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

381–390 of 559 posts

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

#381

Post by troupo »

otterley wrote: post #145
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…

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

1. Chrome telemetry underreports a lot of use cases

2. They have a semi-internal document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... that explicitly states: small usage percentage doesn't mean you can safely remove a feature

--- start quote ---

As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial.

There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!

--- end quote ---

3. Any feature removal on the web has to be a) given thorough thought and investigation which we haven't seen. Library of congress apparently uses XSLT and Chrome devs couldn't care less

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

#382

Post by troupo »

kg wrote: post #133
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…

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…

And Google even has a doc literally saying that you shouldn't break the web even if a small number of sites use a feature: https://news.ycombinator.com/item?id=44956267

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

#383

Post by const_cast »

codedokode wrote: post #204
rebolek wrote: post #152

Earlier quoted context omitted.

Why should the browser contain a specific scripting language, like JavaScript, and not ActiveScript for example?

The browser could use Java or .NET bytecode interpreter - in this case it doesn't need to have a compiler and you can use any language - but in this case you won't be able to see a script's source code.

You already effectively can't see a scripts source code because we compile, minify, and obfuscate JS these days. Because the performance characteristics are so poor.

Actually, most of the time C# decompiles nicer from CLR bytecode than esoterically built JS.

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

#384

Post by em-bee »

ndriscoll wrote: post #350
jerf wrote: post #303

Earlier quoted context omitted.

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize…

Statistically, how many websites are using webusb? I'm guessing fewer than xslt, which is used by e.g. the US Congress website. I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component sys…

i just built a website in XSLT and implementing some form of client side include in XSLT is not easier than doing the same in javascript. while i agree with you that client side include is sorely missing in HTML, XSLT is not the answer to that problem. anyone who doesn't want to use javascript to implement client-side include, won't want to use XSLT either.

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

#385

Post by danans »

pjmlp wrote: post #329
danans wrote: post #287

Earlier quoted context omitted.

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

WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web.

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

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

#386

Post by troupo »

WhitneyLand wrote: post #271
kg wrote: post #151

Earlier quoted context omitted.

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

E.g. Google said in their document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...

--- start quote ---

As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!

--- end quote ---

Read the full doc. They even give examples when they couldn't remove a feature impacting just 0.0000008% of web views.

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

#388

Post by troupo »

nativeit wrote: post #168
pjmlp wrote: post #149

Earlier quoted context omitted.

No need, with exception of Safari, Web is ChromeOS already. All the other alternatives are meaningless, including Firefox. I am one of the few folks on my team that still uses Firefox, all our projects dropped support for it like 5 years ago.

Wow, you’re really pushing this Web=ChromeOS nonsense. Want to support that with something more than your own isolated anecdote?

E.g. Google releasing through dozens of Chrome-only APIs with hardly a spec, and then expecting everyone to support the "standards".

Every discussion about "Safari holding back the web" on HN are about 99% about Google-only non-standards that both Safari and Firefox oppose.

There are multiple "works only in Chrome" websites, many of them regularly published on HN.

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

#389

Post by OrvalWintermute »

kg wrote: post #133
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…

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…

It sounds like Mozilla has problems despite the quite lucrative "notoriously under-resourced" $400M - $500M a year Google spends on FF a year

Is there a spending on junk projects issue with Firefox?

https://galaxy.ai/youtube-summarizer/is-mozilla-wasting-mone...

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

#390

Post by hokkos »

ArchOversight wrote: post #324
spankalee wrote: post #171

Earlier quoted context omitted.

Another way to look at this is: Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?

If this is the reason to remove and or not add something to the web, then we should take a good hard look at things like WebSerial/WebBluetooth/WebGPU/Canvas/WebMIDI and other stuff that has been added that is used by a very small percentage of people yet all could contain various security bugs... If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are…

whatever you do with xslt you can do it in a saner way, but whatever we need to use serial/bluetooth/webgpu/midi for there is no other way, and canvas is massively used.
Post reply on HN