Intent to Deprecate and Remove: XSLT (Again)

[Dominic Cooney]

Primary eng email

domi...@chromium.org

Summary

XSLT is a declarative language for transforming XML. Transforming XML into HTML is a typical use on the web. XSLT 1.0 is implemented in Blink, although it’s incomplete. (xsl:include does not work, for example.) Our implementation has been described by users as “far too slow in practice” and “the worst of them all”.

Unfortunately the situation looks unlikely to improve. Adam Barth proposed removing XSLT from Blink two years ago, but we instead investigated alternatives to removing it. We found those alternatives infeasible. We reduced the complexity of the integration in Source/core, but we couldn’t justify larger improvements given the Blink project’s priorities.

Meanwhile, the world has moved on. XSLT 2.0 became a W3C Recommendation in 2007 and XSLT 3.0 reached Last Call in 2014, while relative usage of XSLT 1.0 in Blink has halved since Adam’s 2013 Intent to Deprecate and Remove: XSLT message.

Motivation

I want to remove XSLT to make the binary smaller (up to about 0.5 MB smaller, depending on the platform), make the attack surface smaller, eliminate the maintenance burden of updating the library (which we did rarely in practice), and give us more flexibility in how Blink handles XML.

Compatibility Risk

The specific change I am proposing is (1.) to stop handling <?xml-stylesheet …?> processing instructions in XML documents, and (2.) to remove the XSLTTransform object. These are supported by most browsers so this change reduces compatibility.

I am not proposing any larger changes to XML or XPath.

Alternative implementation suggestion for web developers

Web developers can use a library which implements XSLT. There are client-side libraries and server-side libraries which implement XSLT.

Usage information from UseCounter [1; 2]

Removing support for XSLT will affect less than 0.01% of page views.

There’s a theory that these particular counters are inaccurate because users who use XSLT are less likely to contribute data. The best thing to do is to proceed carefully. We can discuss separately how to do that.

OWP launch tracking bug

Issue 514995

Entry on the feature dashboard

https://www.chromestatus.com/features/4730954895589376

Requesting approval to remove too?

Yes.

Read the original thread before replying so that we can have a focused discussion. I have studied every message in that thread in detail.

[Jochen Eisinger]

+Drew Wilson

[Philip Jägenstedt]

Dominic, what timing do you have in mind? Given how negative the feedback was on the original thread, an unusually long deprecation period seems warranted, and it would be good to state a firm date in the deprecation message.

+Drew Wilson

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[m...@rouvenwessling.de]

I have no attachment to XSLT, but is it really necessary to remove <?xml-stylesheet …?>? While rarely used, it's sometimes nice to have XML files that still look somewhat nice when viewed in a browser.

[Dominic Cooney]

(Mending threads.)

w...@rouvenwessling.de wrote:

<snip>

I have no attachment to XSLT, but is it really necessary to remove <?xml-stylesheet …?>? While rarely used, it's sometimes nice to have XML files that still look somewhat nice when viewed in a browser.

</snip>

I recognize that removing <?xml-stylesheet ...?> causes more pain for authors. They will probably need to make changes on the server, because XML documents do not run scripts on the client. Whereas authors could use a polyfill to replace XSLTTransform because that's a context where they're already using script.

However only by removing both do we achieve significant benefits. If we removed XSLTTransform alone we would still need to maintain an XSLT implementation for <?xml-stylesheet ...?>. I learned the peril of partial deprecation the hard way: I am the unfortunate person who removed Attr.ownerElement thinking it represented progress to making Attrs no longer be full-blown Nodes. However removing ownerElement alone did not simplify the codebase and inevitably broke some sites. Eventually Eric Seidel cleaned up my mess and put it back. (Sorry, everyone.)

On Wed, Jul 29, 2015 at 8:40 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Dominic, what timing do you have in mind? Given how negative the feedback was on the original thread, an unusually long deprecation period seems warranted, and it would be good to state a firm date in the deprecation message.

