> As of the next version of Chrome, XSLT will be gated behind a flag.

Citation? That would greatly surprise me in its abruptness and severity (they only just started talking about it this month, and acknowledge it’s particularly risky for enterprise) and https://chromestatus.com/feature/4709671889534976 gives no such indication.

▲

shakna 2 days ago | parent [-]

The meeting referenced there, from March not last month, also gives no indication that they'd go ahead and make any moves - "stick a pin in it". But they did anyway. [0]

panos: next item, removing XSLT. There are usage numbers.

stephen: I have concerns. I kept this up to date historically for Chromium, and I don't trust the use counters based on my experience. Total usage might be higher.

dan: even if the data were accurate, not enough zeros for the usage to be low enough.

mason: is XSLT supported officially?

simon: supported

mason: maybe we could just mark it deprecated in the spec, to make the statement that we're not actively working on it.

brian: we could do that on MDN too. This would be the first time we have something baseline widely available that we've marked as removed.

dan: maybe we could offer helpful pointers to alternatives that are better, and why they're better.

panos: maybe a question for olli. But I like brian's suggestion to mark it in all the places.

dan: it won't go far unless developers know what to use instead.

brian: talk about it in those terms also. Would anyone want to come on the podcast and talk about it? I'm guessing people will have objections.

emilio: we have a history of security bugs, etc.

stephen: yeah that was a big deal

mason: yeah we get bugs about it and have to basically ignore them, which sucks

brian: people do use it and some like it

panos: put a pin in it, and talk with olli next time?

panos: next thing is file upload control rendering

[0] https://github.com/whatwg/html/issues/11146#issuecomment-275...

▲

magicalist 2 days ago | parent | next [-]

> But they did anyway.

Did what? The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome, but you forgot to add that. As best as I can tell, the GP is right and you're confused.

▲

troupo a day ago | parent [-]

Tracking issue: https://issues.chromium.org/issues/435623334

Add flag to disable XSLT: https://chromium-review.googlesource.com/c/chromium/src/+/68...

It's approved, I don't know which release it will be.

Additionally, quote from the GitHub discussion:

--- start quote ---

Q: why has Chrome already started working on removing the feature from the browser?

A: To explore the effects of removal. It's hard to tell what will break without being able to turn it off and see.

https://github.com/whatwg/html/issues/11582#issuecomment-320...

--- end quote ---

▲

afavour a day ago | parent [-]

> The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome

> Add flag to disable XSLT

Two very different things. OP is talking about XSLT support going behind a flag, you’re citing XSLT deprecation going behind a flag. The default state matters (and the default state is undeprecated)

It makes sense that the Chrome team would do what they’re doing, otherwise it’s very difficult for anyone to assess the impact of XSLT deprecation.

▲

chrismorgan a day ago | parent | next [-]

I’d reword that: Google haven’t deprecated it (yet), they’ve added a flag whereby you can disable it (which, at this stage, is only being used by a test).

“Deprecate” has a specific meaning, largely unrelated to actual removal (though depending on the convention it may be expected to lead to it after some time).

▲

troupo a day ago | parent | prev [-]

> OP is talking about XSLT support going behind a flag, you’re citing XSLT deprecation going behind a flag.

Literally from my link:

--- start quote ---

Add a feature flag to disable XSLT

This adds a feature flag that disables:

- XSLTProcessor

- XSLT Processing Instructions

--- end quote ---

	▲	afavour a day ago \| parent [-]
		Literally from my comment: > The default state matters (and the default state is undeprecated) OP said “ But they did anyway”, and they did not

▲

chrismorgan 2 days ago | parent | prev [-]

By “started talking about it this month” I meant this specific advocation for removing it. Yes, it’s been talked about for years, but this time it’s specific.

▲

shakna 2 days ago | parent [-]

> brian: we could do that on MDN too. This would be the first time we have something baseline widely available that we've marked as removed.

They were advocating for removing it. And it was specific. And is labelled by the Chromium report you mentioned as the cause.

It wasn't "this month".

▲

chrismorgan a day ago | parent [-]

Again, that’s prior discussion. It’s happened a few times over the last few years.

Then another few months pass, and one of the agitators goes about formally proposing removing it, so that finally it isn’t just murmurings more or less behind closed doors, but out in public for the developers to clamour about. That’s where we are this month.

▲

shakna a day ago | parent [-]

Again, that prior discussion that you're dismissing as irrelevant - is the discussion the Chromium report links to! I don't think that can really get more definitive as cause and effect.

▲

chrismorgan a day ago | parent [-]

I’m not calling it irrelevant, just not part of the actual proposal and ensuing furore, which began this month. We discover there have been mutterings of this for years, and certainly those things led up to it, but this was the first public intimation. They don’t ever say “hi public, we know this is the first you’ve heard about it, but we’re removing a major feature next month”, which is basically what you were claiming (or what it amounted to). Far simpler and less controversial changes have taken many months to be shipped.

	▲	shakna 14 hours ago \| parent [-]
		Again, Google themselves say it was part of the discussion and where things started. So why do you know better than the Chromium team?