5 ms·

So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks fo

So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all mostly ignored. And "if this is about adoption then listen to the constant community request to update the the newer XSLT 3.0 which has been out for years and world have much higher adoption due to tons of QoL improvements including handling JSON." And the argument presented, which i don't know (but seems reasonable to me), is that XSLT supports the open web. Google tried to kill it a decade ago, the community pushed back and stopped it. So Google's plan was to refuse to do anything to support it, ignore community requests for simple improvements, try to make it wither then use that as justification for killing it at a later point. Forcing this through when almost all feedback is against it seems to support that to me. Especially with XSLT suddenly/recebtly gaining a lot of popularity and it seems like they are trying to kill it before they have an open competitor in the web. https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523

pjmlp 1y ago
Web is for all practical purposes ChromeOS, but then people complain about Apple not playing ball.
- nativeit 1y ago
  > ChromeOS is for all practical purposes, the web. Fixed that typo for you.
  - danans 1y ago
    > > ChromeOS is for all practical purposes, the web I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.
    - pjmlp 1y ago
      That is a VM, and actually maybe eventually it will be on top of Webassembly, how things are going.
      - danans 1y ago
        > That is a VM... So is WSL on Windows. I wouldn't call Windows "just the web". There's also nothing stopping me from building and running local desktop GUI software on the VM. In fact, a VM is better in that I can back up and restore the image easily.
        pjmlp 1y ago
        WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web.
        danans 1y ago
        > WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web. Just like the Linux VM on ChromeOS.
        pjmlp 1y ago
        Which eventually will be a VM on top of WebAssembly, given the hype. https://webvm.io/ https://webvm.io/
        danans 1y ago
        > Which eventually will be a VM on top of WebAssembly, I'm not sure how that supports the argument that ChromeOS is only "the web". It's running a native VM for Linux today. What would be the advantage of porting it to WebAssembly?
webstrand 1y ago
It would be incredible if we could pull it into the javascript/wasm sandbox and get xslt 3.0 support. The best of both worlds, at the cost of a performance hit on those pages, but not a terrible cost.
- NoGravitas 1y ago
  This is clearly the Right Thing. So what do you suppose the chance of it happening is?
- bilog 1y ago
  There's even a JS implementation of XSLT 3.0 already (SaxonJS).
  - webstrand 1y ago
    That's pretty cool, its too bad the license is a bit confusing about whether bundling with Chrome or Firefox would be permissible under the license.
- dev0001 1y ago
  Not really, because that would add a dependency on Javascript whereas, at the moment, XSLT works without Javascript enabled.
  - dpassens 1y ago
    Not necessarily. The idea is that this is browser-internal, so presumably it would still work even if JS from external sources is disabled.
    - colejohnson66 1y ago
      No. The idea is that website authors do the work. The proposal suggests the browsers wholesale remove support and forget about it. https://github.com/whatwg/html/issues/11523#issuecomment-3155739198 https://github.com/whatwg/html/issues/11523#issuecomment-315...
notatoad 1y ago
>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.
- LegionMammal978 1y ago
  > people who are actually using it I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision. > explain why it's necessary No feature is strictly necessary, so that's a pretty high standard.
  - kstrauser 1y ago
    > I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision. I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it. I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it. Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.
    - LegionMammal978 1y ago
      True, a small number of vocal opponents does not automatically make something a bad idea. But in these cases of compatibility, especially with something as big as the Web, the vast majority of those affected who do care will be completely silent. There's no hotline to call up the entire world and tell them to update their code. (And if you did want to tell the entire world to update their code, and have any chance of them following through with it, you'd better make sure there's an immediate replacement ready. Log4Shell would probably still be a huge issue today if it couldn't be fixed in place by swapping out jar files.)
insin 1y ago
Google tells you what they're going to do to the web with a question mark on the end.
- cryptonector 1y ago
  It's called uptalking.
cess11 1y ago
It comes with the XML territory that things have versioned schemas and things like namespaces, and can be programmed in XSLT. This typically means that integrations are trivial due to public, reliable contracts. Unlike your average Angular project. Building on top of minified Typescript is rather unreasonable and integrating with JSON means you have a less than reliable data transfer protocol without schema, so validation is a crude trial and error process. There's no elegance in raw XML et consortes, but the maturity of this family means there are also very mature tools so in practice you don't have to look at XML or XSD as text, you can just unmarshal it into your programming language of choice (that is, if you choose a suitable one) and look at it as you would some other data structure.
arp242 1y ago
[flagged]
- dev0001 1y ago
  The vast majority of feedback on the GitHub issue was respectful — unless you consider opposing the proposal disrespectful.
  - whimsicalism 1y ago
    There’s not nearly enough comments for “vast majority” to be a useful descriptor, and I saw a significant number of uncivil, rude comments.

