Intent to Deprecate and Remove: Shadow DOM V0, Custom Elements V0, HTML Imports

17,660 views
Skip to first unread message

Hayato Ito

unread,
Jul 30, 2018, 3:35:19 AM7/30/18
to blink-dev, Takayoshi Kochi, yoi...@chromium.org


Primary eng (and PM) emails

hay...@chromium.org,  ko...@chromium.org, yoi...@chromium.org,


Summary

Remove Shadow DOM V0, Custom Elements V0, and HTML Imports at once in April, 2019 after deprecation period.  All these pre-V1 era web components technologies except HTML Templates were not adopted by any other rendering engines. We discourage any usage of these APIs and encourage migrating to V1 APIs and ES modules.


We are targeting M73 which will be on the stable channel in April 2019 to disable the features. Just in case people need more time for migration, we plan to provide an option of using origin trials to keep using the APIs, see below for details.


Here is the timeline.


  • 2018Q2 (done)

    • Reach out Chrome internal users (e.g. WebUI)

    • Analyze log data (UKM etc.) to identify non-polyfilled users

  • 2018Q3

    • Start showing deprecation message on dev channel (M70)

    • Proactively drive the usage down

  • 2018Q4

    • Start showing deprecation message on stable channel (M70)

    • Continue driving the usage down

  • 2019Q1

    • Disable the feature in M73 (branch Jan. 2019)

  • 2019Q2

    • Feature disabled in stable, start reverse origin trials for remaining users

  • 2020Q1

    • Stop accepting origin trials

  • 2020Q2

    • Remove the code from the code base


Motivation


Shadow DOM V0, Custom Elements V0, and HTML Imports were launched in 2014, but they did not get adopted by other browser engines. Instead, Shadow DOM V1, Custom Elements V1, and ES modules are widely adopted by various browser engines today. Chrome has shipped Shadow DOM V1 / Custom Elements V1 in 2016 and ES modules in 2017.


This is the second intent, the first one was to deprecate only Shadow DOM V0 in Nov. 2016 after Shadow DOM V1 shipped. We withheld deprecating mostly because we had not analyzed the usage at that time.


Since then, we

  • identified the most major users of Shadow DOM V0 and reached out to them (AdBlock Plus, AdBlock) , and helped them moving away from Shadow DOM V0, which resulted in significant usage drop (14% to 2% - considering the usage was 2.2% at the previous intent post with a different measurement method than today, current 2% corresponds to ~0.3% at that time).

  • reached out Chrome internal users (e.g. Chrome WebUI used V0 APIs via Polymer V1) to migrate to V1 APIs (or Polymer V2+), tracked at crbug.com/806159. Half of them are done, and the rest have plan to meet the timeline.

  • removed features of Shadow DOM V0 which are not available in V1 (/deep/, multiple shadow roots) to facilitate web developers to migrate from Shadow DOM V0 to V1.

  • migrated Blink’s UA shadow implementation from V0 to V1.

  • shipped type extension (aka “is=” attribute) for Custom Elements V1, for Custom Element V0 users to migrate to V1

  • Opted in UKM for better analysis of which sites are using these APIs

  • Analyzed httparchive data to identify list of sites that use the APIs


Since then, we also found that in many real-world use cases, Shadow DOM V0, Custom Elements V0, HTML Imports were used together, and instead of getting each of them migrated respectively, getting all of them migrated to today’s standards at once, or at least use the polyfill would make it less troublesome, easier to migrate, rather than fighting with every edge case of combination of polyfill and native implementation.


We found cases that some sites use browser sniffing to assume if it is “Chrome”, use native Custom Elements V0 and HTML Imports, and other sites once feature detect Shadow DOM V0, they assume Custom Elements V0 and HTML Imports are also available.  The former can’t be helped, but the latter can be saved by one-off deprecation strategy.


Note: the polyfill (webcomponentsjs) is designed to feature-detect and polyfill any combination of Shadow DOM V0, Custom Elements V0, HTML Imports. Having said that, each has its own implementation limitation and different level of fidelity to native implementation, if we go the route of one-by-one deprecation, every site owner has to extensively test the site,  while if we deprecate and remove at once, assuming the original site is designed to work for both Blink-based and non-Blink-based browsers using the polyfill, the probability that the site continues to work without any modification must be very high.



Compatibility and Interoperability Risk


No other browser engines support Shadow DOM V0, Custom Elements V0, and HTML Imports.


Existing users of these APIs are mainly coming from Polymer V1 users (Shadow DOM V0, Custom Elements V0, and HTML Imports) and Polymer V2 users (HTML Imports only, Shadow DOM and Custom Elements are V1).  Fortunately for them, the impact should be minimal at the removal because these features are polyfilled and those pages should continue to work. Therefore even though their current usages via UMA look high, we can ignore the major portion of it (see below for details). We continue to figure out more exact usage of non-polyfilled sites that will break via various sources (UMA, UKM, httparchive, …).


Most of Chrome internal usage (such as Chrome Web UI) has migration plans and it is tracked at crbug.com/806159.


Note: even though Event.path was originally defined with Shadow DOM V0, and is superseded by Event.composedPath() in the V1 spec, Event.path can work without Shadow DOM V0 and will be deprecated separately.


Edge/IE: Not supported

Firefox: Not supported

Safari: Not supported


Alternative implementation suggestion for web developers


The most straightforward option is to migrate to Shadow DOM V1, Custom Elements V1, ES modules respectively at once. For Shadow DOM V1, there’s a document to compare V0 and V1 APIs. As this is not a simple replacement of APIs, it may be time consuming.


If you use the features without Polymer, one option is to use a polyfill. The polyfill bundled with Polymer is separately available as “webcomponentsjs”. Specifically for polyfilling V0 APIs, you can use its v0 branch. There are other alternative polyfills for each, like AshleyScirra’s HTML Imports polyfill.


