10 ms·

Intent to Deprecate and Remove XSLT

87 points by CharlesW 1y ago

bugbuddy 1y ago
Good riddance. The web needs to shed all the old baggages like this to move forward. Looking forward to MCP becoming part of the browser.
- imiric 1y ago
  Wow, I couldn't disagree more. XSLT is no more "baggage" than HTML itself. Removing it in no way "moves the web forward". And integrating technologies part of the current hype cycle, which very well may disappear in a year, is a terrible idea.
29athrowaway 1y ago
XSLT is amazing.
- Kimitri 1y ago
  It really is. It's extremely handy albeit a bit niche these days.
  - 29athrowaway 1y ago
    XSLT is very useful to transform nested structures. The input has to be XML, but you can get there via YAML, JSON, tree-sitter etc. And the output doesn't have to be XML. xsltproc is usually easy to install.
codedokode 1y ago
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.
- bartread 1y ago
  Dude… no. Firstly, it puts a huge burden of non-value-adding work onto developers and the organisations they work for. Secondly it would lead to even higher frequency and prevalence of people inventing their own half-arsed ways of doing things that used to be in the box. Nobody would think about standard usability affordances, accessibility, etc. Thirdly, it would simply move the attack surface into an emergent library ecosystem without really solving anything. Fourthly, it would increase website payloads even further. Developers have historically been awful at using bandwidth efficiently (still a concern in many scenarios due to connectivity limitations and costs), and we don’t need to offer more opportunities for them to demonstrate how terrible and undisciplined they are at it. Fifthly, not everyone wants or needs (or should!) to learn web assembly in the same way that not everyone wants or needs to learn x86/64 assembly, ARM assembly, C or Rust. Sixthly, it would lead to a huge amount of retooling and rewriting which, yes, to some extent would happen anyway because, apparently, we all love endless churn masquerading as progress, but it would be considerably worse. The web would become significantly buggier and more unusable as a result of all of the above.
- sureglymop 1y ago
  I think it sounds good to have that "on top" of what's already there. So that those who want to can use a lower level abstraction.
- dwb 1y ago
  That sounds awful! For a start, accessibility would get even worse than it already is. The browser may become more “minimal” and “simple” from the point of view of the implementer, but certainly not the user.
- chrismorgan 1y ago
  On the off chance that by “canvas” you didn’t mean all rendering (which is a terrible idea for reasons addressed by others) but only what is currently covered by <canvas>—the frame buffer approach is incompatible with GPU acceleration, so 3D would basically not be possible. For better or for worse, WebGL is pretty close to the minimum acceptable for that kind of functionality.