I don't have a plan yet. I was thinking of asking people who support Chrome in enterprises about the updating habits of enterprise users. Say that N milestones will reach a reasonable number of them. Then I was thinking we could:

1. Let a deprecation message bake for N milestones.

2. Turn off XSLT by default, but with the option to re-enable it with a flag for an additional milestone (or two, or N.)

3. Remove XSLT entirely.

An alternative would be to advertise that we will remove XSLT as soon as use dips below a certain level (say, half the current level.) This encourages users to report use counters, and it encourages authors who can move to start heading for the exits.

[Dominic Cooney]

On Thu, Jul 30, 2015 at 8:54 AM, Dominic Cooney <domi...@chromium.org> wrote:

(Mending threads.)

w...@rouvenwessling.de wrote:

[Jeremy Roman]

To clarify, do you mean using <?xml-stylesheet ...?> to load an XSLT stylesheet, or a CSS stylesheet?

[Dominic Cooney]

(Mending more threads.)

jbroman wrote: To clarify, do you mean using <?xml-stylesheet ...?> to load an XSLT stylesheet, or a CSS stylesheet?

I mean using <?xml-stylesheet ...?> to load an XSLT stylesheet. There are a bunch of random MIME types that we treat as XSLT.

[Elliott Sprehn]

I think this question was about CSS support in <?xml-stylsheet which I don't think we should be trying to remove with this intent, only xslt support in processing instructions.

http://www.w3.org/Style/styling-XML.en.html

CSS in processing instructions is not a particularly large burden on the engine.

[m...@rouvenwessling.de]

On Thursday, July 30, 2015 at 3:37:51 AM UTC+2, Elliott Sprehn wrote:

I think this question was about CSS support in <?xml-stylsheet which I don't think we should be trying to remove with this intent, only xslt support in processing instructions.

http://www.w3.org/Style/styling-XML.en.html

CSS in processing instructions is not a particularly large burden on the engine.

Correct. The original mail sounded like <?xml-stylesheet would be removed completely, if that's not the case, than I don't have any concerns.

[Philip Jägenstedt]

On Thu, Jul 30, 2015 at 1:54 AM, Dominic Cooney <domi...@chromium.org> wrote:

On Wed, Jul 29, 2015 at 8:40 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Dominic, what timing do you have in mind? Given how negative the feedback was on the original thread, an unusually long deprecation period seems warranted, and it would be good to state a firm date in the deprecation message.

I don't have a plan yet. I was thinking of asking people who support Chrome in enterprises about the updating habits of enterprise users. Say that N milestones will reach a reasonable number of them. Then I was thinking we could:

1. Let a deprecation message bake for N milestones.

2. Turn off XSLT by default, but with the option to re-enable it with a flag for an additional milestone (or two, or N.)

3. Remove XSLT entirely.

Concretely, does that mean that the deprecation message would say something like "XSLT is deprecated. It will be disabled by default in M46+N and removed in M46+2N"?

I think a reasonable range for N is between 2 (remove in 6 months) and 4 (remove in 12 months), but it'd be great to know what the Chrome enterprise teams thinks.

 

An alternative would be to advertise that we will remove XSLT as soon as use dips below a certain level (say, half the current level.) This encourages users to report use counters, and it encourages authors who can move to start heading for the exits.

I'm somewhat skeptical of this, when usage is this low the deprecation messages are very unlikely to be seen and acted upon, so usage may not drop to half the current level in any reasonable time. In the worst case, some will vote against the removal by deliberately hitting the use counter with new XSLTProcessor()...

Philip

[Dominic Cooney]

On Thu, Jul 30, 2015 at 6:38 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Jul 30, 2015 at 1:54 AM, Dominic Cooney <domi...@chromium.org> wrote:

On Wed, Jul 29, 2015 at 8:40 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Dominic, what timing do you have in mind? Given how negative the feedback was on the original thread, an unusually long deprecation period seems warranted, and it would be good to state a firm date in the deprecation message.

