Comment by spankalee

Disclaimer: I work on Chrome/Blink and I've also contributed a (very small) number of patches to libxml/libxslt.

It's not just a matter of replacing the libxslt; libxslt integrates quite closely with libxml2. There's a fair amount of glue to bolt libxml2/libxslt on to Blink (and WebKit); I can't speak for Gecko.

Even when there's no work on new XML/XSLT features, there's a passive cost to just having that glue code around since it adds quirks and special cases that otherwise wouldn't exist.

> Xee implements modern versions of these specifications, rather than the versions released in 1999.

My understanding is that browsers specifically use the 1999 version and changing this would break compat

I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues.

To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute.

To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest.

Google may have a lot of control over the web, but note that WEI still didn't ship.

WhatWG has a fairly well documented process for feature requests. Issues are not usually decided in closed meetings. But there’s a difference between constructive discussion and the stubborn shameless entitlement that some members of the community are displaying in their comments.

https://blog.whatwg.org/staged-proposals-at-the-whatwg

Fwiw the meetings aren't closed, unlike w3c the whatwg doesn't require paid membership to attend.

The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread.

Ultimately the way the community can influence decisions is to not be completely unhinged.

Like someone else said the other way would be to just use XSLT in the first place.

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation.

Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero.

I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect?

[1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.

Community feedback is usually very ad hoc. Platform PMs will work with major sites, framework maintainers, and sometimes do discussions and polls on social sites. IOW, they try to go where the community that uses the features are, rather than stay on GitHub in the spec issues.

[dead]

There isn't one. It's Google's web now. You should be thankful that you are still allowed to use it.

> I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file.

HTTP has already had this since the 90s. Clients send the Accept HTTP header indicating which format they want and servers can respond with alternative representations. You can already respond with HTML for browsers and XML for other clients today. You don’t need the browser to know how to do the transformation.

I actually found that particular response to be quite disappointing. It should give pause to those advocating removal of XSLT that these three totally disparate use cases could already be gracefully handled by a single technology which is:

* side effect free (a pure data to data transformation)

* stable, from a spec perspective, for decades

* completely client-side

Isn't this basically an A+ report card for any attempt at making a powerful general tool? The fact that the suggested solution in the absence of XSLT is to toil away at implementing application-specific solutions forever really feels like working toward the wrong direction.

Purely out of curiosity, what are some websites that actually make use of XSLT?

Isn't this theoretically already supported by the standards? The client supplies an Accept content type, and if that is html not xml the server should render it appropriately.

You can include a "link" HTTP header similar to a link tag. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

This would work without special syntax in the XML file.

Any solution that requires any change to the websites affected, no matter how small, is not a solution at all. DO. NOT. BREAK. THE. WEB.

Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs.

Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance:

- libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes.

- libxslt reaches into libxml and reuses fields in creative ways, e.g. libxml2's `xmlDoc` has a `compression` field that is ostensibly for storing the zlib compression level [1], but libxslt has co-opted it for a completely different purpose [2].

- There's a lot of missing institutional knowledge and no clear place to go for answers, e.g. what does a compile-time flag that guards "refactored parts of libxslt" [3] do exactly?

[1] https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f3...

[2] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...

[3] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...

That same argument applies to numerous web technologies, though.

Applied to each individually it seems to make sense. However the aggregate effect is kill off a substantial portion of the web.

In fact, it's an argument to never add a new web technology: Should 100% of web users be made vulnerable to bugs in a new technology that 0% of the people are currently using?

Plus it's a false dichotomy. They could instead address XSLT security... e.g., as various people have suggested, by building in the XSLT polyfill they are suggesting all the XSLT pages start using as an alternative.

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

If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are trying to have the browser replace the whole OS.

Solutions have been proposed in that threads, including adding the XSLT polyfill to the browser (which would run it in the Javascript VM/sandbox).

If the usage/risk of XSLT is enough to remove it, you'd have to remove webusb, webbluetooth, webmidi, webxr, and countless more

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.

One is a browser. The other is an ad delivery platform which requires a more strategic active development posture.

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

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

XSLT was awesome back in the day. You could get a block of XML data from the server, and with a bit of very simple scripting, slice it, filter it, sort it, present summary or detail views, generate tables or forms, all without a server round trip. This was back in IE6 days, or even IE5 with an add-on.

We built stuff with it that amazed users, because they were so used to the "full page reload" for every change.

> Probably there are a handful of legacy corporate users hanging on to it for dear life.

Like more or less everyone that hosts podcasts. But the current trend is for podcast feeds to go away, and be subsumed into Spotify and YouTube.

> Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)

