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