- 1y ago
otterley 1y ago
This continues the saga discussed here: https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185
cassonmars 1y ago
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.
- MattPalmer1086 1y ago
  Was there ever a good reason for XSLT to be an XML document itself? It was painful writing it.
  - arwhatever 1y ago
    Yo dawg, I heard you like xml … so I made you an xml-based language to turn xml into other xml!
  - Mikhail_Edoshin 1y ago
    This way you can manipulate XSLT using XSLT. A common case is to generate XSLT.
    - MattPalmer1086 1y ago
      Clearly that would be possible, but I never actually saw anyone doing that though. Any pointers to tech that did this, if it was a common case?
      - Mikhail_Edoshin 1y ago
        I doubt it was common. But, for example, there is such thing as Schematron: this is a special notation that checks that an XML document follows business rules and the final tool that it produces is a custom XSLT that transforms the document into the report. (I'm also doing this currently; I need to prepare a sort of an annotated patch to an XML document, so I concocted a notation that describes edits and use it to generate both the documentation that highlights differences and also the patch itself; the patch comes out as XSLT.)
imiric 1y ago
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.
- ozim 1y ago
  I would expect governments finally taking over. I believe they didn’t just because most of politicians don’t know anything about software. Being aware of the problems that “governmatization” of open source can bring it still is something I expect to be picked up by countries.
- bawolff 1y ago
  People are free to make their own browser if they want. Part of the reason google chrome won the browser wars is because they are willing to make decisions like this. Kitchen sink software is bad software.
  - imiric 1y ago
    > People are free to make their own browser if they want. Some peple are doing that[1]. It's not a matter of desire, but of the amount of effort and resources required to build and maintain the insanity of the modern web stack. > Part of the reason google chrome won the browser wars is because they are willing to make decisions like this. Eh, no. Google Chrome won because it is backed by one of the largest adtech corporations with enough resources and influence to make it happen. They're better at this than Microsoft was with IE, but that's not saying much. When it launched it introduced some interesting and novel features, but it's now nothing but a marketing funnel for Google's services. [1]: https://ladybird.org/ https://ladybird.org/
chrismorgan 1y ago
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.com/articles/view/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?
- CamJN 1y ago
  Maybe the blink or marquee tags? I’m pretty sure those don’t work anymore...
  - chrismorgan 1y ago
    <marquee> still works fine. Better than it used to, honestly, as at least Firefox and Chromium removed the deliberate low frame rate at some point in the last decade. <blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20blink%20element%20type%20was,functional%20blink%20tag. https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>. > Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996. Fun times. Both essentially accusing the other of having a dumb tag.
Animats 1y ago
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.
- apimade 1y ago
  Why not just expose an HTML representation of the data? Why must it remain JSON, XML, CSV, Parquet, fixed length or tab delimited files, ProtoBuf, etc? API’s should provide content in the format asked of them. CSS should be used to style that content. This is largely solved in RFC-6838 which is about “how media types, representation and the interoperability problem is solved”. https://datatracker.ietf.org/doc/rfc6838/ https://datatracker.ietf.org/doc/rfc6838/ Already supported by .NET Web APIs, Django, Spring, Node, Laravel, RoR, etc. Less mature ecosystems like Golang have solutions, they’re just very much patch-work/RYO. Or even use OpenResty or njs in Nginx, which puts the transformation in the web service layer and not the web application layer. So your data might be JSON blob, it’ll convert to HTML in real-time. Something similar can be achieved elsewhere like Apache using mod_lua etc. I think bastardising one format (HTML), to support another format (JSON), is probably not the right move. We’ve already done that with stuff like media queries which have been abused for fingerprinting, or “has” CSS selectors for shitty layout hacks by devs who refuse to fix the underlying structure.
  - 1718627440 1y ago
    Because so you can separate the data from the layout. You can e.g. return a list of strings and then the strings become the summaries of a set of details elements.
    - apimade 1y ago
      The description you give inherently changes the structure of the data, and JavaScript would be the best way to post-process it. CSS is about styling the structure of HTML, not structural changes to it. Unless you have a good example, I think you’re coming at this from an “everything’s a nail if the only tool I have is a hammer”.
icameron 1y ago
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.
postepowanieadm 1y ago
In Europe some countries still use XML as the official data format and XSLT as the official code format.
- rhdunn 1y ago
  It's used a lot in the publishing industry, which stores the content in JATS and other similar XML markup. It's also used by the US government for bills, etc. Typically, these use XSLT on the backend to transform the content to HTML to be sent to the web browser. And there's RSS which was mentioned in the previous discussions. Podcasts will typically have HTML renderings of that data, but if you opened the RSS in a web browser you could use XSLT to provide a user-friendly view of the content. XSLT can also be used to provide fallback rendering for unsupported content, such as converting MathML to HTML for browsers without support. -- Chrome as of 109 supports MathML Core, but doesn't support the content markup (used for more semantic markup of common constructs like N-ary sum, integrals, etc.), so would still need something like XSLT to convert that markup to the presentation markup supported by Chrome.
- 0x000xca0xfe 1y ago
  Not just "still use", at least here in Germany our brand new e-invoicing system (mandatory since this year) is built on XML. And XSL is used to validate invoice documents.
  - ExoticPearTree 1y ago
    It's not only in Germany, it's an EU mandated thing to have e-invoicing to prevent fraud and whatever other things the bureaucrats in Brussels felt like it would be solved with technology. And yes, sadly the powers that be decided that this crap needs to be XML. Because why not, why use a modern standard...
    - Devasta 1y ago
      What about XML isn't modern? It's a far more capable format than JSON or anything else you can devise.
Mikhail_Edoshin 1y ago
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.
- heavyset_go 1y ago
  Pertinent to your point, he wanted to resurrect ancestors so that they, too, could participate in the general resurrection. The analogy being old technology resurrected to work alongside contemporary technology towards a shared goal.
- dtech 1y ago
  > good and working parts are removed The browser vendors are arguing XSLT is neither good - it's adoption has always been lacking because of complexity and has now become a niche technology because better alternatives exist - nor working, see the mentioned security and maintenance issues. I think they have a good point there.
  - Mikhail_Edoshin 1y ago
    Well, one can argue that Metafont fonts are "niche". No font library supports them. But from what I know they could easily be technically superior to, say, Type 1 fonts. Of course a technology will be niche if it is treated as a poor relative. XSLT could be an alternative to CSS, for example. It is definitely more powerful than CSS, because it actually transforms the document, not just alters the appearance and sprinkles some automatic content here and there. And is actually used this way in XSL-FO, which, I think, powers a substantial share of technical publishing.
solatic 1y ago
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.
- jmspring 1y ago
  I’m lost at “the public sector would have argued for some budget”. Xslt and libxslt are used across a no - trivial amount of deployments. Why would the public sector feel bound to support it as opposed to pivot in the same direction the winds are blowing? Outside the idiocy of this particular administration in the US, gov is pivoting toward more commercial norms (with compliance/etc for gov cloud and etc compliance).
  - solatic 1y ago
    > Why would the public sector feel bound to support it The underlying axiom is the Pareto principle - that you get 80% of the benefit from the first 20% of the work, and getting the last 20% of the benefit takes up 80% of the work. The private sector will stop funding after the first 80% of benefit (it's not profitable to chase the last 20%) but the public sector is usually mandated to support everybody so it is indeed required to put in that extra effort.
- MrJohz 1y ago
  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).
elric 1y ago
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.
- rhdunn 1y ago
  Part of the issue is that XSLT in the browser is stuck at version 1.0 so lacks a lot of the improvements added in 2.0 and later that make working with it a lot nicer.
  - sam_lowry_ 1y ago
    XSLT 2.0 is a failed spec, there is only one implementation by Michael Kay in the paid version of Saxon. And he was also the spec editor, his incentive was to get lucrative contracts from BigTech, not make the world a better place.
    - rhdunn 1y ago
      XSLT 2.0 is not a failed spec. From [1] RaptorXML (XSLT 3.0) and xjslt (XSLT 2.0) are listed as implementing that spec. MarkLogic also provides XSLT 2.0 support. Saxon has a free HE version [2] that has the source code available and implements XSLT 2.0 REC, 3.0 REC, and 4.0 ED at the baseline conformance. The paid version implements optional features and vendor-specific extensions [3]. Even though Michael Kay is the editor of the spec, several others are involved in the standardization of XSLT, XPath, and XQuery, including members from BaseX and eXist-db which provide XQuery implementations. And as XPath is a subset of XSLT and XQuery there's a lot of overlap there, and features come from many people, not just Michael Kay. [1] https://en.wikipedia.org/wiki/XSLT#Processor_implementations https://en.wikipedia.org/wiki/XSLT#Processor_implementations [2] https://www.saxonica.com/download/java.xml https://www.saxonica.com/download/java.xml [3] https://www.saxonica.com/products/products.xml https://www.saxonica.com/products/products.xml
jraph 1y ago
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.
- ErroneousBosh 1y ago
  > 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. How many people ever do this?
  - Mikhail_Edoshin 1y ago
    I did that. You can write .rst, then transform it into XML with 'rst2xml' and then generate both HTML and PDF (using XSL-FO). (I myself also did a little literate programming this way: I added a special reStructuredText directive to mark code snippets, then extracted and joined them together into files.)
  - spiffytech 1y ago
    If this is "declarative XSL Processing Instructions", apparently 0.001% of global page loads.
  - gregabbott 1y ago
    Plain text, markup and Markdown to HTML with XSLT: REPO: https://github.com/gregabbott/skip https://github.com/gregabbott/skip DEMO: https://gregabbott.pages.dev/skip https://gregabbott.pages.dev/skip (^ View Source: 2 lines of XML around a .md file)
    - paularmstrong 1y ago
      Parsing the XSLT file fails in Firefox :)
      - 1y ago
