Comment by magicalist
14 hours ago
> 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.
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 ---
> 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.
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).
> 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 ---
1 reply →