Comment by BoiledCabbage
3 months ago
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.
>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.
> 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.
> 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.
5 replies →
You're literally commenting on a thread full of those explanations that were handwaved away.
Google's own document says numbers don't show the full picture: https://news.ycombinator.com/item?id=44958929
Well, no; the reasonable course of action is to solicit feedback from the right people instead.
yeah! they should only ask for feedback from people who love XSLT, other people's opinion doesn't matter.
Part of the reason I stopped was lack of higher than 1.0 in browsers.
The other reason is that SVG took a very long time to get good, and when it did I wanted to use XSL and SVG together.
Now SVG has got good and they are removing it :(
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.
There's even a JS implementation of XSLT 3.0 already (SaxonJS).
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.
This is clearly the Right Thing. So what do you suppose the chance of it happening is?
Not really, because that would add a dependency on Javascript whereas, at the moment, XSLT works without Javascript enabled.
Not necessarily. The idea is that this is browser-internal, so presumably it would still work even if JS from external sources is disabled.
2 replies →
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.
Google tells you what they're going to do to the web with a question mark on the end.
It's called uptalking.
[flagged]
The vast majority of feedback on the GitHub issue was respectful — unless you consider opposing the proposal disrespectful.
There’s not nearly enough comments for “vast majority” to be a useful descriptor, and I saw a significant number of uncivil, rude comments.
Web is for all practical purposes ChromeOS, but then people complain about Apple not playing ball.
> ChromeOS is for all practical purposes, the web.
Fixed that typo for you.
> > 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.
6 replies →