jasonkester 1y ago
Ah, shame. I always meant to expand on my little experiment here to ship 100% content pages to the client: http://www.blogabond.com/xsl/vistacular.xml 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 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.
- chrismorgan 1y ago
  > I defy google to not figure out what to index here: Easy: ignore due to no content-type header.
- thro1 1y ago
  cute :) (focused and instant)
swiftcoder 1y ago
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)
righthand 1y ago
They're keeping XPath but removing XSLT. What a joke. All these brilliant Google engineers and all this brilliant AI tooling and no one can fix XSLT. Google pays people to destroy the open web, not improve it. These Google engineers are pathetic and should be ashamed of their inept laziness.
deleted 1y ago
[deleted]
thro1 1y ago
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 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] ! https://news.ycombinator.com/item?id=44994459 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?
thro1 1y ago
How about that: 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).
- thro1 1y ago
  (?) - then more about the tactic: https://news.ycombinator.com/item?id=44994459 https://news.ycombinator.com/item?id=44994459 (web looks like nails for that tool we have) 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)
  - deleted 1y ago
    [deleted]
thro1 1y ago
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 ?
lolive 1y ago
JSON and XML are basically syntactic variant of the same data storage strategy [:tree of attributes and children]. [1] 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.
- ExoticPearTree 1y ago
  > The lack of support of XSLT 2.0 in browsers is a major issue, ... for who?
  - sam_lowry_ 1y ago
    XSLT 2.0 is a failed language, only Michael Kay could implement it in the paid version of Saxon and that because he was the editor if the spec, so he did as he pleased.
  - lolive 1y ago
    People stuck with XSLT 1.0 [or worse, javascript] as your tree transformation engine
    - indolering 1y ago
      Yeah, just because browser vendors put XML tech in maintenance mode doesn't mean that it wouldn't be nice to have. We might see real world usage of these technologies had browser vendors not frozen them out.
