6 ms·

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 Firefo

by kg 1y 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.

segmondy 1y ago
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?
- kg 1y ago
  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.
  - WhitneyLand 1y ago
    “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 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.
    - troupo 1y ago
      E.g. Google said in their document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk 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.
      - 1y ago
93po 1y ago
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.
- kg 1y ago
  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.
- spankalee 1y ago
  This makes the job of smaller engines like Servo and Ladybird a lot easier.
- dralley 1y ago
  >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.
spankalee 1y ago
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%?
- microtonal 1y ago
  Solutions have been proposed in that threads, including adding the XSLT polyfill to the browser (which would run it in the Javascript VM/sandbox).
- jopsen 1y ago
  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.
  - NoGravitas 1y ago
    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.
    - realityking 1y ago
      As discussed in the GitHub thread, strategy two is fundamentally flawed because there’s no other way to make an XML document human readable in today’s browsers. (CSS is close but lacking some capabilities) So site operators who rely on this feature today are not merely asked to load a polyfill but to fundamentally change the structure of their website - without necessarily getting to the same result in the end.
- jmull 1y ago
anon84873628 1y ago
>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.)
solardev 1y ago
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...
- NoGravitas 1y ago
  > 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.
  - solardev 1y ago
    Do people consume RSS feeds directly via XSLT? Not through apps and such that subscribe to the feed?
    - passivegains 1y ago
      This came up in some of the comments: https://github.com/whatwg/html/issues/11523#issuecomment-3154574260 https://github.com/whatwg/html/issues/11523#issuecomment-315... if you click the links instead of copy/pasting into your reader you get a page full of raw XML. It's not harmful or anything but it's not a great look. You can't really expect your users to just never click on your links, that's usually what links are for.
- chrismorgan 1y ago
  > 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.
sugarpimpdorsey 1y 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.
- alfiedotwtf 1y ago
  Maybe because Edge is just a wrapper around Blink?
  - sugarpimpdorsey 1y ago
    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.
- layer8 1y ago
  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 https://gs.statcounter.com/browser-market-share/all/germany [1] https://gs.statcounter.com/browser-market-share/desktop/germany https://gs.statcounter.com/browser-market-share/desktop/germ...
- lukan 1y ago
  "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.
Shebanator 1y ago
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.
- kevin_thibedeau 1y ago
  One is a browser. The other is an ad delivery platform which requires a more strategic active development posture.
  - ioasuncvinvaer 1y ago
    The funny thing is that apple has a huge ad business so I don't know which browser you mean.
- troupo 1y ago
  > 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.
KingLancelot 1y ago
[dead]
mr_toad 1y ago
> 0.1% of a billion people Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.
- deleted 1y ago
  [deleted]
- barefootliam 1y ago
  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.
troupo 1y ago
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 https://news.ycombinator.com/item?id=44956267
OrvalWintermute 1y ago
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-money-a-deep-dive-into-its-financial-management-DoZCz1rzdx0 https://galaxy.ai/youtube-summarizer/is-mozilla-wasting-mone...
thro1 1y ago
> 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 ?)
veeti 1y ago
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 https://github.com/whatwg/html/issues/2894 [2] https://www.theregister.com/2021/08/05/google_chrome_iframe/ 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.)

by kg 1y ago

segmondy 1y ago

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?

kg 1y ago
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.
- WhitneyLand 1y ago
  “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 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.
  - troupo 1y ago
    E.g. Google said in their document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk 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.
    - 1y ago

93po 1y ago

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.

kg 1y ago
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.
spankalee 1y ago
This makes the job of smaller engines like Servo and Ladybird a lot easier.
dralley 1y ago
>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.

spankalee 1y ago

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%?

microtonal 1y ago
Solutions have been proposed in that threads, including adding the XSLT polyfill to the browser (which would run it in the Javascript VM/sandbox).
jopsen 1y ago
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.
- NoGravitas 1y ago
  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.
  - realityking 1y ago
    As discussed in the GitHub thread, strategy two is fundamentally flawed because there’s no other way to make an XML document human readable in today’s browsers. (CSS is close but lacking some capabilities) So site operators who rely on this feature today are not merely asked to load a polyfill but to fundamentally change the structure of their website - without necessarily getting to the same result in the end.
jmull 1y ago

anon84873628 1y ago

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

solardev 1y ago

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

NoGravitas 1y ago
> 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.
- solardev 1y ago
  Do people consume RSS feeds directly via XSLT? Not through apps and such that subscribe to the feed?
  - passivegains 1y ago
    This came up in some of the comments: https://github.com/whatwg/html/issues/11523#issuecomment-3154574260 https://github.com/whatwg/html/issues/11523#issuecomment-315... if you click the links instead of copy/pasting into your reader you get a page full of raw XML. It's not harmful or anything but it's not a great look. You can't really expect your users to just never click on your links, that's usually what links are for.
chrismorgan 1y ago
> 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.

sugarpimpdorsey 1y 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.

alfiedotwtf 1y ago
Maybe because Edge is just a wrapper around Blink?
- sugarpimpdorsey 1y ago
  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.
layer8 1y ago
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 https://gs.statcounter.com/browser-market-share/all/germany [1] https://gs.statcounter.com/browser-market-share/desktop/germany https://gs.statcounter.com/browser-market-share/desktop/germ...
lukan 1y ago
"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.

Shebanator 1y ago

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.

kevin_thibedeau 1y ago
One is a browser. The other is an ad delivery platform which requires a more strategic active development posture.
- ioasuncvinvaer 1y ago
  The funny thing is that apple has a huge ad business so I don't know which browser you mean.
troupo 1y ago
> 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.

KingLancelot 1y ago

[dead]

mr_toad 1y ago

> 0.1% of a billion people Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.

deleted 1y ago
[deleted]
barefootliam 1y ago
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.

troupo 1y ago

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 https://news.ycombinator.com/item?id=44956267

OrvalWintermute 1y ago

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-money-a-deep-dive-into-its-financial-management-DoZCz1rzdx0 https://galaxy.ai/youtube-summarizer/is-mozilla-wasting-mone...

thro1 1y ago

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

veeti 1y ago

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 https://github.com/whatwg/html/issues/2894 [2] https://www.theregister.com/2021/08/05/google_chrome_iframe/ 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.)