If you use Polymer V1 or V2, in most cases you do not have to take any action because the polyfill should kick in where these APIs are not available. If you would like to try if the polyfill works, you can pass --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports to Chrome (see howto document for passing command line parameter). To be more future proof, it is a good idea to migrate to a newer version of Polymer, see their document for upgrading to 3.0 and 2.0.

Note: at this moment Chrome’s devtools use Shadow DOM V0 and Custom Elements V0, if you pass the option above, you cannot open developer tools.  In that case you can use remote debugging.


If you are an owner/developer of a site where any options above does not help, and cannot have time to do the work by the expected deadline (April 2019), we plan to offer an option to use origin trials to opt-in for the site to enable deprecated features for up to 1 year. Origin Trials are a mechanism that a site owner can apply for using Chrome’s experimental features, by getting a token to embed in a page to unlock the features. We use this for allowing to use deprecated features, aka “reverse origin trials”.  How to apply for this will be sent out separately, when the removal date approaches (expecting in Jan 2019).


If you encounter a site that you do not own, but is broken due to this deprecation, you can try passing --enable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports to Chrome. This will work until we remove the code in 2020.


Usage information from UseCounter


Element.createShadowRoot() (representative for Shadow DOM V0 usage)

https://www.chromestatus.com/metrics/feature/timeline/popularity/456 (~1.7%)

According to internal per-OS breakdown data, Android is the lowest (~0.85%) and other desktop OSes are all higher than 1.7%. It could mean that still some extensions use this.  On httparchive mobile sites, we have only ~260 URLs out of Alexa 500,000 top mobile sites (~0.45%, because UMA takes page views into account, number % of top URLs must be smaller than UMA). By reaching out non-polyfilled sites we think we can reduce the pageview-based number of non-polyfilled sites to below 0.1% within this deprecation period.


Document.registerElement() (representative for Custom Elements V0 usage)

https://www.chromestatus.com/metrics/feature/timeline/popularity/457 (~5.0%)

We are aware that this number is high, however, this includes YouTube desktop usage. We have been talking with YouTube team. From internal UMA per-OS breakdown, Android is ~3.8% (and other desktop OSes are above 5%). We have ~4000 URLs in httparchive for mobile sites (~0.8%), and will pick up non-polyfilled sites and reach them out. Even for non-polyfilled sites, unless they run Blink-based browser only sites, we assume most of them feature-detect with some fallback, therefore problematic sites should be very few (to be closely analyzed, though).


HTML Imports (<link rel=”import”>)

https://www.chromestatus.com/metrics/feature/timeline/popularity/455 (~2.0%)

We are aware that this number is high, however, this includes YouTube desktop usage. From internal UMA per-OS breakdown, Android is ~0.13% (and other desktop OSs are above 2%). Once YouTube desktop move out of HTML Imports, desktop numbers should become closer to Android’s.  From httparchive mobile sites, ~280 URLs (out of 500,000 - ~0.6%) pmeenan@ already looked at these list and 175 out of 277 are identified using web components polyfill. So ~100 sites out of 500,000 sites will be affected by this, which is ~0.02% of sites.


Polymer V1 (detected by “dom-module” registration via document.registerElement)

https://www.chromestatus.com/metrics/feature/timeline/popularity/2466 (~1.9%)

This includes desktop YouTube usage (Note: this counter is added in M69 (still dev or beta), so the variance against the real number could be high).  We use this number for roughly estimating those who are NOT affected by this removal.



Other less significant counters


V0CustomElementsCreateTypeExtensionElement

https://www.chromestatus.com/metrics/feature/timeline/popularity/1878 (~3.5%)

As M67 shipped type extension for Custom Elements V1, this number should decrease, and we will observe how this declines.


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=671907 (Shadow DOM V0)

https://bugs.chromium.org/p/chromium/issues/detail?id=660759 (Custom Elements V0)

https://bugs.chromium.org/p/chromium/issues/detail?id=766694 (HTML Imports)


Entry on the feature dashboard

https://www.chromestatus.com/features/4507242028072960 (Shadow DOM V0)

https://www.chromestatus.com/feature/4642138092470272 (Custom Elements V0)

https://www.chromestatus.com/features/5144752345317376 (HTML Imports)


Requesting approval to remove too?

Yes


--
Hayato

Chris Harrelson

unread,
Aug 6, 2018, 8:41:41 PM8/6/18
to Hayato Ito, blink-dev, Takayoshi Kochi, Yoichi Osato
LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_2%3DWVFFf8fK%2BXrOJmw-_a6nBO1YqzA%2BUaaiOpm1UK-xyQ%40mail.gmail.com.

Yoav Weiss

unread,
Aug 8, 2018, 7:20:22 AM8/8/18
to Chris Harrelson, Hayato Ito, blink-dev, Takayoshi Kochi, Yoichi Osato
I'm concerned that the replacement of HTML imports will not be as performant. A couple performance characteristics that I really like about HTML imports are the browser's ability to progressively process them and its ability to tokenize them and preload their subresources.

I haven't kept close tabs with the HTML modules effort so I don't know where it stands, but last time I looked, these characteristics would have been lost with the ES modules based proposal. It also seems like the HTML imports polyfill doesn't process them progressively.

So, it feels like we're removing a platform capability (or at least a convenience) without providing an edequate alternative.





smaug

