Comment by troupo

Comment by troupo 11 hours ago

4 replies

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 10 hours ago

> 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 5 hours ago

    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 9 hours ago

    > 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 8 hours ago

      Literally from my comment:

      > The default state matters (and the default state is undeprecated)

      OP said “ But they did anyway”, and they did not