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

271–280 of 559 posts

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

#271

Post by WhitneyLand »

kg wrote: post #151
segmondy wrote: post #144

Earlier quoted context omitted.

By your argument, once anything makes it in, then it can't be removed. Billions of people are going to use the web every day and it won't stop. Even the most obscure feature will end up being used by 0.1% of users. Can you name a feature that's supported by all browsers that's not being used by anyone?

Yes. That is exactly how web standards work historically. If something will break 0.1% of the web it isn't done unless there are really really strong reasons to do it anyway. I personally watched lots of things get bounced due to their impact on a very small % of all websites. This is part of why web standards processes need to be very conservative about what's added to the web, and part of why a small vocal continge…

“That is exactly how web standards work…”

Says who? You keep mentioning this 0.1% threshold yet…

1. I can’t find any reference to that do you have examples / citations?

2. On the contrary here’s a paper that proposes a 3x higher heuristic: https://arianamirian.com/docs/icse2019_deprecation.pdf

3. It seems there are plenty of examples of features being removed above that threshold NPAPI/SPDY/WebSQL/etc.

4. Resources are finite. It’s not a simple matter of who would be impacted. It’s also opportunity cost and people who could be helped as resources are applied to other efforts.

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

#272

Post by LegionMammal978 »

kstrauser wrote: post #265
LegionMammal978 wrote: post #242

Earlier quoted context omitted.

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

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

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

#273

Post by chrismorgan »

codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

> Many things, like WebAudio or Canvas, could be immplemented using WASM modules, which as a side effect, would prevent their use for fingerprinting.

Audio and canvas are fundamental I/O things. You can’t shift them to WASM.

You could theoretically shift a fair bit of Audio into a WASM blob, just expose something more like Mozilla’s original Audio Data API which the Web Audio API defeated for some reason, and implement the rest atop that single primitive.

2D canvas context includes some rendering stuff that needs to match DOM rendering. So you can’t even just expose pixel data and implement the rest of the 2D context in a WASM blob atop that.

And shifting as much of 2D context to WASM as you could would destroy its performance. As for WebGL and WebGPU contexts, their whole thing is GPU integration, you can’t do that via WASM.

So overall, these things you’re saying could be done in WASM are the primitives, so they definitely can’t.

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

#274

Post by ndriscoll »

JimDabell wrote: post #262
youngtaff wrote: post #255

Earlier quoted context omitted.

Apart from that doesn’t really work for people who are statically hosting their RSS feeds etc.

You can use content negotiation with static websites too. Apache has mod_negotiation, for example.

Assuming you have access to server configuration. XML/XSLT works anywhere you can host a static page.

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

#275

Post by kevin_thibedeau »

Shebanator wrote: post #227
kg wrote: post #133

Earlier quoted context omitted.

Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for con…

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.

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

#276

Post by esprehn »

Fwiw the XSLT implementation in Blink and WebKit is extremely inefficient. For example converting the entire document into a string, to parse it to a format that's compatible with libxslt, to then produce a string and parse it back into a node structure again. I suspect a user space library could be similarly as effective.

Ex. https://source.chromium.org/chromium/chromium/src/+/main:thi...

https://source.chromium.org/chromium/chromium/src/+/main:thi...

https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca3902...

Mozilla has an in-house implementation at least:

https://github.com/mozilla-firefox/firefox/tree/5f99d536df02...

It seems like the answer to the compat issue might be the MathML approach. An outside vendor would need to contribute an implementation to every browser. Possibly taking the very inefficient route since that's easy to port.

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

#277

Post by jauco »

arjvik wrote: post #269
xg15 wrote: post #214

Earlier quoted context omitted.

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…

Purely out of curiosity, what are some websites that actually make use of XSLT?

Skechers used to :)

https://thedailywtf.com/articles/Sketchy-Skecherscom

Also world of warcraft used to.

Can’t think of recent examples though.

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

#279

Post by timeon »

codedokode wrote: post #194
geocar wrote: post #175

Earlier quoted context omitted.

> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations. Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio... > and not Jinja for example? Jinja operates on text, so it's basically document.w…

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

Maybe but PR author, who created the Issue there as well, gave example: 'JSON+React'. 'React' one of the slowest framework out there. Performance is rarely considered in contemporary front-end.

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

#280

Post by [deleted] »

bawolff wrote: post #221
jchw wrote: post #209

Earlier quoted context omitted.

I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues. To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute. To be honest if…

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.

[deleted]
Post reply on HN