2 ms·

Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/i

by troupo 1y ago

Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523

webstrand 1y ago
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.
- delfinom 1y ago
  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.
  - arccy 1y ago
    w3c architecture astronauts have no place dictating standards that they can't implement.
bayindirh 1y ago
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.
- agwa 1y ago
  > 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.
  - bayindirh 1y ago
    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.
    - arccy 1y ago
      where is this official statement, I don't think you even managed to get the name right
      - bayindirh 1y ago
        Sorry. Was at dinner. It's Russ Cox. Being hungry and in a hurry doesn't help with remembering names. The GitHub discussion is there: https://github.com/golang/go/discussions/58409 https://github.com/golang/go/discussions/58409 but the words I of Russ I cited is here: https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p0N7AwAJ https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p... Copying verbatim: It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence. So as a person who just started programming Go and made some good technical comments didn't matter at all. Only people with clout has mattered, and the voice had to come from the team itself. Otherwise we the users' influence is "fuck all" (sorry, my blood boils every time I read this comment from Russ).
    - rafram 1y ago
      I mean yeah, I too would probably prefer to read a few well-reasoned arguments over email than to wade through hundreds of hateful, vitriolic, accusatory comments from randos in a GitHub thread. Being an open-source maintainer is hard.
      - troupo 1y ago
        Or, you know, do the right thing from the start considering that forced telemetry you have to opt-out of is universally reviled and every project that includes it suffers from literally the same issues.
deleted 1y ago
[deleted]
ummonk 1y ago
If it's a security issue, shouldn't the browsers just replace C++ code with the JS or WASM polyfill themselves?
- therealmarv 1y ago
  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.
  - ummonk 1y ago
    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.
    - esprehn 1y ago
      That is an interesting approach, you could suggest it? In general using JS to implement web APIs is very difficult, but using WASM might work especially for the way XSLTProcessor works today.
uyzstvqs 1y ago
"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.

by troupo 1y ago

Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523

webstrand 1y ago

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.

delfinom 1y ago
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.
- arccy 1y ago
  w3c architecture astronauts have no place dictating standards that they can't implement.

bayindirh 1y ago

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.

agwa 1y ago
> 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.
- bayindirh 1y ago
  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.
  - arccy 1y ago
    where is this official statement, I don't think you even managed to get the name right
    - bayindirh 1y ago
      Sorry. Was at dinner. It's Russ Cox. Being hungry and in a hurry doesn't help with remembering names. The GitHub discussion is there: https://github.com/golang/go/discussions/58409 https://github.com/golang/go/discussions/58409 but the words I of Russ I cited is here: https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p0N7AwAJ https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p... Copying verbatim: It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence. So as a person who just started programming Go and made some good technical comments didn't matter at all. Only people with clout has mattered, and the voice had to come from the team itself. Otherwise we the users' influence is "fuck all" (sorry, my blood boils every time I read this comment from Russ).
  - rafram 1y ago
    I mean yeah, I too would probably prefer to read a few well-reasoned arguments over email than to wade through hundreds of hateful, vitriolic, accusatory comments from randos in a GitHub thread. Being an open-source maintainer is hard.
    - troupo 1y ago
      Or, you know, do the right thing from the start considering that forced telemetry you have to opt-out of is universally reviled and every project that includes it suffers from literally the same issues.

deleted 1y ago

[deleted]

ummonk 1y ago

If it's a security issue, shouldn't the browsers just replace C++ code with the JS or WASM polyfill themselves?

therealmarv 1y ago
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.
- ummonk 1y ago
  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.
  - esprehn 1y ago
    That is an interesting approach, you could suggest it? In general using JS to implement web APIs is very difficult, but using WASM might work especially for the way XSLTProcessor works today.

uyzstvqs 1y ago

"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.