Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

Post reply on HN
Print view View original

361–370 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#361

Post by zahlman »

notatoad wrote: post #188
BoiledCabbage wrote: post #113

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 m…

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

Well, no; the reasonable course of action is to solicit feedback from the right people instead.

Re: "Remove mentions of XSLT from the html spec"

#363

Post by tsimionescu »

upofadown wrote: post #170
spankalee wrote: post #92

A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…

The implementations are owned by the implementers. Who owns the actual standard, the implementers or the users?

As for any standard, the implementers ultimately own it. Users don't spend resources on implementing standards, so they only get a marginal say. Do you expect to contribute to the 6G standards, or USB-C, too?

Re: "Remove mentions of XSLT from the html spec"

#364

Post by moomin »

starkparker wrote: post #355
bawolff wrote: post #221

Earlier quoted context omitted.

If people are upset about xslt being removed, step 1 would have been to actually use it in a significant way on the web. Step 2 would have been to volunteer to maintain libxslt. Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.

Didn't someone step up to volunteer ot maintain libxslt a few weeks ago? https://gitlab.gnome.org/GNOME/libxslt/-/issues/150

Knowing our luck it’s probably Jia Tan.

Re: "Remove mentions of XSLT from the html spec"

#365

Post by LegionMammal978 »

chocmake wrote: post #238
LegionMammal978 wrote: post #95

Oh hey, that thing happened that one could easily see was going to happen [0]. The writing was on the wall for XSL as soon as the browsers tore out FTP support: their desire to minimize attack surface trumps any tendency to leave well enough alone. I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those…

CSS animations still lack a semantic way to sequence animations based on the beginning/end of some other animation, which SMIL offers. With SMIL you can say 'when this animation ID begins/ends only then trigger this other animation', including time offsets from that point. Which is miles better than having to having to use calcs for CSS animation timing which requires a kludge of CSS variables/etc to keep track of wh…

> if wanting to avoid requiring Javascript.

And there's one of the issues: browser devs are perfectly happy if user JS can be used to replicate some piece of functionality, since then it's not their problem.

Re: "Remove mentions of XSLT from the html spec"

#366

Post by ioasuncvinvaer »

kevin_thibedeau wrote: post #275
Shebanator wrote: post #227

Earlier quoted context omitted.

So the Safari developers are overworked/under-resourced, but Google somehow should have infinite resources to maintain things forever? Apple is a much bigger company than Google these days, so why shouldn't they also have these infinite resources? Oh, right, its because fundamentally they don't value their web browser as much as they should. But you give them a pass.

One is a browser. The other is an ad delivery platform which requires a more strategic active development posture.

The funny thing is that apple has a huge ad business so I don't know which browser you mean.

Re: "Remove mentions of XSLT from the html spec"

#368

Post by tsimionescu »

basscomm wrote: post #314
kstrauser wrote: post #265

Earlier quoted context omitted.

> 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 err…

> 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. I _do_ use XSLT on my tiny, low-traffic blog, and I _don't_ think that it's reasonable for browser devs to tell me to update my code. Also, it's real easy to manufacture a situation where adoption of a thing is low when the implementation is incomplete and hasn't had significant updates for decades.

The web has grown a thousand fold over those decades, in spite of no support for XSLT. No browser has failed (or gained market traction) by missing support for (or adding more support for) XSLT. It's an irrelevancy, even if you did like it once.

Lots of content was lost when Flash was removed as well - much, much more than the amount of content that will be lost if XSLT is removed. And yet the web continued.

Re: "Remove mentions of XSLT from the html spec"

#369

Post by codedokode »

ArchOversight wrote: post #330
codedokode wrote: post #194

Earlier quoted context omitted.

> I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else. Serving a server-generated HTML page could be even faster.

That assumes the server has a lot of additional CPU power to serve the content as HTML (and thus do the templating server side), whereas with XSLT I can serve XML and the XSLT and the client side can render the page according to the XSLT. The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.

With server-side rendering you control the amount of compute you are providing, with client-side rendering you cannot control anything and if the app would be dog slow on some devices you can't do anything.

Re: "Remove mentions of XSLT from the html spec"

#370

Post by lyricaljoke »

xg15 wrote: post #214
spankalee wrote: post #127

Earlier quoted context omitted.

Also, https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback. It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. This is happening after some serious exploi…

I think this post is useful where the thread author proposed some solutions to the people affected: https://github.com/whatwg/html/issues/11523#issuecomment-318... The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering. I think this could be addressed by introducing a processing instruction that browsers would inter…

I actually found that particular response to be quite disappointing. It should give pause to those advocating removal of XSLT that these three totally disparate use cases could already be gracefully handled by a single technology which is:

* side effect free (a pure data to data transformation)

* stable, from a spec perspective, for decades

* completely client-side

Isn't this basically an A+ report card for any attempt at making a powerful general tool? The fact that the suggested solution in the absence of XSLT is to toil away at implementing application-specific solutions forever really feels like working toward the wrong direction.

Post reply on HN