- sam_lowry_ 1y ago
  XML allows multiple trees in one file via namespaces, this is a big difference
Fileformat 1y ago
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.
- mbo 1y ago
  This is why I've needed to use XLST, to style my personal RSS feed. Great guide for this: https://andrewstiefel.com/style-atom-xsl/ https://andrewstiefel.com/style-atom-xsl/ Looks like it's been raised on the whatwg issue too: https://github.com/whatwg/html/issues/11523#issuecomment-3151679326 https://github.com/whatwg/html/issues/11523#issuecomment-315...
- whimsicalism 1y ago
  extremely important? i use rss a lot and i have never seen anyone do this
  - Fileformat 1y ago
    This is exactly my point: everyone here is tech-savvy and knows what to do with an RSS/Atom link. So we don't see a need for XSLT. But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish). XSLT is currently the only way to make feeds into something that can still be viewed. I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO). I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/ https://www.rss.style/ You can see it in action on an RSS feed here (served as real XML, not HTML): https://www.fileformat.info/news/rss.xml https://www.fileformat.info/news/rss.xml
joeiq 1y ago
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.
wosined 1y ago
Just leave it alone bro.
cess11 1y ago
In practice this means XSLT execution will be moved from clients to servers and I'm not so sure this is positive with regards to security.
thro1 1y ago
Moreover: there is no JS solution being so stable and for so long as that standard: "25 year old version of XSLT". Can be "made with JS" doesn't mean that by chance it would be in any bit better than long proved and still used solution - not a one of many crippled, always changing, excluding imitations of it - for example like that one: https://news.ycombinator.com/item?id=45183624 https://news.ycombinator.com/item?id=45183624 (no caching, not instant, transparent or othogonal etc.). With XSLT removed, Chrome can not claim to be a standard internet browser neither. There is nothing wrong with XSLT - it's just Google not wanting to fix few bugs since decades - but others have to follow, nothing changes. Actually.. I can't care less about Chrome - if others will not follow neither allow Google to reach such position claiming to be able to dastandardize working and used solutions.
- thro1 1y ago
  - as in Europe, I don't see neither how taxpayers money or users time (if still alive) could be forcibly used to cover the costs of some far away corporation savings (on bug fixing) and profit, downgrading then a lot into more costly, less maintainable, not standard solutions. But I see less of that money but much better used - to support any of open, independent, not for profit, conforming to standards browsers instead - in not following what a big corporation says and want.
- harrisi 1y ago
  For what it's worth, there does not exist a "standard internet browser," assuming that means an application that adheres to all relevant web standards. No piece of software exists (at least not publicly) that even adheres to the entirety of any single relevant web standard (e.g. HTML, CSS, ECMAScript, etc.), as far as I know. Maybe for a few small things like JSON, I suppose, but not for any of the major standards. And not just as in they implement a superset of the standards - every browser implements a distinct set of each standard that is neither a subset nor a superset. I'm still not a fan of Chrome nor the effect it has on the web.
  - thro1 1y ago
    The standard so far is to respect existing standards still in use, peoples effort and work done already - but not to outsource bug fixing costs by forcing any of that to be redone or lost.