pjmlp 1y ago

Web is for all practical purposes ChromeOS, but then people complain about Apple not playing ball.

nativeit 1y ago
> ChromeOS is for all practical purposes, the web. Fixed that typo for you.
- danans 1y ago
  > > ChromeOS is for all practical purposes, the web I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.
  - pjmlp 1y ago
    That is a VM, and actually maybe eventually it will be on top of Webassembly, how things are going.
    - danans 1y ago
      > That is a VM... So is WSL on Windows. I wouldn't call Windows "just the web". There's also nothing stopping me from building and running local desktop GUI software on the VM. In fact, a VM is better in that I can back up and restore the image easily.
      - pjmlp 1y ago
        WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web.
        danans 1y ago
        > WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web. Just like the Linux VM on ChromeOS.
        pjmlp 1y ago
        Which eventually will be a VM on top of WebAssembly, given the hype. https://webvm.io/ https://webvm.io/
        danans 1y ago
        > Which eventually will be a VM on top of WebAssembly, I'm not sure how that supports the argument that ChromeOS is only "the web". It's running a native VM for Linux today. What would be the advantage of porting it to WebAssembly?

webstrand 1y ago

It would be incredible if we could pull it into the javascript/wasm sandbox and get xslt 3.0 support. The best of both worlds, at the cost of a performance hit on those pages, but not a terrible cost.

NoGravitas 1y ago
This is clearly the Right Thing. So what do you suppose the chance of it happening is?
bilog 1y ago
There's even a JS implementation of XSLT 3.0 already (SaxonJS).
- webstrand 1y ago
  That's pretty cool, its too bad the license is a bit confusing about whether bundling with Chrome or Firefox would be permissible under the license.
dev0001 1y ago
Not really, because that would add a dependency on Javascript whereas, at the moment, XSLT works without Javascript enabled.
- dpassens 1y ago
  Not necessarily. The idea is that this is browser-internal, so presumably it would still work even if JS from external sources is disabled.
  - colejohnson66 1y ago
    No. The idea is that website authors do the work. The proposal suggests the browsers wholesale remove support and forget about it. https://github.com/whatwg/html/issues/11523#issuecomment-3155739198 https://github.com/whatwg/html/issues/11523#issuecomment-315...

notatoad 1y ago

>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.

LegionMammal978 1y ago
> people who are actually using it I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision. > explain why it's necessary No feature is strictly necessary, so that's a pretty high standard.
- kstrauser 1y ago
  > I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision. I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it. I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it. Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.
  - LegionMammal978 1y ago
    True, a small number of vocal opponents does not automatically make something a bad idea. But in these cases of compatibility, especially with something as big as the Web, the vast majority of those affected who do care will be completely silent. There's no hotline to call up the entire world and tell them to update their code. (And if you did want to tell the entire world to update their code, and have any chance of them following through with it, you'd better make sure there's an immediate replacement ready. Log4Shell would probably still be a huge issue today if it couldn't be fixed in place by swapping out jar files.)

insin 1y ago

Google tells you what they're going to do to the web with a question mark on the end.

cryptonector 1y ago
It's called uptalking.

cess11 1y ago

It comes with the XML territory that things have versioned schemas and things like namespaces, and can be programmed in XSLT. This typically means that integrations are trivial due to public, reliable contracts. Unlike your average Angular project. Building on top of minified Typescript is rather unreasonable and integrating with JSON means you have a less than reliable data transfer protocol without schema, so validation is a crude trial and error process. There's no elegance in raw XML et consortes, but the maturity of this family means there are also very mature tools so in practice you don't have to look at XML or XSD as text, you can just unmarshal it into your programming language of choice (that is, if you choose a suitable one) and look at it as you would some other data structure.

arp242 1y ago

[flagged]

dev0001 1y ago
The vast majority of feedback on the GitHub issue was respectful — unless you consider opposing the proposal disrespectful.
- whimsicalism 1y ago
  There’s not nearly enough comments for “vast majority” to be a useful descriptor, and I saw a significant number of uncivil, rude comments.