I want browsers to be minimal and simple. For example, canvas should only provide a framebuffer to draw into, and all the rest can be done with WASM libraries. Web Audio should only provide an audio thread, and things like low-pass filters can be implemented in WASM. WebRTC should only provide UDP support, etc.
This would make creating competition easier and reduce attack surface. As a nice side effect, it would become impossible to use canvas or web audio for fingerprinting.
XSLT is great, but its core problem is that the tooling is awful. And a lot of this has to do with the primary author of the XSLT specification, keeping a proprietary (and expensive) library as the main library that implements the ungodly terse spec. Simpler standards and open tooling won out, not just because it was simpler, but because there wasn't someone chiefly in charge of the spec essentially making the tooling an enterprise sales funnel. A shame.
So, instead of a giant corporation with all the resources in the world stepping in and maintaining a core web library, they're deciding to remove a feature because the lone maintainer who has been doing a thankless job for years has decided to unsurprisingly step down from this role.
I suppose we can expect support for XML to be dropped soon as well, since libxml2 maintenance is ending this year.
I don't buy the excuse of low number of users. Google's AMP has abysmal usage numbers, yet they're still maintaining that garbage.
Google has been a net negative for the web, and is directly responsible for the shit show it is today. An entirely expected outcome considering it is steered by corporate interests.
Presuming this goes ahead, I believe this is the first time a standard, baseline-available feature will be removed.
There have been other removals, but few of them were of even specified features, and I don’t think any of them have been universally available. One of the closest might be showModalDialog <https://web.archive.org/web/20140401014356/http://dev.opera....>, but I gather mobile browsers never supported it anyway, and it was a really problematic feature from an implementation perspective too. You could argue Mutation Events from ~2011 qualifies¹; it was supplanted by Mutation Observers within two years, yet hung around for over a decade before being removed. As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.
And so here they are now planning to remove a well-entrenched (if not especially commonly used) feature against the clearly-expressed will of the actual developers, in a one year time frame.
—⁂—
¹ I choose to disqualify Mutation Events because no one ever finished their implementation: WebKit heritage never did DOMAttrModified, Gecko/Trident heritage never did DOMNodeInsertedIntoDocument or DOMNodeRemovedFromDocument. Flimsy excuse, probably. If you want to count it, perhaps you’ll agree to consider XSLT the first time a major, standard, baseline-available feature will be removed?
It would be kind of nice if HTML had something where you can make a remote fetch request for JSON or XML data and get it formatted in some CSS-defined way, without Javascript.
During my college undergrad CS series we had a practicum with a real engineer from HP or somewhere. Our project was to help the world find and download printer drivers over the web. The project was to make a Java web service send XML that conformed to a schema, which would be turned into a webpage by a transform aka XSLT. It seemed convoluted at the time. The teacher showed us “the how” but I guess “the why” was left as an exercise for the reader. I never understood the big picture- at the time it seemed rather complex. But now I realize this probably would have scaled quite well on turn of the century hardware.
One might think that as technology progresses more and more pieces of older technologies get revived and incorporated into the available tooling. Yet the very opposite thing happens: good and working parts are removed because the richest companies on Earth "cannot afford" to keep them.
In 19th century Russia there was a thinker, N. F. Fedorov, who wanted to revive all dead people. He saw it as the ultimate goal of humanity. (He worked in a library, a very telling occupation. He spent most of what he earned to support others.) We do not know how to revive dead people or if we can do that at all; but we certainly can revive old tech or just not let it die.
Of course, this job is not for everyone. We cannot count on the richest, apparently, they're too busy getting richer. This is a job for monks.
> One might think that as technology progresses more and more pieces of older technologies get revived and incorporated into the available tooling. Yet the very opposite thing happens: good and working parts are removed because the richest companies on Earth "cannot afford" to keep them.
I think it is because nobody, excepts a handful of people around the world, feels the need to use XSLT in lieu of CSS. Hence, CSS has evolved over time while XSLT has not.
This is how the world works: technology advances and old things become obsolete over time.
For what it's worth, this is the difference between private-sector and public-sector development. The public sector would have instead argued for some budget to hire developers to maintain libxslt and issue RFPs for grant money to rewrite it in Rust for memory safety guarantees. The private sector decides that it's just not a profitable use of resources and moves to cancel support.
The question isn't whether or not you use XSLT yourself, it's whether you use a different feature that could be deemed unprofitable and slammed on the chopping block. And therefore a question of whether it wouldn't be better for everyone for this work to be publicly funded instead.
I'm quite unconvinced by this - it seems very easy to come up with all sorts of counterexamples, particularly in terms of public infrastructure, but also all of public services are regularly cut if the organising body doesn't see that service as achieving its goals any more.
It is true that public bodies are less concerned with profitability, which changes how they make decisions around deprecations and removals, but being cost-effective is still important for them, especially when budgets are low and need is high. In situations like that, it's not uncommon for, say, a service to get cut so that funding can be reallocated elsewhere where it's more needed.
I don't think publicly funding this sort of work would necessarily significantly change the equation here. The costs of XSLT are relatively high because of its complexity and the natural security risks that arise from that complexity. Meanwhile, it is very rarely used, and where it is used, there are better alternatives (generally loading a sandboxed library rather than using the built-in tooling).
I'm an XSLT fanboy. I've used it for all kinds of things, from generating docs to generating entire UIs from an XML declaration. But never in all my years have I used it in a browser. I didn't even know that was an option.
XSLT is to my knowledge the only client side technology that lets you include chunks of HTML without using JavaScript and without server-side technology.
XSLT lets you build completely static websites without having to use copy paste or a static website generator to handle the common stuff like menus.
Makes sense, but I'll have to update my rss feed (which currently uses XSLT to display in browsers that don't have native RSS capabilities - i.e. basically all modern browsers)
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. [..]
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user [paying for that saving on costs by some big company - or having to redo NOW in less efficient way something that still works well so far regardless of decades passed] !
Moreover.. Content First - and browser is a secondary thing to existing content (Chrome came after) - not the (double) opposite (primary, for ads n tracking instead)
- isn't Google as a public servant - so part of their job is to fix their bugs - but not in the position to decide to kill someone else existing content or solution - for not displaying ads so easy?
Wasn't the social contract that get the market share that you can use Chrome to browse all the web already existing as well as by using the other browsers - means not discriminating (non-profit, government, older sites or those working well without JS for ads to be tracked), and not to kill parts of that web when convenient ?
One extremely important use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use.
XSLT is wildly under-appreciated. You can take hierarchical data and bend it to your will, remix it, and turn it inside out if you wish. Those developers working with XML should consider XSLT before rolling their own manipulation script.
Now, do you need XSLT’s capabilities in the browser? Their stats say no one’s really using it.
32 comments
[ 688 ms ] story [ 7422 ms ] threadThis would make creating competition easier and reduce attack surface. As a nice side effect, it would become impossible to use canvas or web audio for fingerprinting.
I suppose we can expect support for XML to be dropped soon as well, since libxml2 maintenance is ending this year.
I don't buy the excuse of low number of users. Google's AMP has abysmal usage numbers, yet they're still maintaining that garbage.
Google has been a net negative for the web, and is directly responsible for the shit show it is today. An entirely expected outcome considering it is steered by corporate interests.
There have been other removals, but few of them were of even specified features, and I don’t think any of them have been universally available. One of the closest might be showModalDialog <https://web.archive.org/web/20140401014356/http://dev.opera....>, but I gather mobile browsers never supported it anyway, and it was a really problematic feature from an implementation perspective too. You could argue Mutation Events from ~2011 qualifies¹; it was supplanted by Mutation Observers within two years, yet hung around for over a decade before being removed. As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.
And so here they are now planning to remove a well-entrenched (if not especially commonly used) feature against the clearly-expressed will of the actual developers, in a one year time frame.
—⁂—
¹ I choose to disqualify Mutation Events because no one ever finished their implementation: WebKit heritage never did DOMAttrModified, Gecko/Trident heritage never did DOMNodeInsertedIntoDocument or DOMNodeRemovedFromDocument. Flimsy excuse, probably. If you want to count it, perhaps you’ll agree to consider XSLT the first time a major, standard, baseline-available feature will be removed?
And XSL is used to validate invoice documents.
In 19th century Russia there was a thinker, N. F. Fedorov, who wanted to revive all dead people. He saw it as the ultimate goal of humanity. (He worked in a library, a very telling occupation. He spent most of what he earned to support others.) We do not know how to revive dead people or if we can do that at all; but we certainly can revive old tech or just not let it die.
Of course, this job is not for everyone. We cannot count on the richest, apparently, they're too busy getting richer. This is a job for monks.
I think it is because nobody, excepts a handful of people around the world, feels the need to use XSLT in lieu of CSS. Hence, CSS has evolved over time while XSLT has not.
This is how the world works: technology advances and old things become obsolete over time.
The question isn't whether or not you use XSLT yourself, it's whether you use a different feature that could be deemed unprofitable and slammed on the chopping block. And therefore a question of whether it wouldn't be better for everyone for this work to be publicly funded instead.
It is true that public bodies are less concerned with profitability, which changes how they make decisions around deprecations and removals, but being cost-effective is still important for them, especially when budgets are low and need is high. In situations like that, it's not uncommon for, say, a service to get cut so that funding can be reallocated elsewhere where it's more needed.
I don't think publicly funding this sort of work would necessarily significantly change the equation here. The costs of XSLT are relatively high because of its complexity and the natural security risks that arise from that complexity. Meanwhile, it is very rarely used, and where it is used, there are better alternatives (generally loading a sandboxed library rather than using the built-in tooling).
XSLT lets you build completely static websites without having to use copy paste or a static website generator to handle the common stuff like menus.
http://www.blogabond.com/xsl/vistacular.xml
The upside is that the entire html page is content. I defy google to not figure out what to index here:
view-source:http://www.blogabond.com/xsl/vistacular.xml
The downside is everything else about the experience. Hence my 15 years of not bothering to implement it in a usable way.
Google pays people to destroy the open web, not improve it. These Google engineers are pathetic and should be ashamed of their inept laziness.
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. [..]
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user [paying for that saving on costs by some big company - or having to redo NOW in less efficient way something that still works well so far regardless of decades passed] !
https://news.ycombinator.com/item?id=44994459 - with answering lame questions of a developer not having a clue what is all about.
(Just.. live and let others live too ? Thx.)
Moreover.. Content First - and browser is a secondary thing to existing content (Chrome came after) - not the (double) opposite (primary, for ads n tracking instead)
- isn't Google as a public servant - so part of their job is to fix their bugs - but not in the position to decide to kill someone else existing content or solution - for not displaying ads so easy?
Google's unilaterally tries to kill part of the web that not let them track or profit from ads so easy ?
.. and with all that money they get (and brains), still to lazy to fix few old bugs (stuck at old version).
now how about that:
Chrome voluntarily decides to disjoint self from parts of the web where it can't take profits - saying they are not in fashion ..
- and if then, actually no one would like to have to follow ever again anything like that ?. (ocean is _big_ and.. blue)
Where XSLT shines, and JavaScript currently has no equivalent afaik, is in transforming a tree into another one, rule-based.
The lack of support of XSLT 2.0 in browsers is a major issue, as it includes many solutions to problems absolutely not covered by XSLT 1.0.
[1]: xml2dict/dict2xml is an implementation of exactly this duality.
Now, do you need XSLT’s capabilities in the browser? Their stats say no one’s really using it.