87 points by CharlesW 1y ago

Good riddance. The web needs to shed all the old baggages like this to move forward. Looking forward to MCP becoming part of the browser.

imiric 1y ago
Wow, I couldn't disagree more. XSLT is no more "baggage" than HTML itself. Removing it in no way "moves the web forward". And integrating technologies part of the current hype cycle, which very well may disappear in a year, is a terrible idea.

29athrowaway 1y ago

XSLT is amazing.

Kimitri 1y ago
It really is. It's extremely handy albeit a bit niche these days.
- 29athrowaway 1y ago
  XSLT is very useful to transform nested structures. The input has to be XML, but you can get there via YAML, JSON, tree-sitter etc. And the output doesn't have to be XML. xsltproc is usually easy to install.

codedokode 1y ago

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.

bartread 1y ago
Dude… no. Firstly, it puts a huge burden of non-value-adding work onto developers and the organisations they work for. Secondly it would lead to even higher frequency and prevalence of people inventing their own half-arsed ways of doing things that used to be in the box. Nobody would think about standard usability affordances, accessibility, etc. Thirdly, it would simply move the attack surface into an emergent library ecosystem without really solving anything. Fourthly, it would increase website payloads even further. Developers have historically been awful at using bandwidth efficiently (still a concern in many scenarios due to connectivity limitations and costs), and we don’t need to offer more opportunities for them to demonstrate how terrible and undisciplined they are at it. Fifthly, not everyone wants or needs (or should!) to learn web assembly in the same way that not everyone wants or needs to learn x86/64 assembly, ARM assembly, C or Rust. Sixthly, it would lead to a huge amount of retooling and rewriting which, yes, to some extent would happen anyway because, apparently, we all love endless churn masquerading as progress, but it would be considerably worse. The web would become significantly buggier and more unusable as a result of all of the above.
sureglymop 1y ago
I think it sounds good to have that "on top" of what's already there. So that those who want to can use a lower level abstraction.
dwb 1y ago
That sounds awful! For a start, accessibility would get even worse than it already is. The browser may become more “minimal” and “simple” from the point of view of the implementer, but certainly not the user.
chrismorgan 1y ago
On the off chance that by “canvas” you didn’t mean all rendering (which is a terrible idea for reasons addressed by others) but only what is currently covered by <canvas>—the frame buffer approach is incompatible with GPU acceleration, so 3D would basically not be possible. For better or for worse, WebGL is pretty close to the minimum acceptable for that kind of functionality.
1y ago

otterley 1y ago

This continues the saga discussed here: https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185

cassonmars 1y ago

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.

MattPalmer1086 1y ago
Was there ever a good reason for XSLT to be an XML document itself? It was painful writing it.
- arwhatever 1y ago
  Yo dawg, I heard you like xml … so I made you an xml-based language to turn xml into other xml!
