Comment by troupo
3 months ago
Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523
3 months ago
Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523
It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue.
Google is boneheaded and hostile to open web at this point, explicitly.
> It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue.
Go changed their telemetry to opt-in based on community feedback, so I'm not sure what point you're trying to make with that example.
No. The official statement from Brian was “I received a couple of personal e-mails from some credible people who stated that their data belonged to them, so we (I) decided to make it opt-in” (paraphrased).
I spent days in that thread. That uproar was “a bunch of noisy minority which doesn’t worth listening” for them.
6 replies →
Looks like they're going to ram it through anyway, no matter the existing users. There's got to be a better way to deal with spam than just locking the thread to anyone with relevant information.
WHATWG literally forced W3C to sign a deal and obey their standards. WHATWG is basically Google + Apple + Microsoft directly writing the browser standards. Fixing Microsoft's original mistake of Internet Explorer of not creating a faux committee lol.
w3c architecture astronauts have no place dictating standards that they can't implement.
"Heated discussion" sounds like any comment voicing legitimate concern being hidden as "off-topic", and the entire discussion eventually being locked. Gives me Reddit vibes, I hope this is not how open web standards are managed.
If it's a security issue, shouldn't the browsers just replace C++ code with the JS or WASM polyfill themselves?
I also wondered about that. They probably don't want to do that because of maintaining, fixing and allocating resources to it then.
Probably a browser extension on the user side can do the same job if an XSLT relying page cannot be updated.
This seems like the kind of thing that won't require any resources to maintain, other than possible bugfixes (which 3rd parties can provide). It only requires parsing and DOM manipulation, so it doesn't really require any features of JS or WASM that would be deprecated in the future, and the XSLT standard that is supported by browsers is frozen - they won't ever have to dedicate resources to adding any additional features.
1 reply →