I don't have a plan yet. I was thinking of asking people who support Chrome in enterprises about the updating habits of enterprise users. Say that N milestones will reach a reasonable number of them. Then I was thinking we could:

1. Let a deprecation message bake for N milestones.

2. Turn off XSLT by default, but with the option to re-enable it with a flag for an additional milestone (or two, or N.)

3. Remove XSLT entirely.

Concretely, does that mean that the deprecation message would say something like "XSLT is deprecated. It will be disabled by default in M46+N and removed in M46+2N"?

Something like that. Maybe simply that it will be disabled in version 46+N.

 

I think a reasonable range for N is between 2 (remove in 6 months) and 4 (remove in 12 months), but it'd be great to know what the Chrome enterprise teams thinks.

Drew, what's your advice?

 

An alternative would be to advertise that we will remove XSLT as soon as use dips below a certain level (say, half the current level.) This encourages users to report use counters, and it encourages authors who can move to start heading for the exits.

I'm somewhat skeptical of this, when usage is this low the deprecation messages are very unlikely to be seen and acted upon, so usage may not drop to half the current level in any reasonable time. In the worst case, some will vote against the removal by deliberately hitting the use counter with new XSLTProcessor()...

Yes, this does create the perverse incentive to try to spam the use counter, and I don't know what the effects of that would be.

[TAMURA, Kent]

I don't think we can remove XSLT in a few years.

Google Chrome 44 has a serious regression of XSLT, and the bug got 37 stars in a short period.  It represents there are a lot of XSLT users.

XSLT is a large feature.  Applications using XSLT need to change their system architecture.  They can't stop using XSLT easily.

If we'd like to reduce the binary code size, we should consider dynamic loading of libxml.

--

TAMURA Kent
Software Engineer, Google

[Drew Wilson]

+saswat

Typically, we provide 6+ months notice before removing stuff from the web platform. Ideally, we'd give 6+ months notice with some UI affordance in the browser for people using these pages, then deprecate it (remove support by default, but allow it to be re-enabled behind a runtime flag + policy for some further amount of time), then remove the code entirely when we feel comfortable that usage has truly fallen low enough.

-atw

[Domenic Denicola]

Since nobody has mentioned it yet: the showModalDialog removal seems like a very good and successful model to follow. IIRC the key ingredients were deprecation, then hiding it behind a group-policy flag, then eventual removal. Maybe someone can dig up the design docs for that process.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dominic Cooney]

Thanks Drew, Domenic and Kent for those points. Some replies inline.

On Sat, Aug 1, 2015 at 4:59 AM, Domenic Denicola <d...@domenic.me> wrote:

Since nobody has mentioned it yet: the showModalDialog removal seems like a very good and successful model to follow. IIRC the key ingredients were deprecation, then hiding it behind a group-policy flag, then eventual removal. Maybe someone can dig up the design docs for that process.

 

From: atwi...@google.com [mailto:atwi...@google.com] On Behalf Of Drew Wilson
Sent: Friday, July 31, 2015 10:06
To: TAMURA, Kent <tk...@chromium.org>; Saswat Panigrahi <sas...@google.com>
Cc: Dominic Cooney <domi...@chromium.org>; blink-dev <blin...@chromium.org>
Subject: Re: [blink-dev] Intent to Deprecate and Remove: XSLT (Again)

 

+saswat

 

Typically, we provide 6+ months notice before removing stuff from the web platform. Ideally, we'd give 6+ months notice with some UI affordance in the browser for people using these pages, then deprecate it (remove support by default, but allow it to be re-enabled behind a runtime flag + policy for some further amount of time), then remove the code entirely when we feel comfortable that usage has truly fallen low enough.

 

-atw

 

On Fri, Jul 31, 2015 at 8:31 AM, TAMURA, Kent <tk...@chromium.org> wrote:

I don't think we can remove XSLT in a few years.

Google Chrome 44 has a serious regression of XSLT, and the bug got 37 stars in a short period.  It represents there are a lot of XSLT users.