- Mikhail_Edoshin 1y ago
  This way you can manipulate XSLT using XSLT. A common case is to generate XSLT.
  - MattPalmer1086 1y ago
    Clearly that would be possible, but I never actually saw anyone doing that though. Any pointers to tech that did this, if it was a common case?
    - Mikhail_Edoshin 1y ago
      I doubt it was common. But, for example, there is such thing as Schematron: this is a special notation that checks that an XML document follows business rules and the final tool that it produces is a custom XSLT that transforms the document into the report. (I'm also doing this currently; I need to prepare a sort of an annotated patch to an XML document, so I concocted a notation that describes edits and use it to generate both the documentation that highlights differences and also the patch itself; the patch comes out as XSLT.)

imiric 1y ago

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.

ozim 1y ago
I would expect governments finally taking over. I believe they didn’t just because most of politicians don’t know anything about software. Being aware of the problems that “governmatization” of open source can bring it still is something I expect to be picked up by countries.
bawolff 1y ago
People are free to make their own browser if they want. Part of the reason google chrome won the browser wars is because they are willing to make decisions like this. Kitchen sink software is bad software.
- imiric 1y ago
  > People are free to make their own browser if they want. Some peple are doing that[1]. It's not a matter of desire, but of the amount of effort and resources required to build and maintain the insanity of the modern web stack. > Part of the reason google chrome won the browser wars is because they are willing to make decisions like this. Eh, no. Google Chrome won because it is backed by one of the largest adtech corporations with enough resources and influence to make it happen. They're better at this than Microsoft was with IE, but that's not saying much. When it launched it introduced some interesting and novel features, but it's now nothing but a marketing funnel for Google's services. [1]: https://ladybird.org/ https://ladybird.org/

chrismorgan 1y ago

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.com/articles/view/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?

CamJN 1y ago
Maybe the blink or marquee tags? I’m pretty sure those don’t work anymore...
- chrismorgan 1y ago
  <marquee> still works fine. Better than it used to, honestly, as at least Firefox and Chromium removed the deliberate low frame rate at some point in the last decade. <blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20blink%20element%20type%20was,functional%20blink%20tag. https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>. > Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996. Fun times. Both essentially accusing the other of having a dumb tag.

Animats 1y ago

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.

apimade 1y ago
Why not just expose an HTML representation of the data? Why must it remain JSON, XML, CSV, Parquet, fixed length or tab delimited files, ProtoBuf, etc? API’s should provide content in the format asked of them. CSS should be used to style that content. This is largely solved in RFC-6838 which is about “how media types, representation and the interoperability problem is solved”. https://datatracker.ietf.org/doc/rfc6838/ https://datatracker.ietf.org/doc/rfc6838/ Already supported by .NET Web APIs, Django, Spring, Node, Laravel, RoR, etc. Less mature ecosystems like Golang have solutions, they’re just very much patch-work/RYO. Or even use OpenResty or njs in Nginx, which puts the transformation in the web service layer and not the web application layer. So your data might be JSON blob, it’ll convert to HTML in real-time. Something similar can be achieved elsewhere like Apache using mod_lua etc. I think bastardising one format (HTML), to support another format (JSON), is probably not the right move. We’ve already done that with stuff like media queries which have been abused for fingerprinting, or “has” CSS selectors for shitty layout hacks by devs who refuse to fix the underlying structure.
- 1718627440 1y ago
  Because so you can separate the data from the layout. You can e.g. return a list of strings and then the strings become the summaries of a set of details elements.
  - apimade 1y ago
    The description you give inherently changes the structure of the data, and JavaScript would be the best way to post-process it. CSS is about styling the structure of HTML, not structural changes to it. Unless you have a good example, I think you’re coming at this from an “everything’s a nail if the only tool I have is a hammer”.

icameron 1y ago

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.

postepowanieadm 1y ago

In Europe some countries still use XML as the official data format and XSLT as the official code format.

rhdunn 1y ago
It's used a lot in the publishing industry, which stores the content in JATS and other similar XML markup. It's also used by the US government for bills, etc. Typically, these use XSLT on the backend to transform the content to HTML to be sent to the web browser. And there's RSS which was mentioned in the previous discussions. Podcasts will typically have HTML renderings of that data, but if you opened the RSS in a web browser you could use XSLT to provide a user-friendly view of the content. XSLT can also be used to provide fallback rendering for unsupported content, such as converting MathML to HTML for browsers without support. -- Chrome as of 109 supports MathML Core, but doesn't support the content markup (used for more semantic markup of common constructs like N-ary sum, integrals, etc.), so would still need something like XSLT to convert that markup to the presentation markup supported by Chrome.
0x000xca0xfe 1y ago
Not just "still use", at least here in Germany our brand new e-invoicing system (mandatory since this year) is built on XML. And XSL is used to validate invoice documents.
- ExoticPearTree 1y ago
  It's not only in Germany, it's an EU mandated thing to have e-invoicing to prevent fraud and whatever other things the bureaucrats in Brussels felt like it would be solved with technology. And yes, sadly the powers that be decided that this crap needs to be XML. Because why not, why use a modern standard...
  - Devasta 1y ago
    What about XML isn't modern? It's a far more capable format than JSON or anything else you can devise.

Mikhail_Edoshin 1y ago

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.

heavyset_go 1y ago
Pertinent to your point, he wanted to resurrect ancestors so that they, too, could participate in the general resurrection. The analogy being old technology resurrected to work alongside contemporary technology towards a shared goal.
dtech 1y ago
> good and working parts are removed The browser vendors are arguing XSLT is neither good - it's adoption has always been lacking because of complexity and has now become a niche technology because better alternatives exist - nor working, see the mentioned security and maintenance issues. I think they have a good point there.
- Mikhail_Edoshin 1y ago
  Well, one can argue that Metafont fonts are "niche". No font library supports them. But from what I know they could easily be technically superior to, say, Type 1 fonts. Of course a technology will be niche if it is treated as a poor relative. XSLT could be an alternative to CSS, for example. It is definitely more powerful than CSS, because it actually transforms the document, not just alters the appearance and sprinkles some automatic content here and there. And is actually used this way in XSL-FO, which, I think, powers a substantial share of technical publishing.

solatic 1y ago

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.

jmspring 1y ago
I’m lost at “the public sector would have argued for some budget”. Xslt and libxslt are used across a no - trivial amount of deployments. Why would the public sector feel bound to support it as opposed to pivot in the same direction the winds are blowing? Outside the idiocy of this particular administration in the US, gov is pivoting toward more commercial norms (with compliance/etc for gov cloud and etc compliance).
- solatic 1y ago
  > Why would the public sector feel bound to support it The underlying axiom is the Pareto principle - that you get 80% of the benefit from the first 20% of the work, and getting the last 20% of the benefit takes up 80% of the work. The private sector will stop funding after the first 80% of benefit (it's not profitable to chase the last 20%) but the public sector is usually mandated to support everybody so it is indeed required to put in that extra effort.
MrJohz 1y ago
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).

elric 1y ago

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.

rhdunn 1y ago
Part of the issue is that XSLT in the browser is stuck at version 1.0 so lacks a lot of the improvements added in 2.0 and later that make working with it a lot nicer.
- sam_lowry_ 1y ago
  XSLT 2.0 is a failed spec, there is only one implementation by Michael Kay in the paid version of Saxon. And he was also the spec editor, his incentive was to get lucrative contracts from BigTech, not make the world a better place.
  - rhdunn 1y ago
    XSLT 2.0 is not a failed spec. From [1] RaptorXML (XSLT 3.0) and xjslt (XSLT 2.0) are listed as implementing that spec. MarkLogic also provides XSLT 2.0 support. Saxon has a free HE version [2] that has the source code available and implements XSLT 2.0 REC, 3.0 REC, and 4.0 ED at the baseline conformance. The paid version implements optional features and vendor-specific extensions [3]. Even though Michael Kay is the editor of the spec, several others are involved in the standardization of XSLT, XPath, and XQuery, including members from BaseX and eXist-db which provide XQuery implementations. And as XPath is a subset of XSLT and XQuery there's a lot of overlap there, and features come from many people, not just Michael Kay. [1] https://en.wikipedia.org/wiki/XSLT#Processor_implementations https://en.wikipedia.org/wiki/XSLT#Processor_implementations [2] https://www.saxonica.com/download/java.xml https://www.saxonica.com/download/java.xml [3] https://www.saxonica.com/products/products.xml https://www.saxonica.com/products/products.xml

jraph 1y ago

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.

ErroneousBosh 1y ago
> 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. How many people ever do this?
- Mikhail_Edoshin 1y ago
  I did that. You can write .rst, then transform it into XML with 'rst2xml' and then generate both HTML and PDF (using XSL-FO). (I myself also did a little literate programming this way: I added a special reStructuredText directive to mark code snippets, then extracted and joined them together into files.)
- spiffytech 1y ago
  If this is "declarative XSL Processing Instructions", apparently 0.001% of global page loads.
- gregabbott 1y ago
  Plain text, markup and Markdown to HTML with XSLT: REPO: https://github.com/gregabbott/skip https://github.com/gregabbott/skip DEMO: https://gregabbott.pages.dev/skip https://gregabbott.pages.dev/skip (^ View Source: 2 lines of XML around a .md file)
  - paularmstrong 1y ago
    Parsing the XSLT file fails in Firefox :)
    - 1y ago

