"Remove mentions of XSLT from the html spec"

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.

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

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.

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.

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.

[dead]

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

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.

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

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

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

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.

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.

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

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.

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

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

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

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

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

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.

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

> Does it include unanimous support from browser projects

They could continue supporting XSLT if they wanted.

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

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

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'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.

I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it.

I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it.

Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.

> > ChromeOS is for all practical purposes, the web

I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.

Probably labeling a removal of a format (which is somewhat niche anyway) as "killing the open web" was a bit hyperbolic and not entirely warranted in this case.

Imagine that tomorrow, Google announces plans to stop supporting HTML and move everyone to its own version of "CompuServe", delivered only via Google Fiber and accessible only with Google Chrome. What headline would you suggest for that occasion? "Google is killing the open web" has already been used today on an article about upcoming deprecation of XSLT format.

Users flagged it. We can only guess why users flag things. Perhaps it was the baity title.

I've taken the flags off that post now.

Companies use the same tactics as some states, bot campaigns, etc. The aim is to suppress, or at least diminish, the voices of opposition.

The flagged post is a perfect example. It contains just a fraction of factual information, but it was enough for bot farms to engage. Manipulators get mad at truth.

[flagged]

It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.

That assumes the server has a lot of additional CPU power to serve the content as HTML (and thus do the templating server side), whereas with XSLT I can serve XML and the XSLT and the client side can render the page according to the XSLT.

The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.

> Serving a server-generated HTML page could be even faster.

Except it isn't.

Lots of things could be faster than they are.

Maybe but PR author, who created the Issue there as well, gave example: 'JSON+React'. 'React' one of the slowest framework out there. Performance is rarely considered in contemporary front-end.

I think you're confusing throughput with latency.

You're right nobody processes a million DOM nodes with XSLT in a browser, but you're wrong about everything else: WASM has a huge startup cost.

Consider applying stylesheet properties: XSLT knows exactly how to lay things out so it can put all of the stylesheet properties directly on the element. Pre-rendered HTML would be huge. CSS is slow. XSLT gets you direct-attach, small-payload, and low-latency display.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

It is actively used today.

I get what you're saying, but following this line of reasoning would mean that successful, wide-spread specifications, standards, and technologies must never drop any features. They would only ever accumulate new features, bloating to the point of uselessness, and die under the weight of their own success.

I don't understand how this is any more fair to Google than the quoted statement.

almost same. wrote a xml cms and then the xslt into html... then realized I would have to continue to write xml and said hell no! and rewrote the whole thing with php and a mysql db.