And those that would replace you might care more for the web rather than the next performance review.

+1. I worked on an internal corporate eCommerce in 2005 built entirely on DOM + XSLT to create the final HTML. It was an atrocious pain in the neck to maintain (despite being server side so the browser never had to deal with the XSLT). Unless you still manipulate XML and need to transform it in various other formats through XSLT/XSL-FO, I don’t see why anyone would bother with it. It always cracks me up when people « demand » support for features hardly ever used for which they won’t spend a dime or a minute to help

Well, every browser engine that is part of WHATWG. That's how working groups... work. The current crop of "not Chrome/Firefox/Webkit" aren't typically building their own browser engines though. They're re-skinning Chromium/Gecko/Webkit.

The reckless, infinite scope of web browsers https://drewdevault.com/2020/03/18/Reckless-limitless-scope....

> Does it include unanimous support from browser projects

They could continue supporting XSLT if they wanted.

This makes the job of smaller engines like Servo and Ladybird a lot easier.

It's not a huge conspiracy, but it is worthwhile to consider what the incentives are for people from each browser vendor. In practice all the vendors probably have big backlogs of work they are struggling to keep up with. The backlogs are accumulating in part because of the breakneck pace at which new APIs and features are added to the web platform, and in part because of the unending torrent of new security vulnerabilities being discovered in existing parts of the platform. Anything that reduces the backlog is thus really appealing, and money doesn't have to change hands.

Arguably, we could lighten the load on all three teams (especially the under-resourced Firefox and Safari teams) by slowing the pace of new APIs and platform features. This would also ease development of browsers by new teams, like Servo or Ladybird. But this seems to be an unpopular stance because people really (for good reason) want the web platform to have every pet feature they're an advocate for. Most people don't have the perspective necessary to see why a slower pace may be necessary.

>I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare.

This has never ever made sense because Mozilla is not at all afraid to piss in Google's cheerios at the standards meetings. How many different variations of Flock and similar adtech oriented features did they shoot down? It's gotta be at least 3. Not to mention the anti-fingerprinting tech that's available in Firefox (not by default because it breaks several websites) and opposition to several Google-proposed APIs on grounds of fingerprinting. And keeping Manifest V2 around indefinitely for the adblockers.

People just want a conspiracy, even when no observed evidence actually supports it.

>And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.

That's basically true whether incidentally or on purpose.

There are countries like Germany where Firefox still has around 10% market share [0], or closer to 20% on the desktop, only second behind Chrome [1]. Not exactly irrelevant.

[0] https://gs.statcounter.com/browser-market-share/all/germany

[1] https://gs.statcounter.com/browser-market-share/desktop/germ...

It has long seemed like Firefox is likely doing Google's bidding? That could be a reason why they're given a full vote?

/abject-speculation

> Did anybody bother checking with Microsoft?

> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?

The juxtaposition of these two statements is very funny.

Firefox actually develops a browser, Microsoft doesn't. That's why Firefox gets a say and Microsoft doesn't. Microsoft jumped off the browser game years ago.

No, changing the search engine from Google to Bing in chromium doesn't count.

Ultimately, Microsoft isn't implementing jack shit around XSLT because they aren't implementing ANY web standards.

"Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?"

There was not really a vote in the first place and FF is still dependant on google. Otherwise FF (users) represants a vocal and somewhat influental minority, capable of creating shitstorms, if the pain level is high enough.

Personally, I always thought XSLT is somewhat weird, so I never used it. Good choice in hindsight.

Maybe because Edge is just a wrapper around Blink?

> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?

Ironic, considering the market share of XSLT.

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.

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.

Does that library use the browser's xslt?

I'm curious as to the scope of the problem, if html spec drops xslt, what the solutions would be; I've never really used xslt (once maybe, 20 years ago). In addition to just pre-rendering your webpage server-side, I assume another possible solution is some javascript library that does the transformations, if it needed to be client-side?

Found a js-only library, so someone has done this before: https://www.npmjs.com/package/xslt-processor

Hmm, I don't see the LOC listed here among the top sites: https://chromestatus.com/metrics/feature/timeline/popularity... - where are you seeing the Library of Congress as impacted?

>Chrome telemetry underreports a lot of use cases Sure; in that case, I would suggest to the people with those use cases that they should stop switching off telemetry. Everyone on HN seems to forget telemetry isn't there for shits and giggles, it's there to help improve a product. If you refuse to help improve the product, don't expect a company to improve the product for you, for free.

First, we are an insignificant portion of the web, and it's okay to admit that.

Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.