jasonkester 1y ago

Ah, shame. I always meant to expand on my little experiment here to ship 100% content pages to the client: http://www.blogabond.com/xsl/vistacular.xml 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 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.

chrismorgan 1y ago
> I defy google to not figure out what to index here: Easy: ignore due to no content-type header.
thro1 1y ago
cute :) (focused and instant)

swiftcoder 1y ago

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)

righthand 1y ago

They're keeping XPath but removing XSLT. What a joke. All these brilliant Google engineers and all this brilliant AI tooling and no one can fix XSLT. Google pays people to destroy the open web, not improve it. These Google engineers are pathetic and should be ashamed of their inept laziness.

deleted 1y ago

[deleted]

thro1 1y ago

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

thro1 1y ago

How about that: 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).

thro1 1y ago
(?) - then more about the tactic: https://news.ycombinator.com/item?id=44994459 https://news.ycombinator.com/item?id=44994459 (web looks like nails for that tool we have) 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)
- deleted 1y ago
  [deleted]

thro1 1y ago

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 ?

lolive 1y ago

JSON and XML are basically syntactic variant of the same data storage strategy [:tree of attributes and children]. [1] 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.

ExoticPearTree 1y ago
> The lack of support of XSLT 2.0 in browsers is a major issue, ... for who?
- sam_lowry_ 1y ago
  XSLT 2.0 is a failed language, only Michael Kay could implement it in the paid version of Saxon and that because he was the editor if the spec, so he did as he pleased.