unread,
Aug 8, 2018, 8:19:51 AM8/8/18
to Yoav Weiss, Chris Harrelson, Hayato Ito, blink-dev, Takayoshi Kochi, Yoichi Osato
On 08/08/2018 02:20 PM, Yoav Weiss wrote:
> I'm concerned that the replacement of HTML imports will not be as performant. A couple performance characteristics that I really like about HTML
> imports are the browser's ability to progressively process them and its ability to tokenize them and preload their subresources.
>
> I haven't kept close tabs with the HTML modules effort so I don't know where it stands, but last time I looked, these characteristics would have been
> lost with the ES modules based proposal. It also seems like the HTML imports polyfill doesn't process them progressively
> <https://github.com/AshleyScirra/html-imports-polyfill/blob/master/htmlimports.js#L51>.
>
> So, it feels like we're removing a platform capability (or at least a convenience) without providing an edequate alternative.
>

FWIW, it is not really a platform capability when it is a blink-only API.
It is a good thing to remove browser specific web exposed APIs.


-Olli


>
>
>
>
> On Tue, Aug 7, 2018 at 2:41 AM Chris Harrelson <chri...@chromium.org <mailto:chri...@chromium.org>> wrote:
>
> LGTM1
>
> On Mon, Jul 30, 2018 at 12:35 AM Hayato Ito <hay...@chromium.org <mailto:hay...@chromium.org>> wrote:
>
> *
>
>
> Primary eng (and PM) emails
>
> hay...@chromium.org <mailto:hay...@chromium.org>, ko...@chromium.org <mailto:ko...@chromium.org>, yoi...@chromium.org
> <mailto:yoi...@chromium.org>,
>
>
> Summary
>
> Remove Shadow DOM V0, Custom Elements V0, and HTML Imports at once in April, 2019 after deprecation period.  All these pre-V1 era web
> components technologies except HTML Templates were not adopted by any other rendering engines. We discourage any usage of these APIs and
> encourage migrating to V1 APIs and ES modules.
>
>
> We are targeting M73 which will be on the stable channel in April 2019 to disable the features. Just in case people need more time for
> migration, we plan to provide an option of using origin trials<https://github.com/GoogleChrome/OriginTrials>to keep using the APIs, see below
> for details.
>
>
> Here is the timeline.
>
>
> *
>
> 2018Q2 (done)
>
> o
>
> Reach out Chrome internal users (e.g. WebUI)
>
> o
>
> Analyze log data (UKM etc.) to identify non-polyfilled users
>
> *
>
> 2018Q3
>
> o
>
> Start showing deprecation message on dev channel (M70)
>
> o
>
> Proactively drive the usage down
>
> *
>
> 2018Q4
>
> o
>
> Start showing deprecation message on stable channel (M70)
>
> o
>
> Continue driving the usage down
>
> *
>
> 2019Q1
>
> o
>
> Disable the feature in M73 (branch Jan. 2019)
>
> *
>
> 2019Q2
>
> o
>
> Feature disabled in stable, start reverse origin trials for remaining users
>
> *
>
> 2020Q1
>
> o
>
> Stop accepting origin trials
>
> *
>
> 2020Q2
>
> o
>
> Remove the code from the code base
>
>
> Motivation
>
>
> Shadow DOM V0, Custom Elements V0, and HTML Imports were launched in 2014, but they did not get adopted by other browser engines. Instead,
> Shadow DOM V1, Custom Elements V1, and ES modules are widely adopted by various browser engines today. Chrome has shipped Shadow DOM V1 /
> Custom Elements V1 in 2016 and ES modules in 2017.
>
>
> This is the second intent, the first one was to deprecate only Shadow DOM V0 in Nov. 2016
> <https://groups.google.com/a/chromium.org/d/topic/blink-dev/txIN7qDRFpU/discussion>after Shadow DOM V1 shipped. We withheld deprecating mostly
> because we had not analyzed the usage at that time.
>
>
> Since then, we
>
> *
>
> identified the most major users of Shadow DOM V0 and reached out to them (AdBlock Plus <https://issues.adblockplus.org/ticket/242>,
> AdBlock <https://help.getadblock.com/support/discussions/topics/6000044963>) , and helped them
> <https://bugs.chromium.org/p/chromium/issues/detail?id=632009>moving away from Shadow DOM V0, which resulted in significant usage drop
> (14% to 2% - considering the usage was 2.2% at the previous intent post with a different measurement method than today, current 2%
> corresponds to ~0.3% at that time).
>
> *
>
> reached out Chrome internal users (e.g. Chrome WebUI used V0 APIs via Polymer V1) to migrate to V1 APIs (or Polymer V2+), tracked at
> crbug.com/806159 <https://crbug.com/806159>. Half of them are done, and the rest have plan to meet the timeline.
>
> *
>
> removed features of Shadow DOM V0 which are not available in V1 (/deep/ <https://bugs.chromium.org/p/chromium/issues/detail?id=489954>,
> multiple shadow roots <https://bugs.chromium.org/p/chromium/issues/detail?id=489947>) to facilitate web developers to migrate from Shadow
> DOM V0 to V1.
>
> *
>
> migrated Blink’s UA shadow implementation from V0 to V1 <https://bugs.chromium.org/p/chromium/issues/detail?id=787717>.
>
> *
>
> shipped type extension <https://bugs.chromium.org/p/chromium/issues/detail?id=648828>(aka “is=” attribute) for Custom Elements V1, for
> Custom Element V0 users to migrate to V1
>
> *
>
> Opted in UKM for better analysis of which sites are using these APIs
>
> *
>
> Analyzed httparchive data to identify list of sites that use the APIs
>
>
> Since then, we also found that in many real-world use cases, Shadow DOM V0, Custom Elements V0, HTML Imports were used together, and instead
> of getting each of them migrated respectively, getting all of them migrated to today’s standards at once, or at least use the polyfill would
> make it less troublesome, easier to migrate, rather than fighting with every edge case of combination of polyfill and native implementation.
>
>
> We found cases that some sites use browser sniffing to assume if it is “Chrome”, use native Custom Elements V0 and HTML Imports, and other
> sites once feature detect Shadow DOM V0, they assume Custom Elements V0 and HTML Imports are also available.  The former can’t be helped, but
> the latter can be saved by one-off deprecation strategy.
>
>
> Note: the polyfill (webcomponentsjs <https://github.com/webcomponents/webcomponentsjs>) is designed to feature-detect and polyfill any
> combination of Shadow DOM V0, Custom Elements V0, HTML Imports. Having said that, each has its own implementation limitation and different
> level of fidelity to native implementation, if we go the route of one-by-one deprecation, every site owner has to extensively test the site,
>  while if we deprecate and remove at once, assuming the original site is designed to work for both Blink-based and non-Blink-based browsers
> using the polyfill, the probability that the site continues to work without any modification must be very high.
>
>
>
> Compatibility and Interoperability Risk
>
>
> No other browser engines support Shadow DOM V0, Custom Elements V0, and HTML Imports.
>
>
> Existing users of these APIs are mainly coming from Polymer V1 users (Shadow DOM V0, Custom Elements V0, and HTML Imports) and Polymer V2
> users (HTML Imports only, Shadow DOM and Custom Elements are V1).  Fortunately for them, the impact should be minimal at the removal because
> these features are polyfilled and those pages should continue to work. Therefore even though their current usages via UMA look high, we can
> ignore the major portion of it (see below for details). We continue to figure out more exact usage of non-polyfilled sites that will break via
> various sources (UMA, UKM, httparchive, …).
>
>
> Most of Chrome internal usage (such as Chrome Web UI) has migration plans and it is tracked at crbug.com/806159 <https://crbug.com/806159>.
>
>
> Note: even though Event.path was originally defined with Shadow DOM V0, and is superseded by Event.composedPath()
> <https://dom.spec.whatwg.org/#dom-event-composedpath>in the V1 spec, Event.path can work without Shadow DOM V0 and will be deprecated separately.
>
>
> Edge/IE: Not supported
>
> Firefox: Not supported
>
> Safari: Not supported
>
>
> Alternative implementation suggestion for web developers
>
>
> The most straightforward option is to migrate to Shadow DOM V1, Custom Elements V1, ES modules respectively at once. For Shadow DOM V1,
> there’s a document <https://hayato.io/2016/shadowdomv1/>to compare V0 and V1 APIs. As this is not a simple replacement of APIs, it may be time
> consuming.
>
>
> If you use the features without Polymer, one option is to use a polyfill. The polyfill bundled with Polymer is separately available as
> “webcomponentsjs <https://github.com/webcomponents/webcomponentsjs>”. Specifically for polyfilling V0 APIs, you can use its v0 branch
> <https://github.com/webcomponents/webcomponentsjs/tree/v0>. There are other alternative polyfills for each, like AshleyScirra’s HTML Imports
> polyfill <https://github.com/AshleyScirra/html-imports-polyfill>.
>
>
> If you use Polymer V1 or V2, in most cases you do not have to take any action because the polyfill should kick in where these APIs are not
> available. If you would like to try if the polyfill works, you can pass --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports to
> Chrome (see howto document <http://www.chromium.org/developers/how-tos/run-chromium-with-flags>for passing command line parameter). To be more
> future proof, it is a good idea to migrate to a newer version of Polymer, see their document for upgrading to 3.0
> <https://www.polymer-project.org/3.0/docs/upgrade>and 2.0 <https://www.polymer-project.org/2.0/docs/upgrade>.
>
> Note: at this moment Chrome’s devtools use Shadow DOM V0 and Custom Elements V0, if you pass the option above, you cannot open developer
> tools.  In that case you can use remote debugging <https://blog.chromium.org/2011/05/remote-debugging-with-chrome-developer.html>.
>
>
> If you are an owner/developer of a site where any options above does not help, and cannot have time to do the work by the expected deadline
> (April 2019), we plan to offer an option to use origin trials <https://github.com/GoogleChrome/OriginTrials>to opt-in for the site to enable
> deprecated features for up to 1 year. Origin Trials are a mechanism that a site owner can apply for using Chrome’s experimental features, by
> getting a token to embed in a page to unlock the features. We use this for allowing to use deprecated features, aka “reverse origin trials”.
> How to apply for this will be sent out separately, when the removal date approaches (expecting in Jan 2019).
>
>
> If you encounter a site that you do not own, but is broken due to this deprecation, you can try passing
> --enable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports to Chrome. This will work until we remove the code in 2020.
>
>
> Usage information from UseCounter
>
>
> Element.createShadowRoot() (representative for Shadow DOM V0 usage)
>
> https://www.chromestatus.com/metrics/feature/timeline/popularity/456(~1.7%)
>
> According to internal per-OS breakdown data, Android is the lowest (~0.85%) and other desktop OSes are all higher than 1.7%. It could mean
> that still some extensions use this.  On httparchive mobile sites, we have only ~260 URLs out of Alexa 500,000 top mobile sites (~0.45%,
> because UMA takes page views into account, number % of top URLs must be smaller than UMA). By reaching out non-polyfilled sites we think we
> can reduce the pageview-based number of non-polyfilled sites to below 0.1% within this deprecation period.
>
>
> Document.registerElement() (representative for Custom Elements V0 usage)
>
> https://www.chromestatus.com/metrics/feature/timeline/popularity/457(~5.0%)
>
> We are aware that this number is high, however, this includes YouTube desktop usage. We have been talking with YouTube team. From internal UMA
> per-OS breakdown, Android is ~3.8% (and other desktop OSes are above 5%). We have ~4000 URLs in httparchive for mobile sites (~0.8%), and will
> pick up non-polyfilled sites and reach them out. Even for non-polyfilled sites, unless they run Blink-based browser only sites, we assume most
> of them feature-detect with some fallback, therefore problematic sites should be very few (to be closely analyzed, though).
>
>
> HTML Imports (<link rel=”import”>)
>
> https://www.chromestatus.com/metrics/feature/timeline/popularity/455(~2.0%)
>
> We are aware that this number is high, however, this includes YouTube desktop usage. From internal UMA per-OS breakdown, Android is ~0.13%
> (and other desktop OSs are above 2%). Once YouTube desktop move out of HTML Imports, desktop numbers should become closer to Android’s.  From
> httparchive mobile sites, ~280 URLs (out of 500,000 - ~0.6%) pmeenan@ already looked at these list
> <https://docs.google.com/spreadsheets/d/1TgAFyM_HzSTisEE_sR6yhc5oEDnEdWJKtso-qr66Ma4/edit#gid=0>and 175 out of 277 are identified using web
> components polyfill. So ~100 sites out of 500,000 sites will be affected by this, which is ~0.02% of sites.
>
>
> Polymer V1 (detected by “dom-module” registration via document.registerElement)
>
> https://www.chromestatus.com/metrics/feature/timeline/popularity/2466(~1.9%)
>
> This includes desktop YouTube usage (Note: this counter is added in M69 (still dev or beta), so the variance against the real number could be
> high).  We use this number for roughly estimating those who are NOT affected by this removal.
>
>
>
> Other less significant counters
>
>
> V0CustomElementsCreateTypeExtensionElement
>
> https://www.chromestatus.com/metrics/feature/timeline/popularity/1878(~3.5%)
>
> As M67 shipped type extension for Custom Elements V1, this number should decrease, and we will observe how this declines.
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=671907(Shadow DOM V0)
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=660759(Custom Elements V0)
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=766694(HTML Imports)
> https://www.chromestatus.com/features/5144752345317376(HTML Imports)
>
>
> Requesting approval to remove too?
>
> Yes
>
>
> --
> Hayato
> *
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_2%3DWVFFf8fK%2BXrOJmw-_a6nBO1YqzA%2BUaaiOpm1UK-xyQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ua4%2Bey7XB%2BTA4_pHYqPwveq9azEcgSEVq5FwQQv2sCQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ua4%2Bey7XB%2BTA4_pHYqPwveq9azEcgSEVq5FwQQv2sCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEj15Bh7heVM_G0JV%3DhZvJbVfr5F5LfjmuFP5hEpLYBL9w%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEj15Bh7heVM_G0JV%3DhZvJbVfr5F5LfjmuFP5hEpLYBL9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

nsi...@nuxeo.com

unread,
Aug 9, 2018, 5:35:48 PM8/9/18
to blink-dev
I can't help but feel that the deprecation of HTML imports is being rushed and should be decoupled from the deprecation of CE and Shadow DOM V0. Agree it's not good to keep non standard APIs but HTML imports are being used with CE and Shadow DOM V1 in Polymer 2 for instance which was released just a year ago!
There isn't any comparable alternative yet apart from ES Modules which require generating HTML and CSS with JS. HTML modules are the most similar proposal but very far from even a first implementation. IMHO it would make sense to delay deprecation of HTML imports until we have HTML modules or a way to leverage ES Modules to load HTML.

PhistucK

unread,
Aug 9, 2018, 5:58:03 PM8/9/18
to nsi...@nuxeo.com, blink-dev
> but HTML imports are being used with CE and Shadow DOM V1 in Polymer 2 for instance which was released just a year ago!
That was probably a mistake on their part, because all of the other vendors indicated opposition to HTML imports for years, if I remember correctly.
However, it is only an optimization, if I am not mistaken and it will work even without HTML import support, so it does not really matter much.

PhistucK


On Fri, Aug 10, 2018 at 12:35 AM <nsi...@nuxeo.com> wrote:
I can't help but feel that the deprecation of HTML imports is being rushed and should be decoupled from the deprecation of CE and Shadow DOM V0. Agree it's not good to keep non standard APIs but HTML imports are being used with CE and Shadow DOM V1 in Polymer 2 for instance which was released just a year ago!
There isn't any comparable alternative yet apart from ES Modules which require generating HTML and CSS with JS. HTML modules are the most similar proposal but very far from even a first implementation. IMHO it would make sense to delay deprecation of HTML imports until we have HTML modules or a way to leverage ES Modules to load HTML.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/73977699-55ff-42a3-8aab-10188b89c785%40chromium.org.

TAMURA, Kent

unread,
Aug 10, 2018, 12:53:23 AM8/10/18
to Yoav Weiss, Chris Harrelson, Hayato Ito, blink-dev, Takayoshi Kochi, Yoichi Osato
LGTM2.

The plan looks very good.  Because the usage numbers are still not low, we need long deprecation period, and providing origin trial sounds a good idea.
As for no replacement of HTML Imports, we should consider the tradeoff between the benefit of performance boost by HTML Imports and the risk of keeping the non-interoperable API. IMO the latter is larger in this case.




--
TAMURA Kent
Software Engineer, Google


Nelson Silva

unread,
Aug 10, 2018, 4:57:42 AM8/10/18
to blink-dev
"Chrome has shipped Shadow DOM V1 / Custom Elements V1 in 2016 and ES modules in 2017" so the "alternative" for HTML imports arrived almost a year after CE and Shadow DOM V1 which makes the deprecation window much shorter.
We currently rely heavily on HTML imports to allow *declarative* building of custom elements for enterprise content management applications. These come with long term support.
We have migrated away from the V0 APIs and are planning migrating from HTML imports but there is no direct replacement at this time, not one that allows us to stick to HTML without some form of building/bundling process.
Today we rely on the polyfill for other browsers but at least we have a nice development experience with Chrome which shows the imports as HTML documents and not as nasty data urls.
I am well aware this is not the time or place to discuss the adoption of HTML imports as a standard since that "battle" has been lost a long time ago but I still have hopes for a real alternative that allows us to keep HTML for it's declarative nature and would hope for HTML imports to be there, at least in Chrome, until we have a comparable alternative.

Hayato Ito

unread,
Aug 10, 2018, 5:31:17 AM8/10/18
to nsi...@nuxeo.com, blink-dev
Just for reference, the discussion about HTML Modules, as an alternative to HTML Imports, is here.
It would be really great for us to move HTML Modules forward.
As far as I understand, no one objects to it. At this point it mostly just needs someone to do the non-trivial legwork to get it done.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.


--
Hayato

Philip Jägenstedt

unread,
Aug 14, 2018, 10:30:56 AM8/14/18
to Hayato Ito, nsi...@nuxeo.com, blink-dev
LGTM3

A very comprehensive plan and research into existing usage, thank you!
Working with ad blocking extensions to drive down usage from 14% to 2%
is particularly impressive!

The rationale for linking these deprecations makes perfect sense to
me, it will allow web developers to react to the change once.

Yoav, do you still have concerns with removing HTML imports? If so
please do not let the 3xLGTM stop the discussion on this thread.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_3QTy_%2BhMVVjSTOq5fam8VYCZ%2BzfcxQfVSjAnf1YJxY6w%40mail.gmail.com.

Philip Jägenstedt

unread,
Aug 14, 2018, 12:12:41 PM8/14/18
to Hayato Ito, Domenic Denicola, nsi...@nuxeo.com, blink-dev
The API owners (Alex, Yoav, me) discussed this in the meeting today.

We're still concerned that the replacement will be less performant than HTML imports, and would like to understand if there's any path forward. +Domenic Denicola, what are your current views on "HTML modules", and what it would take to ship something with multi-vendor support?

Domenic Denicola

unread,
Aug 14, 2018, 12:25:49 PM8/14/18
to Philip Jägenstedt, Hayato Ito, nsi...@nuxeo.com, blink-dev
From: Philip Jägenstedt <foo...@chromium.org>

> We're still concerned that the replacement will be less performant than HTML imports,

My understanding is that many of the theoretical performance benefits of HTML imports were not, in the end, implemented; in practice to get acceptable performance with them sites had to use tooling like Vulcanize to inline their contents into the main page. See https://www.polymer-project.org/1.0/docs/tools/optimize-for-production for example. Hayato or the rest of the DOM team can weigh in further.

> and would like to understand if there's any path forward. mailto:d...@domenic.me, what are your current views on "HTML modules", and what it would take to ship something with multi-vendor support?

HTML modules make a lot of sense to me in theory, as they allow the standards, implementer, and web developer community to converge on a single module system and optimize the heck out of it. (See previous threads for updates on the loading team's ongoing efforts in that area for the JS module system).

Hayato is right that no browsers seem to object to it, and that it mostly just needs someone to do the legwork. The discussion is at https://github.com/w3c/webcomponents/issues/645, but nobody seems to be devoting full-time effort to it. I think last we saw putting together a concrete proposal was part of the Polymer OKRs, with mentoring from the DOM team, but I haven't seen any progress for a while.

Hayato Ito

unread,
Aug 15, 2018, 9:17:23 AM8/15/18
to Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
On Wed, Aug 15, 2018 at 1:25 AM Domenic Denicola <d...@domenic.me> wrote:
From: Philip Jägenstedt <foo...@chromium.org>

> We're still concerned that the replacement will be less performant than HTML imports,

My understanding is that many of the theoretical performance benefits of HTML imports were not, in the end, implemented; in practice to get acceptable performance with them sites had to use tooling like Vulcanize to inline their contents into the main page. See https://www.polymer-project.org/1.0/docs/tools/optimize-for-production for example. Hayato or the rest of the DOM team can weigh in further.


Yeah, in practice, I think most sites are using Vulcanize at this point.
Polymer has already switched to use ES Modules, and I've not heard any significant performance regression on this switch, compared to HTML Imports.

We know that ES Modules couldn't be a replacement of HTML Imports because they solve a different problem, however, from the performance perspective, ES Modules shouldn't be less performant than HTML imports. ES Modules' performance is getting better and better, I think.

In addition to that, as Olli@ pointed out in this thread, other browsers never get performance benefits from HTML Imports.

Polymer team would have more insights on the performance.

--
Hayato

Yoav Weiss

unread,
Aug 16, 2018, 7:17:02 AM8/16/18
to Hayato Ito, Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
On Wed, Aug 15, 2018 at 3:17 PM Hayato Ito <hay...@chromium.org> wrote:
On Wed, Aug 15, 2018 at 1:25 AM Domenic Denicola <d...@domenic.me> wrote:
From: Philip Jägenstedt <foo...@chromium.org>

> We're still concerned that the replacement will be less performant than HTML imports,

My understanding is that many of the theoretical performance benefits of HTML imports were not, in the end, implemented; in practice to get acceptable performance with them sites had to use tooling like Vulcanize to inline their contents into the main page. See https://www.polymer-project.org/1.0/docs/tools/optimize-for-production for example. Hayato or the rest of the DOM team can weigh in further.


Yeah, in practice, I think most sites are using Vulcanize at this point.
Polymer has already switched to use ES Modules, and I've not heard any significant performance regression on this switch, compared to HTML Imports.

Interesting. Was the existing implementation not optimized to go through preloadScanning and progressive DOM building? Or are the payloads typically used too small for it to make a difference?


We know that ES Modules couldn't be a replacement of HTML Imports because they solve a different problem, however, from the performance perspective, ES Modules shouldn't be less performant than HTML imports.

Can the HTML modules model enable progressive tokenization and DOM building?
 
ES Modules' performance is getting better and better, I think.

In addition to that, as Olli@ pointed out in this thread, other browsers never get performance benefits from HTML Imports.

Polymer team would have more insights on the performance.

--
Hayato

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss

unread,
Aug 16, 2018, 7:37:19 AM8/16/18
to Hayato Ito, blink-dev, Takayoshi Kochi, yoi...@chromium.org
Going back to the usage numbers:

On Mon, Jul 30, 2018 at 9:35 AM Hayato Ito <hay...@chromium.org> wrote:



Usage information from UseCounter


...

HTML Imports (<link rel=”import”>)

https://www.chromestatus.com/metrics/feature/timeline/popularity/455 (~2.0%)

We are aware that this number is high, however, this includes YouTube desktop usage. From internal UMA per-OS breakdown, Android is ~0.13% (and other desktop OSs are above 2%). Once YouTube desktop move out of HTML Imports, desktop numbers should become closer to Android’s.  From httparchive mobile sites, ~280 URLs (out of 500,000 - ~0.6%) pmeenan@ already looked at these list and 175 out of 277 are identified using web components polyfill. So ~100 sites out of 500,000 sites will be affected by this, which is ~0.02% of sites.


If I'm reading this correctly, once YT moves away from HTML imports (what's the schedule on that, btw?), we'd have 0.13% of views which use imports. According to HA data, 36% of sites which do use it, have no polyfill.
That means they are broken today on non-Chrome browsers, or perform some UA sniffing to serve alternative content elsewhere.

If we assume equal distribution of views per site and multiply these numbers, we'll end up with 0.046%, which is above the typical threshold.
The fact that these sites are likely broken in other browsers may make that breakage more palatable.

FWIW, I've tried out a few random sites from that "no polyfill" list, and they don't seem broken in Firefox. Not sure what bit of functionality they actually rely on for imports.

Hayato Ito

unread,
Aug 16, 2018, 8:26:22 AM8/16/18
to Yoav Weiss, Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
On Thu, Aug 16, 2018 at 8:17 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Aug 15, 2018 at 3:17 PM Hayato Ito <hay...@chromium.org> wrote:
On Wed, Aug 15, 2018 at 1:25 AM Domenic Denicola <d...@domenic.me> wrote:
From: Philip Jägenstedt <foo...@chromium.org>

> We're still concerned that the replacement will be less performant than HTML imports,

My understanding is that many of the theoretical performance benefits of HTML imports were not, in the end, implemented; in practice to get acceptable performance with them sites had to use tooling like Vulcanize to inline their contents into the main page. See https://www.polymer-project.org/1.0/docs/tools/optimize-for-production for example. Hayato or the rest of the DOM team can weigh in further.


Yeah, in practice, I think most sites are using Vulcanize at this point.
Polymer has already switched to use ES Modules, and I've not heard any significant performance regression on this switch, compared to HTML Imports.

Interesting. Was the existing implementation not optimized to go through preloadScanning and progressive DOM building? Or are the payloads typically used too small for it to make a difference?


I don't think any implementation of ES Modules are doing progressive DOM building. I think you can get more insights from ES Modules owners.
 

We know that ES Modules couldn't be a replacement of HTML Imports because they solve a different problem, however, from the performance perspective, ES Modules shouldn't be less performant than HTML imports.

Can the HTML modules model enable progressive tokenization and DOM building?
 

That is basically up-to UA. I don't see any reason Blink can't do that for HTML Modules.

I guess the reason you asked these questions is to let us know that HTML Modules would be much better than ES Modules, regarding loading HTML and DOM building. Yup, that is the reason that we would like to move HTML Modules forward.
 
ES Modules' performance is getting better and better, I think.

In addition to that, as Olli@ pointed out in this thread, other browsers never get performance benefits from HTML Imports.

Polymer team would have more insights on the performance.

--
Hayato

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1xd02xp8vVCiA8bPUi7kZor%3DEKJqOrNxeGu5xoSpJHEA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Yoav Weiss

unread,
Aug 16, 2018, 8:37:57 AM8/16/18
to Hayato Ito, Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
On Thu, Aug 16, 2018 at 2:26 PM Hayato Ito <hay...@chromium.org> wrote:
On Thu, Aug 16, 2018 at 8:17 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Aug 15, 2018 at 3:17 PM Hayato Ito <hay...@chromium.org> wrote:
On Wed, Aug 15, 2018 at 1:25 AM Domenic Denicola <d...@domenic.me> wrote:
From: Philip Jägenstedt <foo...@chromium.org>

> We're still concerned that the replacement will be less performant than HTML imports,

My understanding is that many of the theoretical performance benefits of HTML imports were not, in the end, implemented; in practice to get acceptable performance with them sites had to use tooling like Vulcanize to inline their contents into the main page. See https://www.polymer-project.org/1.0/docs/tools/optimize-for-production for example. Hayato or the rest of the DOM team can weigh in further.


Yeah, in practice, I think most sites are using Vulcanize at this point.
Polymer has already switched to use ES Modules, and I've not heard any significant performance regression on this switch, compared to HTML Imports.

Interesting. Was the existing implementation not optimized to go through preloadScanning and progressive DOM building? Or are the payloads typically used too small for it to make a difference?


I don't think any implementation of ES Modules are doing progressive DOM building. I think you can get more insights from ES Modules owners.

Apologies for not being clearer. By "existing implementation" I was referring to the current HTML imports implementation.

 

We know that ES Modules couldn't be a replacement of HTML Imports because they solve a different problem, however, from the performance perspective, ES Modules shouldn't be less performant than HTML imports.

Can the HTML modules model enable progressive tokenization and DOM building?
 

That is basically up-to UA. I don't see any reason Blink can't do that for HTML Modules.

I guess the reason you asked these questions is to let us know that HTML Modules would be much better than ES Modules, regarding loading HTML and DOM building. Yup, that is the reason that we would like to move HTML Modules forward.

I was asking that because I wanted to know the answer :)
I wasn't sure if the reliance on ES modules as infrastructure would make it more difficult to process the HTML content progressively.

Glad to see you don't foresee any difficulties there, and glad to hear HTML modules is something the team continues to pursue.

Hayato Ito

unread,
Aug 16, 2018, 8:52:41 AM8/16/18
to Yoav Weiss, Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
On Thu, Aug 16, 2018 at 9:37 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Thu, Aug 16, 2018 at 2:26 PM Hayato Ito <hay...@chromium.org> wrote:
On Thu, Aug 16, 2018 at 8:17 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Aug 15, 2018 at 3:17 PM Hayato Ito <hay...@chromium.org> wrote:
On Wed, Aug 15, 2018 at 1:25 AM Domenic Denicola <d...@domenic.me> wrote:
From: Philip Jägenstedt <foo...@chromium.org>

> We're still concerned that the replacement will be less performant than HTML imports,

My understanding is that many of the theoretical performance benefits of HTML imports were not, in the end, implemented; in practice to get acceptable performance with them sites had to use tooling like Vulcanize to inline their contents into the main page. See https://www.polymer-project.org/1.0/docs/tools/optimize-for-production for example. Hayato or the rest of the DOM team can weigh in further.


Yeah, in practice, I think most sites are using Vulcanize at this point.
Polymer has already switched to use ES Modules, and I've not heard any significant performance regression on this switch, compared to HTML Imports.

Interesting. Was the existing implementation not optimized to go through preloadScanning and progressive DOM building? Or are the payloads typically used too small for it to make a difference?


I don't think any implementation of ES Modules are doing progressive DOM building. I think you can get more insights from ES Modules owners.

Apologies for not being clearer. By "existing implementation" I was referring to the current HTML imports implementation.

 

We know that ES Modules couldn't be a replacement of HTML Imports because they solve a different problem, however, from the performance perspective, ES Modules shouldn't be less performant than HTML imports.

Can the HTML modules model enable progressive tokenization and DOM building?
 

That is basically up-to UA. I don't see any reason Blink can't do that for HTML Modules.

I guess the reason you asked these questions is to let us know that HTML Modules would be much better than ES Modules, regarding loading HTML and DOM building. Yup, that is the reason that we would like to move HTML Modules forward.

I was asking that because I wanted to know the answer :)
I wasn't sure if the reliance on ES modules as infrastructure would make it more difficult to process the HTML content progressively.

Glad to see you don't foresee any difficulties there, and glad to hear HTML modules is something the team continues to pursue.

I see. Thanks!

We should feel sorry that Polymer *had to* switch to ES Modules. If the Web Platform had HTML Modules, Polymer would have switched to HTML Modules, instead of ES Modules!

Unfortunately, we couldn't make it happen. :(
 
 
 
ES Modules' performance is getting better and better, I think.

In addition to that, as Olli@ pointed out in this thread, other browsers never get performance benefits from HTML Imports.

Polymer team would have more insights on the performance.

--
Hayato

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1xd02xp8vVCiA8bPUi7kZor%3DEKJqOrNxeGu5xoSpJHEA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.


--
Hayato


--
Hayato

Yoav Weiss

unread,
Aug 17, 2018, 3:32:28 AM8/17/18
to Hayato Ito, Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
Given the fact that switching to ES modules based loading didn't have associated regressions, I withdraw my previous objections to removal of HTML imports.

Breakage may be higher than the typical threshold, but any missing imported functionality in affected pages is already missing in other browsers.

Looking forward to seeing progress on progressively-loaded HTML modules.

Hayato Ito

unread,
Aug 17, 2018, 3:52:35 AM8/17/18
to Yoav Weiss, Domenic Denicola, Philip Jägenstedt, Nelson Silva, blink-dev
Yoav and API owners,

Thank you for the comments. We really appreciate that.
I think this intent got 3> LGTM-ed, so let us proceed.
We'd keep this thread up to date.



--
Hayato

Philip Jägenstedt

unread,
Aug 19, 2018, 4:41:35 PM8/19/18
to Hayato Ito, Yoav Weiss, Domenic Denicola, Nelson Silva, blink-dev
Best of luck with the removal, Hayato-san and DOM team, it might be a little bit bumpy, but I definitely think it's the right choice for long-term interop and web developer's being able to depend on Shadow DOM and Custom Elements just working the same everywhere.

Pavel Feldman

unread,
Aug 26, 2018, 11:19:18 PM8/26/18
to Philip Jägenstedt, Rick Byers, Domenic Denicola, Hayato Ito, Nelson Silva, Yoav Weiss, blink-dev
Last time I checked, we did not have an agreement on the Shadow DOM V1 with Safari. How is Blink deprecating V0 with no prospect of V1 being consistent across vendors?

Or are the discrepancies with the selection model and registration resolved and we have an agreement with other vendors on the path forward?

Hayato Ito

unread,
Aug 27, 2018, 4:15:11 AM8/27/18
to pfel...@chromium.org, Philip Jägenstedt, Rick Byers, Domenic Denicola, Nelson Silva, Yoav Weiss, blink-dev
Safari had already shipped Shadow DOM v1.

The followings are what you might want to check:
--
Hayato

PhistucK

unread,
Aug 27, 2018, 4:17:32 AM8/27/18
to Hayato Ito, Pavel Feldman, Philip Jägenstedt, Rick Byers, Domenic Denicola, Nelson Silva, Yoav Weiss, blink-dev
But is there full parity in shadow DOM v1 and custom elements v1 (I seem to remember the intents mentioned they were opposed to extending native ones or something like that)?

PhistucK


Hayato Ito

unread,
Aug 27, 2018, 4:29:02 AM8/27/18
to PhistucK, pfel...@chromium.org, Philip Jägenstedt, Rick Byers, Domenic Denicola, Nelson Silva, Yoav Weiss, blink-dev
If someone finds any inconsistency of the behavior in particular case, we'd r