I can't evaluate what 37 or 45 stars over some period might mean. I see bugs about Fedora/Suse-specific font rendering regressions with 37 stars that we weren't in a rush to fix, and multiple bugs about backspace going "back" with hundreds of stars that we WontFixed. There does not seem to be an obvious way to mine the rate of star accrual.

Use counter data is different. Through trial and error the project has compared different levels and has intuition about what level of use is tolerable to remove. Even if XSLT is used heavily in enterprises, given we would consider removing things used three times as much, there is a margin of safety in removing this feature that is used in <0.01% of page loads.

At what level of use would you think its appropriate to remove XSLT?

XSLT is a large feature.  Applications using XSLT need to change their system architecture.  They can't stop using XSLT easily.

 

If we'd like to reduce the binary code size, we should consider dynamic loading of libxml.

Reducing the binary size is just one benefit of removing XSLT.

[TAMURA, Kent]

On Mon, Aug 3, 2015 at 11:07 AM, Dominic Cooney <domi...@chromium.org> wrote:

Thanks Drew, Domenic and Kent for those points. Some replies inline.

On Sat, Aug 1, 2015 at 4:59 AM, Domenic Denicola <d...@domenic.me> wrote:

Since nobody has mentioned it yet: the showModalDialog removal seems like a very good and successful model to follow. IIRC the key ingredients were deprecation, then hiding it behind a group-policy flag, then eventual removal. Maybe someone can dig up the design docs for that process.

 

From: atwi...@google.com [mailto:atwi...@google.com] On Behalf Of Drew Wilson
Sent: Friday, July 31, 2015 10:06
To: TAMURA, Kent <tk...@chromium.org>; Saswat Panigrahi <sas...@google.com>
Cc: Dominic Cooney <domi...@chromium.org>; blink-dev <blin...@chromium.org>
Subject: Re: [blink-dev] Intent to Deprecate and Remove: XSLT (Again)

 

+saswat

 

Typically, we provide 6+ months notice before removing stuff from the web platform. Ideally, we'd give 6+ months notice with some UI affordance in the browser for people using these pages, then deprecate it (remove support by default, but allow it to be re-enabled behind a runtime flag + policy for some further amount of time), then remove the code entirely when we feel comfortable that usage has truly fallen low enough.

 

-atw

 

On Fri, Jul 31, 2015 at 8:31 AM, TAMURA, Kent <tk...@chromium.org> wrote:

I don't think we can remove XSLT in a few years.

Google Chrome 44 has a serious regression of XSLT, and the bug got 37 stars in a short period.  It represents there are a lot of XSLT users.

I can't evaluate what 37 or 45 stars over some period might mean. I see bugs about Fedora/Suse-specific font rendering regressions with 37 stars that we weren't in a rush to fix, and multiple bugs about backspace going "back" with hundreds of stars that we WontFixed. There does not seem to be an obvious way to mine the rate of star accrual.

Use counter data is different. Through trial and error the project has compared different levels and has intuition about what level of use is tolerable to remove. Even if XSLT is used heavily in enterprises, given we would consider removing things used three times as much, there is a margin of safety in removing this feature that is used in <0.01% of page loads.

At what level of use would you think its appropriate to remove XSLT?

I don't have a concrete idea, but the use counter should be much smaller than the current value.  Attr.ownerElement was 0.0055%, but we failed to remove it.

Please refer to "Lessons from the first year of deprecations and removals" section in http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation .

I think the XSLT removal has much more cost than the removal cost of the Attr-related API which we failed to remove.

 

XSLT is a large feature.  Applications using XSLT need to change their system architecture.  They can't stop using XSLT easily.

 

If we'd like to reduce the binary code size, we should consider dynamic loading of libxml.

Reducing the binary size is just one benefit of removing XSLT.

Are there other user-benefit?

As for attack surface, I think it doesn't matter.  libxml is actively maintained, and we also can fix security issues ourselves.

[Kentaro Hara]