- lolive 1y ago
  People stuck with XSLT 1.0 [or worse, javascript] as your tree transformation engine
  - indolering 1y ago
    Yeah, just because browser vendors put XML tech in maintenance mode doesn't mean that it wouldn't be nice to have. We might see real world usage of these technologies had browser vendors not frozen them out.
sam_lowry_ 1y ago
XML allows multiple trees in one file via namespaces, this is a big difference

Fileformat 1y ago

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.

mbo 1y ago
This is why I've needed to use XLST, to style my personal RSS feed. Great guide for this: https://andrewstiefel.com/style-atom-xsl/ https://andrewstiefel.com/style-atom-xsl/ Looks like it's been raised on the whatwg issue too: https://github.com/whatwg/html/issues/11523#issuecomment-3151679326 https://github.com/whatwg/html/issues/11523#issuecomment-315...
whimsicalism 1y ago
extremely important? i use rss a lot and i have never seen anyone do this
- Fileformat 1y ago
  This is exactly my point: everyone here is tech-savvy and knows what to do with an RSS/Atom link. So we don't see a need for XSLT. But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish). XSLT is currently the only way to make feeds into something that can still be viewed. I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO). I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/ https://www.rss.style/ You can see it in action on an RSS feed here (served as real XML, not HTML): https://www.fileformat.info/news/rss.xml https://www.fileformat.info/news/rss.xml

joeiq 1y ago

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.

wosined 1y ago

Just leave it alone bro.

cess11 1y ago

In practice this means XSLT execution will be moved from clients to servers and I'm not so sure this is positive with regards to security.

thro1 1y ago

Moreover: there is no JS solution being so stable and for so long as that standard: "25 year old version of XSLT". Can be "made with JS" doesn't mean that by chance it would be in any bit better than long proved and still used solution - not a one of many crippled, always changing, excluding imitations of it - for example like that one: https://news.ycombinator.com/item?id=45183624 https://news.ycombinator.com/item?id=45183624 (no caching, not instant, transparent or othogonal etc.). With XSLT removed, Chrome can not claim to be a standard internet browser neither. There is nothing wrong with XSLT - it's just Google not wanting to fix few bugs since decades - but others have to follow, nothing changes. Actually.. I can't care less about Chrome - if others will not follow neither allow Google to reach such position claiming to be able to dastandardize working and used solutions.

thro1 1y ago
- as in Europe, I don't see neither how taxpayers money or users time (if still alive) could be forcibly used to cover the costs of some far away corporation savings (on bug fixing) and profit, downgrading then a lot into more costly, less maintainable, not standard solutions. But I see less of that money but much better used - to support any of open, independent, not for profit, conforming to standards browsers instead - in not following what a big corporation says and want.
harrisi 1y ago
For what it's worth, there does not exist a "standard internet browser," assuming that means an application that adheres to all relevant web standards. No piece of software exists (at least not publicly) that even adheres to the entirety of any single relevant web standard (e.g. HTML, CSS, ECMAScript, etc.), as far as I know. Maybe for a few small things like JSON, I suppose, but not for any of the major standards. And not just as in they implement a superset of the standards - every browser implements a distinct set of each standard that is neither a subset nor a superset. I'm still not a fan of Chrome nor the effect it has on the web.
- thro1 1y ago
  The standard so far is to respect existing standards still in use, peoples effort and work done already - but not to outsource bug fixing costs by forcing any of that to be redone or lost.