Comment by kg
3 months ago
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 constantly ramming through new features at a pace the other two projects can't or won't keep up with.
Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do?
This appeal to authority doesn't hold water for me because the important question is not 'do people with specific priorities think this is a good idea' but instead 'will this idea negatively impact the web platform and its billions of users'. Out of those billions of users it's quite possible a sizable number of them rely on XSLT, and in my reading around this issue I haven't seen concrete data supporting that nobody uses XSLT. If nobody really used it there wouldn't be a need for that polyfill.
Fundamentally the question that should be asked here is: Billions of people use the web every day, which means they're relying on technologies like HTML, CSS, XML, XSLT, etc. Are we okay with breaking something that 0.1% of users rely on? If we are, okay, but who's going to tell that 0.1% of a billion people that they don't matter?
The argument I've seen made is that Google doesn't have the resources (somehow) to maintain XSLT support. One of the googlers argued that new emerging web APIs are more popular, and thus more deserving of resources. So what we've created is a zero-sum game where any new feature added to the platform requires the removal of an existing feature. Where does that game end? Will we eventually remove ARIA and/or screen reader support because it's not used by enough people?
I think all three browser vendors have a duty to their users to support them to the best of their ability, and Google has the financial and human resources to support users of XSLT and is choosing not to.
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%?
That same argument applies to numerous web technologies, though.
Applied to each individually it seems to make sense. However the aggregate effect is kill off a substantial portion of the web.
In fact, it's an argument to never add a new web technology: Should 100% of web users be made vulnerable to bugs in a new technology that 0% of the people are currently using?
Plus it's a false dichotomy. They could instead address XSLT security... e.g., as various people have suggested, by building in the XSLT polyfill they are suggesting all the XSLT pages start using as an alternative.
depends entirely on which technologies are acctively addressing current and future vulnerabilities.
1 reply →
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 trying to have the browser replace the whole OS.
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.
4 replies →
Solutions have been proposed in that threads, including adding the XSLT polyfill to the browser (which would run it in the Javascript VM/sandbox).
If the usage/risk of XSLT is enough to remove it, you'd have to remove webusb, webbluetooth, webmidi, webxr, and countless more
Yes, please.
2 replies →
Isn't this something that could be implemented using javascript?
I don't think anyone is arguing that XSLT has to be fast.
You could probably compile libxslt to wasm, run it when loading xml with xslt, and be done.
Does XSLT affect the DOM after processing, isn't it just a dumb preprocessing step, where the render xhtml is what becomes the DOM.
It could be. The meaningful argument is over whether the javascript polyfill should be built into the browser (in which case, browser support remains the same as it ever was, they just swap out a fast but insecure implementation for a slow but secure one), or whether site operators, principally podcast hosts, should be required to integrate it into their sites and serve it.
The first strategy is obviously correct, but Google wants strategy 2.
1 reply →
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...
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.
> but Google somehow should have infinite resources to maintain things forever?
Google adds 1000+ new APIs to the web platform a year. They are expected to be supported nearly forever. They have no qualms adding those.
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
Bring back VRML!
Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)
Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on...
> But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on...
Flash was not part of the web platform. It was a plugin, a plugin that was, over time, abandoned by its maker.
FTP was not part of the web platform. It was a separate protocol that some browsers just happened to include a handler for. If you have an FTP client, you can still open FTP links just fine.
Non-HTTPS sites are being discouraged, but still work fine, and can reasonably be expected to continue to work indefinitely, though they are likely to be discouraged a bit harder over time.
XSLT is part of the web platform. And removing it breaks various things.
I don't think that distinction makes much of a difference for the users and devs affected...
Flash was the best part of the web, though.
1 reply →
XSLT was awesome back in the day. You could get a block of XML data from the server, and with a bit of very simple scripting, slice it, filter it, sort it, present summary or detail views, generate tables or forms, all without a server round trip. This was back in IE6 days, or even IE5 with an add-on.
We built stuff with it that amazed users, because they were so used to the "full page reload" for every change.
> Probably there are a handful of legacy corporate users hanging on to it for dear life.
Like more or less everyone that hosts podcasts. But the current trend is for podcast feeds to go away, and be subsumed into Spotify and YouTube.
Do people consume RSS feeds directly via XSLT? Not through apps and such that subscribe to the feed?
1 reply →
> Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)
And those that would replace you might care more for the web rather than the next performance review.
+1. I worked on an internal corporate eCommerce in 2005 built entirely on DOM + XSLT to create the final HTML. It was an atrocious pain in the neck to maintain (despite being server side so the browser never had to deal with the XSLT). Unless you still manipulate XML and need to transform it in various other formats through XSLT/XSL-FO, I don’t see why anyone would bother with it. It always cracks me up when people « demand » support for features hardly ever used for which they won’t spend a dime or a minute to help
When I see "reps from every browser agree" my bullshit alarm immediately goes off. Does it include unanimous support from browser projects that are either:
1. not trillion dollar tech companies
or
2. not 99% funded from a trillion dollar tech company.
I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare. And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.
Well, every browser engine that is part of WHATWG. That's how working groups... work. The current crop of "not Chrome/Firefox/Webkit" aren't typically building their own browser engines though. They're re-skinning Chromium/Gecko/Webkit.
The reckless, infinite scope of web browsers https://drewdevault.com/2020/03/18/Reckless-limitless-scope....
It’s worth noting that since that article was written, the Ladybird browser has made a lot of progress with their new browser engine.
https://ladybird.org
> Does it include unanimous support from browser projects
They could continue supporting XSLT if they wanted.
This makes the job of smaller engines like Servo and Ladybird a lot easier.
It's not a huge conspiracy, but it is worthwhile to consider what the incentives are for people from each browser vendor. In practice all the vendors probably have big backlogs of work they are struggling to keep up with. The backlogs are accumulating in part because of the breakneck pace at which new APIs and features are added to the web platform, and in part because of the unending torrent of new security vulnerabilities being discovered in existing parts of the platform. Anything that reduces the backlog is thus really appealing, and money doesn't have to change hands.
Arguably, we could lighten the load on all three teams (especially the under-resourced Firefox and Safari teams) by slowing the pace of new APIs and platform features. This would also ease development of browsers by new teams, like Servo or Ladybird. But this seems to be an unpopular stance because people really (for good reason) want the web platform to have every pet feature they're an advocate for. Most people don't have the perspective necessary to see why a slower pace may be necessary.
>I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare.
This has never ever made sense because Mozilla is not at all afraid to piss in Google's cheerios at the standards meetings. How many different variations of Flock and similar adtech oriented features did they shoot down? It's gotta be at least 3. Not to mention the anti-fingerprinting tech that's available in Firefox (not by default because it breaks several websites) and opposition to several Google-proposed APIs on grounds of fingerprinting. And keeping Manifest V2 around indefinitely for the adblockers.
People just want a conspiracy, even when no observed evidence actually supports it.
>And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.
That's basically true whether incidentally or on purpose.
Controlled opposition is absolutely a thing, and to think that people at trillion dollar companies wouldn't do this is naive. I'm not claiming for a fact that mozilla is controlled opposition, i'm just saying it's very feasible that it could be, and i look for signs of it.
You give examples of things they disagree on, and i wouldn't refute that. However i would say that google is going to pick and choose their battles, because ultimately things they appear to "lose on" sort of don't matter. fingerprinting is a great example - yes, firefox provides it, but it's still largely pretty useless, and its impact is even more meaningless because so few people use it. if you have javascript on and arent using a VPN, chances are your anti-fingerprinting isn't actually doing much other than annoying you and breaking sites.
the only real thing to be used for near-complete-anonymity is Tor, but only when it's also used in the right way, and when JavaScript is also turned off. And even then there are ways it could and probably has failed.
Many such cases. Remember when the Chrome team seriously thought they could just disable JavaScript alert() overnight [1][2] and not break decades of internet compatibility? It still makes me smile how quietly this was swept under the rug once it crashed and burned, just like how the countless "off-topic" and "too emotional" comments on Github said it would.
Glad to see the disdain for the actual users of their software remains.
[1] https://github.com/whatwg/html/issues/2894 [2] https://www.theregister.com/2021/08/05/google_chrome_iframe/
(FWIW I agree alert and XSLT are terrible, but that ship sailed a long time ago.)
> Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT
Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications.
Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder who wormed her way onto the HOA board speaking for everyone else. No.
There are countries like Germany where Firefox still has around 10% market share [0], or closer to 20% on the desktop, only second behind Chrome [1]. Not exactly irrelevant.
[0] https://gs.statcounter.com/browser-market-share/all/germany
[1] https://gs.statcounter.com/browser-market-share/desktop/germ...
It has long seemed like Firefox is likely doing Google's bidding? That could be a reason why they're given a full vote?
/abject-speculation
> Did anybody bother checking with Microsoft?
> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?
The juxtaposition of these two statements is very funny.
Firefox actually develops a browser, Microsoft doesn't. That's why Firefox gets a say and Microsoft doesn't. Microsoft jumped off the browser game years ago.
No, changing the search engine from Google to Bing in chromium doesn't count.
Ultimately, Microsoft isn't implementing jack shit around XSLT because they aren't implementing ANY web standards.
You make it sound like those two thoughts are incompatible in juxtaposition, but they are in fact perfectly consistent, even if you were correct that Microsoft isn't building anything, as the premise is that users matter more than elbow grease. The reason why you'd want to ask Microsoft is the same reason why you might not bother consulting Firefox: because Microsoft has actual users they represent, and Firefox does not.
1 reply →
This is not true. Microsoft is participating in standards and implementing them in Blink.
1 reply →
"Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?"
There was not really a vote in the first place and FF is still dependant on google. Otherwise FF (users) represants a vocal and somewhat influental minority, capable of creating shitstorms, if the pain level is high enough.
Personally, I always thought XSLT is somewhat weird, so I never used it. Good choice in hindsight.
Maybe because Edge is just a wrapper around Blink?
So Microsoft cucked by Google and Mozilla being a puppet regime of Google at this point.
Seems like a rigged game to me.
Yes it's a wrapper but Microsoft represents a completely different market with individual needs/wants.
If it wasn't for Apple (who doesn't care about enterprise) butting in, the browser consortium would be reminiscent of the old Soviet Union in terms of voting.
> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?
Ironic, considering the market share of XSLT.
>who's going to tell that 0.1% of a billion people that they don't matter?
This is also not a fair framing. There are lots of good reasons to deprecate a technology, and it doesn't mean the users don't matter. As always, technology requires tradeoffs (as does the "common good", usually.)
> Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do?
Because otherwise everybody has to repeat same work again and again, programming how - instead of focusing on what, declarative way.
Then data is not free, but caged by processing so it can't exist without it.
I just want data or information - not processing, not strings attached.
I don't see any need to run any extra code over any information - except to keep control and to attach other code, trackers etc. - just, I'm not Google, no need to push anything (just.. faster JS engine instead of empowering users somehow made a browser better ? (no matter how fast, you can't) - for what ? (of what I needed) - or instead of something, that they 'forgot' with a wish they could erase it ?)
> 0.1% of a billion people
Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.
0.02% of public Web pages, apparently, have the XSLT processing instruction in them, and a few more invoke XSLT through JavaScript (no-one really knows how many right now).
It’s likely more heavily used inside corporate and governmental firewalls, but that’s much harder to measure.
[dead]
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 contingent of web people are angry that Google keeps adding all sorts of weird stuff to the platform. Useful weird stuff, but regardless.
“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.
2 replies →