I agree with tkent-san here.

Regarding code complexity, tasak@ already removed code that had been intrusive to our code base while he was working on XSLT-in-JS (https://groups.google.com/a/chromium.org/d/topic/blink-dev/F7uuju6_eUU/discussion).

--

Kentaro Hara, Tokyo, Japan

[Dominic Cooney]

I think we are not adding more data at this point, but I will continue to advocate for removing this until the leads make a decision.

On Mon, Aug 3, 2015 at 12:47 PM, Kentaro Hara <har...@chromium.org> wrote:

On Mon, Aug 3, 2015 at 12:42 PM, TAMURA, Kent <tk...@chromium.org> wrote:

On Mon, Aug 3, 2015 at 11:07 AM, Dominic Cooney <domi...@chromium.org> wrote:

Thanks Drew, Domenic and Kent for those points. Some replies inline.

On Sat, Aug 1, 2015 at 4:59 AM, Domenic Denicola <d...@domenic.me> wrote:

Since nobody has mentioned it yet: the showModalDialog removal seems like a very good and successful model to follow. IIRC the key ingredients were deprecation, then hiding it behind a group-policy flag, then eventual removal. Maybe someone can dig up the design docs for that process.

 

From: atwi...@google.com [mailto:atwi...@google.com] On Behalf Of Drew Wilson
Sent: Friday, July 31, 2015 10:06
To: TAMURA, Kent <tk...@chromium.org>; Saswat Panigrahi <sas...@google.com>
Cc: Dominic Cooney <domi...@chromium.org>; blink-dev <blin...@chromium.org>
Subject: Re: [blink-dev] Intent to Deprecate and Remove: XSLT (Again)

 

+saswat

 

Typically, we provide 6+ months notice before removing stuff from the web platform. Ideally, we'd give 6+ months notice with some UI affordance in the browser for people using these pages, then deprecate it (remove support by default, but allow it to be re-enabled behind a runtime flag + policy for some further amount of time), then remove the code entirely when we feel comfortable that usage has truly fallen low enough.

 

-atw

 

On Fri, Jul 31, 2015 at 8:31 AM, TAMURA, Kent <tk...@chromium.org> wrote:

I don't think we can remove XSLT in a few years.

Google Chrome 44 has a serious regression of XSLT, and the bug got 37 stars in a short period.  It represents there are a lot of XSLT users.

I can't evaluate what 37 or 45 stars over some period might mean. I see bugs about Fedora/Suse-specific font rendering regressions with 37 stars that we weren't in a rush to fix, and multiple bugs about backspace going "back" with hundreds of stars that we WontFixed. There does not seem to be an obvious way to mine the rate of star accrual.

Use counter data is different. Through trial and error the project has compared different levels and has intuition about what level of use is tolerable to remove. Even if XSLT is used heavily in enterprises, given we would consider removing things used three times as much, there is a margin of safety in removing this feature that is used in <0.01% of page loads.

At what level of use would you think its appropriate to remove XSLT?

I don't have a concrete idea, but the use counter should be much smaller than the current value.  Attr.ownerElement was 0.0055%, but we failed to remove it.

Please refer to "Lessons from the first year of deprecations and removals" section in http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation .

I am well aware of it, since I was the person who removed ownerElement, as I mentioned in the original post.

 

I think the XSLT removal has much more cost than the removal cost of the Attr-related API which we failed to remove.

It also has more benefit. I take the point that most of the "Lessons" bullets indicate we should not remove things.

XSLT is a large feature.  Applications using XSLT need to change their system architecture.  They can't stop using XSLT easily.

 

If we'd like to reduce the binary code size, we should consider dynamic loading of libxml.

Reducing the binary size is just one benefit of removing XSLT.

Are there other user-benefit?

As for attack surface, I think it doesn't matter.  libxml is actively maintained, and we also can fix security issues ourselves.

How actively something is maintained upstream isn't terribly relevant when we don't update it for several years. I agree that we should take reasonable steps to secure what we ship.

While we're doing that maintenance, we are not doing other things. So continuing to support XSLT has a cost. It's a question of priorities.

[Philip Jägenstedt]

On Mon, Aug 3, 2015 at 5:42 AM, TAMURA, Kent <tk...@chromium.org> wrote:

On Mon, Aug 3, 2015 at 11:07 AM, Dominic Cooney <domi...@chromium.org> wrote:

Thanks Drew, Domenic and Kent for those points. Some replies inline.

On Sat, Aug 1, 2015 at 4:59 AM, Domenic Denicola <d...@domenic.me> wrote:

Since nobody has mentioned it yet: the showModalDialog removal seems like a very good and successful model to follow. IIRC the key ingredients were deprecation, then hiding it behind a group-policy flag, then eventual removal. Maybe someone can dig up the design docs for that process.

 

From: atwi...@google.com [mailto:atwi...@google.com] On Behalf Of Drew Wilson
Sent: Friday, July 31, 2015 10:06
To: TAMURA, Kent <tk...@chromium.org>; Saswat Panigrahi <sas...@google.com>
Cc: Dominic Cooney <domi...@chromium.org>; blink-dev <blin...@chromium.org>
Subject: Re: [blink-dev] Intent to Deprecate and Remove: XSLT (Again)

 

+saswat

 

Typically, we provide 6+ months notice before removing stuff from the web platform. Ideally, we'd give 6+ months notice with some UI affordance in the browser for people using these pages, then deprecate it (remove support by default, but allow it to be re-enabled behind a runtime flag + policy for some further amount of time), then remove the code entirely when we feel comfortable that usage has truly fallen low enough.

 

-atw

 

On Fri, Jul 31, 2015 at 8:31 AM, TAMURA, Kent <tk...@chromium.org> wrote:

I don't think we can remove XSLT in a few years.

Google Chrome 44 has a serious regression of XSLT, and the bug got 37 stars in a short period.  It represents there are a lot of XSLT users.

I can't evaluate what 37 or 45 stars over some period might mean. I see bugs about Fedora/Suse-specific font rendering regressions with 37 stars that we weren't in a rush to fix, and multiple bugs about backspace going "back" with hundreds of stars that we WontFixed. There does not seem to be an obvious way to mine the rate of star accrual.

Use counter data is different. Through trial and error the project has compared different levels and has intuition about what level of use is tolerable to remove. Even if XSLT is used heavily in enterprises, given we would consider removing things used three times as much, there is a margin of safety in removing this feature that is used in <0.01% of page loads.

At what level of use would you think its appropriate to remove XSLT?

I don't have a concrete idea, but the use counter should be much smaller than the current value.  Attr.ownerElement was 0.0055%, but we failed to remove it.

Please refer to "Lessons from the first year of deprecations and removals" section in http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation .

I think the XSLT removal has much more cost than the removal cost of the Attr-related API which we failed to remove.

I think that the most important lesson from the Attr.ownerElement removal was "We shouldn't remove APIs that have small value on the path towards a removal that has significant value."

However, it's very likely that removing XSLT has a higher "risk-per-use-counter-percentage" than many other changes. It might be useful to investigate what kind of breakage would result from removing XSLT. Since we can't correlate use counter data with specific sites, searching for "XSLTProcessor" in httparchive and analyzing a random sample might give some indication.

Philip

[Rick Byers]

The API owners met to discuss this issue.  We agree that we'd love to eliminate XSLT from blink eventually - it's a proven source of security and other issues that we believe is adding relatively little to the web platform compared to the alternative of XSLT processing on the server or in JS.  It's not chromium's goal to retain all functionality used by extremely small (if vocal) subset of users.  Users who prefer a more conservative approach to web platform evolution have the choice of other browsers.

However, our experience with other high-risk/high-value removals (showModalDialog and NPAPI) has shown us that it's really important to be thoughtful and careful in doing such removals in a way that minimizes the user and developer pain.  So in order to approve removing XSLT we'd need to see a well thought out plan that mitigates the damage, with an owner signed up to drive the execution long-term.  We suspect a successful plan would include at least the following:

• A case study of one real-world application converting from browser-XSLT to a Javascript-based library.
• Are the libraries really good enough in practice?
• How much work does this end up being?
• What advice do we have developers for making this as painless as possible?
• A fairly long deprecation timeframe (perhaps 1-2 years)
• A plan to reach out to enterprise customers and help them manage the transition
• Eg. do we need a way for admins to force disable XSLT in advance of removal for testing purposes, and then a way to force re-enable it for a few milestones after removal (similar to NPAPI)?
• Should we present any sort of warning to users to help them understand why a site is broken due to lack of XSLT and what they can do about it?
• Some compat data / identification of specific known applications and an outreach plan
• Eg. IE didn't have XSLT but Edge does.  Why?  Can they share a list of specific compelling applications? cc Jacob Rossi in case he has any insight to share

We recognize this is a substantial undertaking but feel there isn't any easy way out here.  If we can't justify putting in this much effort, then instead we must either live with ongoing maintenance burden, or re-start efforts to make maintenance easier.  It's very tempting to take shortcuts to save ourselves effort, but this just shifts (and magnifies) costs onto our users and so is not the right choice for the ecosystem at large.  If we're going to knowingly inflict non-trivial compat pain on users then we must be willing to do everything possible ourselves to minimize that.

Dominic, what do you think?  Does this seem like a reasonable position to you?  Are you (or anyone else) interested in signing up to own a larger project like this?

Thanks,

   Rick

[Dominic Cooney]

On Fri, Aug 7, 2015 at 6:29 AM, Rick Byers <rby...@chromium.org> wrote:

The API owners met to discuss this issue.  We agree that we'd love to eliminate XSLT from blink eventually - it's a proven source of security and other issues that we believe is adding relatively little to the web platform compared to the alternative of XSLT processing on the server or in JS.  It's not chromium's goal to retain all functionality used by extremely small (if vocal) subset of users.  Users who prefer a more conservative approach to web platform evolution have the choice of other browsers.

However, our experience with other high-risk/high-value removals (showModalDialog and NPAPI) has shown us that it's really important to be thoughtful and careful in doing such removals in a way that minimizes the user and developer pain.  So in order to approve removing XSLT we'd need to see a well thought out plan that mitigates the damage, with an owner signed up to drive the execution long-term.  We suspect a successful plan would include at least the following:

• A case study of one real-world application converting from browser-XSLT to a Javascript-based library.
• Are the libraries really good enough in practice?
• How much work does this end up being?
• What advice do we have developers for making this as painless as possible?
• A fairly long deprecation timeframe (perhaps 1-2 years)
• A plan to reach out to enterprise customers and help them manage the transition
• Eg. do we need a way for admins to force disable XSLT in advance of removal for testing purposes, and then a way to force re-enable it for a few milestones after removal (similar to NPAPI)?
• Should we present any sort of warning to users to help them understand why a site is broken due to lack of XSLT and what they can do about it?
• Some compat data / identification of specific known applications and an outreach plan
• Eg. IE didn't have XSLT but Edge does.  Why?  Can they share a list of specific compelling applications? cc Jacob Rossi in case he has any insight to share

We recognize this is a substantial undertaking but feel there isn't any easy way out here.  If we can't justify putting in this much effort, then instead we must either live with ongoing maintenance burden, or re-start efforts to make maintenance easier.  It's very tempting to take shortcuts to save ourselves effort, but this just shifts (and magnifies) costs onto our users and so is not the right choice for the ecosystem at large.  If we're going to knowingly inflict non-trivial compat pain on users then we must be willing to do everything possible ourselves to minimize that.

Dominic, what do you think?  Does this seem like a reasonable position to you?  Are you (or anyone else) interested in signing up to own a larger project like this?

Thanks,

   Rick

XML and by extension XSLT is most closely related to DOM, so I think the HTML&DOM team should do this--hence my interest in removing XSLT. I will prepare a document to address the points raised in your email, and resubmit it for the leads' consideration.

Dominic

[PhistucK]

On Fri, Aug 7, 2015 at 12:29 AM, Rick Byers <rby...@chromium.org> wrote:

Eg. IE didn't have XSLT

Can you elaborate? What do you mean by "didn't have XSLT"?

Going to http://www.w3.org/TR/xml-stylesheet/xml-stylesheet.xml using Internet Explorer 11 shows the specification.

If you mean the standard (or de facto? I do not remember) API, yes, it did not have it, but it had its own way of transforming a document using XSLT in JavaScript (like it had attachEvent instead of addEventListener).

☆PhistucK

[Rick Byers]

Ah.  Sorry, I misunderstood the discussion - I thought folks were saying IE didn't have a built-in mechanism for using XSLT.  But I see that's incorrect - it was just a different/proprietary API.  That makes more sense - thank you!

☆PhistucK

[Rick Byers]

On Thu, Aug 6, 2015 at 7:59 PM, Dominic Cooney <domi...@chromium.org> wrote:

On Fri, Aug 7, 2015 at 6:29 AM, Rick Byers <rby...@chromium.org> wrote:

The API owners met to discuss this issue.  We agree that we'd love to eliminate XSLT from blink eventually - it's a proven source of security and other issues that we believe is adding relatively little to the web platform compared to the alternative of XSLT processing on the server or in JS.  It's not chromium's goal to retain all functionality used by extremely small (if vocal) subset of users.  Users who prefer a more conservative approach to web platform evolution have the choice of other browsers.

However, our experience with other high-risk/high-value removals (showModalDialog and NPAPI) has shown us that it's really important to be thoughtful and careful in doing such removals in a way that minimizes the user and developer pain.  So in order to approve removing XSLT we'd need to see a well thought out plan that mitigates the damage, with an owner signed up to drive the execution long-term.  We suspect a successful plan would include at least the following:

• A case study of one real-world application converting from browser-XSLT to a Javascript-based library.
• Are the libraries really good enough in practice?
• How much work does this end up being?
• What advice do we have developers for making this as painless as possible?
• A fairly long deprecation timeframe (perhaps 1-2 years)
• A plan to reach out to enterprise customers and help them manage the transition
• Eg. do we need a way for admins to force disable XSLT in advance of removal for testing purposes, and then a way to force re-enable it for a few milestones after removal (similar to NPAPI)?
• Should we present any sort of warning to users to help them understand why a site is broken due to lack of XSLT and what they can do about it?
• Some compat data / identification of specific known applications and an outreach plan
• Eg. IE didn't have XSLT but Edge does.  Why?  Can they share a list of specific compelling applications? cc Jacob Rossi in case he has any insight to share

We recognize this is a substantial undertaking but feel there isn't any easy way out here.  If we can't justify putting in this much effort, then instead we must either live with ongoing maintenance burden, or re-start efforts to make maintenance easier.  It's very tempting to take shortcuts to save ourselves effort, but this just shifts (and magnifies) costs onto our users and so is not the right choice for the ecosystem at large.  If we're going to knowingly inflict non-trivial compat pain on users then we must be willing to do everything possible ourselves to minimize that.

Dominic, what do you think?  Does this seem like a reasonable position to you?  Are you (or anyone else) interested in signing up to own a larger project like this?

Thanks,

   Rick

XML and by extension XSLT is most closely related to DOM, so I think the HTML&DOM team should do this--hence my interest in removing XSLT. I will prepare a document to address the points raised in your email, and resubmit it for the leads' consideration.

Sounds good, thanks!  Personally I suspect the most time consuming part of this is deeply understanding the migration path and ensuring we have good guidance / tools to make it as easy as possible for web developers.  Perhaps there's even a project within Google (or some open source project) that the DOM team could get involved in migrating to use an XSLT JS library?