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

[Hayato Ito‏]

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‏]

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‏]

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.

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.

[smaug‏]

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)

>
>
> 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

> *

>
> --
> 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/CAFpjS_2%3DWVFFf8fK%2BXrOJmw-_a6nBO1YqzA%2BUaaiOpm1UK-xyQ%40mail.gmail.com

> <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‏]

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‏]

> 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‏]

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.

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.

--

TAMURA Kent
Software Engineer, Google

[Nelson Silva‏]

"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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83fe2c3d-ca2c-4879-b84b-0aae39faca55%40chromium.org.

--

Hayato

[Philip Jägenstedt‏]

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‏]

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‏]

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‏]

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‏]

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.

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.

[Yoav Weiss‏]

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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhf-5xd1hVPUu%2B9qTyawvSJA%2Bz06OO5_ztQUo6Dc%2By2dg%40mail.gmail.com.

--

Hayato

[Yoav Weiss‏]

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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhf-5xd1hVPUu%2B9qTyawvSJA%2Bz06OO5_ztQUo6Dc%2By2dg%40mail.gmail.com.

--

Hayato

--

Hayato

[Yoav Weiss‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_0zGUXd6gHQMJFrBwSZvW9buZm-OCp4v_AbQbqPO86wrA%40mail.gmail.com.

[Hayato Ito‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjrne99e1UVtmhfkmEgqRtjH_wPuSnzdJYN0D66EVVJ_g%40mail.gmail.com.

--

Hayato

[Philip Jägenstedt‏]

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‏]

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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYebYDX%2BcX7U_5CFifr70vyT7Zy9%3Dn-ow1fpwQk5Z_SHiA%40mail.gmail.com.

[Hayato Ito‏]

Safari had already shipped Shadow DOM v1.

The followings are what you might want to check:

- Can I use shadow dom v1: 

- [blink-dev] Intent to implement: Shadow DOM v1

--

Hayato

[PhistucK‏]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_2U2uZvHgq0PA8FJ_43deVagks75R1Y9akGc-_pmcnB7A%40mail.gmail.com.

[Hayato Ito‏]

If someone finds any inconsistency of the behavior in particular case, we'd recommend to file a bug for Chrome, Safari, or Firefox.

We have been trying to improve an interoperability, as usual. I think we can respond there.

Regarding extending native ones, this Intent to Ship: Customized Built-in Elements might be what you might want to check.

--

Hayato

[Pavel Feldman‏]

If owners consider deprecation to be the best course of action, I'll obey. But I'd like to make sure owners' decision is informed before I do.

My understanding is that Safari's Shadow DOM v1 is different from Blink's. I.e. DevTools, AdBlock, YouTube, Polymer would work in Chrome, but not in Safari. We are not talking about bugs in the spec implementation, we are talking about the whole systems and apis such as selection model.

So I'm confused why we are pushing for deprecation instead of resolving these inconsistencies. If we have a plan for the mitigation of these discrepancies, we should get ourselves enough of a runway to act on it before we deprecate v0. I might be overestimating the impact and scale of incompatibility, but I'd like to encourage OWNERS to review them and confirm that they are still comfortable with the deprecation.

I can add them to the thread where we discussed it with the team, Rick and myself. We had a nice plan for it back then, but instead of executing on that plan we are seeing another attempt to deprecate.

Pavel

[Anne van Kesteren‏]

On Mon, Aug 27, 2018 at 3:35 PM Pavel Feldman <pfel...@chromium.org> wrote:
> My understanding is that Safari's Shadow DOM v1 is different from Blink's. I.e. DevTools, AdBlock, YouTube, Polymer would work in Chrome, but not in Safari.

Isn't that because YouTube (not sure about the others) uses "v0" and
not the standardized APIs? Other than customized built-in elements I'm
not aware of any outstanding disagreements on the standardized API.
Pointers appreciated.


--
https://annevankesteren.nl/

[Pavel Feldman‏]

I believe that would be https://github.com/w3c/webcomponents/issues/79.

We deal with editors and other nested shadow trees that have selection.

a) It is essential that we can control selection that spans across shadow trees.

b) It is essential that this API does not break half-way as we align with Safari.

If both (a) and (b) are in place, there are no other blocking issues from our side.

Pavel

[Rick Byers‏]

Some context here: I've previously argued that we should be treating devtools like any other major web property (not as an implementation detail in Chrome like we do with WebUI). Their versioning model means that they have similar concerns around the stability of the platform over time and have learned to adopt a policy similar to most web developers of not depending on non-standard behavior (although they have lots of legacy from before this policy was adopted).

So from that perspective, I do think the fundamental question Pavel raises here is worthy of consideration: is there editing functionality which DevTools is relying on today which is not yet available as a standardized alternative? I.e. can they control selection that spans across shadow trees by relying only on behavior that is standardized or at least a implemented consistently between chromium and one other engine (ideally covered by "defacto" web-platform-tests).

Hayato, what's your take on that question?

[Yoichi Osato‏]

From the spec side, there is a kind of inconsistency between shadow and selection:from selection, there must be at most one treescope in a window but shadow adds two or more.

I raised the issue in last TPAC.

https://github.com/yoichio/public-documents/blob/master/selectionapiforshadow.md

Other vendors confirmed the issue but not be interested in.

Current Chrome selection implementation for shadow(v0/v1) somehow works for crossing shadow boundary.

So even chrome violates the spec but current spec prohibits user to select things across the boundary that is why we violates the spec.

2018年8月28日(火) 3:32 Rick Byers <rby...@chromium.org>:

--

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/CAFUtAY_dhcv7gKdCWXZEfac%2BNZOP96%3Dtfh8jNRhBS_Np4H0s%3DQ%40mail.gmail.com.

[Hayato Ito‏]

The section is what you might want to check. This section has been there for a long time. 

That is *never* standardized.

Given that, it's still unclear to me what would get worse at Shadow DOM v1, compared to Shadow DOM v0, regarding editing.

> there editing functionality which DevTools is relying on today 

We'd appreciate what behavior DevTools is relying on Today which is available on Shadow DOM v0, however, it is unavailable on Shadow DOM v1.

AFAIK, regarding editing, there is no difference at this point between Shadow DOM v0 and Shadow DOM v1. Nothing changed.

--

Hayato

[Pavel Feldman‏]

On Mon, Aug 27, 2018 at 7:40 PM Hayato Ito <hay...@chromium.org> wrote:

The section is what you might want to check. This section has been there for a long time. 

That is *never* standardized.

The spec says "Implementation should do their best to do what's best for them.". What do you mean "that is never standardized"? I think we should standardize it though?

I understand how we are interested in shipping v1 incrementally, but the spec has gaps, sometimes large and with no shared visions among the vendors. We are forcing v0 adopters to migrate to v1 today. Does this mean that we will be pushing them to v2 again once selection, aria references and other areas are aligned and implemented?

My only goal was to raise the awareness among the OWNERS, which I believe I achieved. I trust them to make the right call.

[Hayato Ito‏]

Regarding https://github.com/w3c/webcomponents/issues/79,

There are a lot of API changes at Shadow DOM v1, however, the editing is one of the areas which doesn't change at v1.

I remember that we, browser vendors, considered the editing as "v2" issue; it can be addressed in the future, however, we thought that the editing is not a blocking issue for us to have a v1 at that point. Neither v0 and v1 has resolved this issue.

We'd appreciate if you can give us feedback in the issue so that we'd consider that as a high priority issue for us.

--

Hayato

[Hayato Ito‏]

On Tue, Aug 28, 2018 at 12:19 PM Pavel Feldman <pfel...@chromium.org> wrote:

On Mon, Aug 27, 2018 at 7:40 PM Hayato Ito <hay...@chromium.org> wrote:

The section is what you might want to check. This section has been there for a long time. 

That is *never* standardized.

The spec says "Implementation should do their best to do what's best for them.". What do you mean "that is never standardized"? I think we should standardize it though?

I meant "This section is non-normative".

 

I understand how we are interested in shipping v1 incrementally, but the spec has gaps, sometimes large and with no shared visions among the vendors. We are forcing v0 adopters to migrate to v1 today. Does this mean that we will be pushing them to v2 again once selection, aria references and other areas are aligned and implemented?

My only goal was to raise the awareness among the OWNERS, which I believe I achieved. I trust them to make the right call.

Yup, thanks! Let's resolve editing issue or other areas together! I hope these areas would get much attention so that we could consider that as a high priority issue, and resolve that.

--

Hayato

[Hayato Ito‏]

FWIW, we have a plan to discuss Selection handling + shadow DOM at this year's Web Components F2F for 2018 TPAC.

If someone find any feature request or any idea, we'd really appreciate if you can enter feedback here.

--

Hayato

[j.j.‏]

Entry on the feature dashboard

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

There is no hint to deprecation and removal here:

 

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

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

[Yoichi Osato‏]

Have you read https://www.chromestatus.com/features/4667415417847808 for V1 migration?

2018年9月7日(金) 9:48 j.j. <fri...@jeka.info>:

[Hayato Ito‏]

Thanks for pointing that out.

We've updated the chromestatus entries, marking these deprecated at M70.

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18b69fc4-0d23-496c-bc27-5a48aab97eb1%40chromium.org.

--

Hayato

[dpa...@google.com‏]

On Thursday, August 9, 2018 at 2:58:03 PM UTC-7, PhistucK wrote:

> 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.

Even if Chrome's WebUI (chrome://settings,history,downloads,extensions etc) is functional with the HTML import polyfils, performance matters a lot in this case, so this could be definitely a problem. This needs to be audited, especially given the fact that we (WebUI team), are not very likely to have moved away from HTML imports by April 2019.

 

☆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.

[Yoichi Osato‏]

It could be, yes, we should first measure the impact of WebUI on polyfils where and how.

+Peter Burns from Polymer team will help you immigrate HTML Imports.

2018年9月10日(月) 7:08 dpapad via blink-dev <blin...@chromium.org>:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38fa5f9d-b54e-4758-8b97-aa8895ca2bf0%40chromium.org.

[patrik.n...@gmail.com‏]

Why use ES modules when google style guide for Javascript (https://google.github.io/styleguide/jsguide.html) at 3.3 4 says not to use ES modules?

[Hayato Ito‏]

We don't need to follow Google JavaScript Style guide, which is just one of coding standards available in the worlds.

On Thu, Oct 18, 2018 at 12:42 AM <patrik.n...@gmail.com> wrote:

Why use ES modules when google style guide for Javascript (https://google.github.io/styleguide/jsguide.html) at 3.3 4 says not to use ES modules?

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3abf42d5-255b-4efd-8b2c-9f1b5e8dca1b%40chromium.org.

--

Hayato

[Yoichi Osato‏]

> We create link rel="imports" on the fly and no polyfill helps in that case. 

Dynamic-imports doesn't help you?

https://github.com/webcomponents/html-imports#dynamic-imports 

2018年10月22日(月) 12:31 <micb...@gmail.com>:

Hello, we have been developing lots of webapps with WebComponents since 2016. We create link rel="imports" on the fly and no polyfill helps in that case. Our app defines WebAudio plugins that can be dynamically imported on demand in host applications. 

We understand clearly that html imports will not be adopted. Please, before discarding them, can the WebComponent WG publish a guide for helping us migrating to something that will be supported ? How can we replace our imports by ES6 modules? I just can't see any solution except bundling everything in JS using Webpack + plugins... Is that the solution you suggest?

Michel

Le lundi 30 juillet 2018 09:35:19 UTC+2, Hayato Ito a écrit :

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

[micb...@gmail.com‏]

[luk...@google.com‏]

<+icle...@chromium.org and +experimen...@chromium.org for origin-trials related questions below>

Removal of HTML imports would help improve security guarantees offered by Site Isolation in presence of compromised renderer processes - see https://crbug.com/871827.

How can I learn more about (reverse) origin trials?  Would the browser process be aware of the trials when creating/vending a URLLoaderFactory (at ReadyToCommitNavigation time or later / after seeing response headers corresponding to the navigation)?  Or are origin trials only processed/recognized at the Blink layer / in the renderer process?

If browser process is currently unaware of origin trials, then would it make sense to change that and provide a generic way to let the browser process know (via RenderFrameHost?  via NavigationHandle?) what origin trials are active in a given frame^H^H^Hdocument and/or navigation?  Should I go ahead and open a crbug to track this work?  I know of at least one other case where such browser-process-knowledge would be useful (origin-level performance isolation experiments that alexmos@ and mbolohan@ were looking into).

If browser process is aware of origin trials, then I hope that the ability to use unconstrained |request_initiator| can be restricted only to the renderer process that are hosting sites that opt into HTML Import reverse origin trials.  This way the rest of sites would be able to depend on |request_initiator_origin_lock| coming from the browser process instead.

Looking at https://cs.chromium.org/chromium/src/docs/origin_trials_integration.md I see the following, which seems rather discouraging :-)  :

if you need to know in the browser process whether a feature should

be enabled, then you will have to either have the renderer inform it at runtime,

or else just assume that it's always enabled, and gate access to the feature

from the renderer

-Lukasz

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<span style="font-s

[Yoichi Osato‏]

Here is the thread for the reverse origin trial in experimen...@chromium.org:

https://groups.google.com/a/chromium.org/forum/#!topic/experimentation-dev/lrmxlU-Ddxk

2018年11月16日(金) 2:51 <luk...@google.com>:

[nae...@gmail.com‏]

On Monday, July 30, 2018 at 3:35:19 AM UTC-4, Hayato Ito wrote:

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.

Since nobody seems to have said PDF in this thread yet, I'm just going to point out that the PDF "extension" (<chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html>) seems to use all three features, as of Google Chrome 70.0.3538.110 (Official Build) (64-bit). If the paths of the loaded scripts are any indication it's using Polymer v1.0, and index.html is full of HTML imports, so I'm going to go out on a limb and say that it's not polyfilled right now.

So, while that's no doubt a smaller contributor than Youtube is/was, it still presumably contributes to your stats ...

[Yoichi Osato‏]

Thank you for raising.

Yes, the extension is using v0s (yet). The ext should be migrated of will get broken after M73.

I'm seeking and/or contacting huge contributors other rather Youtube for migration.

Thanks.

2018年12月2日(日) 7:18 <nae...@gmail.com>:

[Yoichi Osato‏]

Thanks everyone for reviewing this and preparation work.

Since some Chrome internal components/tests using the APIs didn't finish migration work and some new ones were found, I decided to postpone API removal to M74.

Here is updated timeline:

2019 Q2(M74)

Disable the APIs.

Start reverse origin trials since M74 beta launches.

2020 Q2(M81)

Stop accepting origin trials (would be cut earlier if usage is enough low).

Remove the code and no one can use the APIs anyway.

Tracking bugs for the internal migration (I hope I’m grabbing all blockers):

DevTools: crbug.com/685385

WebUI: crbug.com/738611

PDF: crbug.com/924031

Browser tests: crbug.com/924034

External usage: Chrome status (as 2019 Jan current). Diff is from 2018 July as the first intent mail.

• Shadow DOM V0: 1.5% (-0.2%)

• Custom Elements V0: 4.5% (-0.5%)

• HTML Imports: 1.8% (-0.2%)

The usage is still high but I didn’t find any big sites using the APIs except YouTube. I got to feel there was a metrics magic and the stat didn’t reflect actual usage,,,

2018年12月3日(月) 11:03 Yoichi Osato <yoi...@chromium.org>:

[michel buffa‏]

Hi, is there a guide somewhere that explains how to replace html imports by ES modules? We developed a WebAudio plugin format, each plugin being a WebComponents that is downloaded by adding dynamically an html import to the DOM... How can we change that elegantly? Compile the whole code with a bundler into a single ES module and then dynamically add a script tag?

Are there any text / tutorial explaining this migration?

Thanks in advance!

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/h-JwMiPUnuU/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAAEV3pnCPGUTYQV0xtVkfdF9yqCt8m1Xekn39jG7YFFE7ROE6A%40mail.gmail.com.

[rictic‏]

 > How can we change that elegantly? Compile the whole code with a bundler into a single ES module and then dynamically add a script tag?

That would work. You could also use script type="module" to load individual modules in modern browsers similarly to how you're using HTML Imports today, and use a second script with the nomodule attribute to load that bundled script in older browsers.

[jeffrey...@gmail.com‏]

Hi,

We are using Polymer 2 components on our site, and I'd like to test the deprecation of HTMLImports in Chrome 73.

The documentation specifies using the following Chrome flags: --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports

But when I use these flags Chrome (version 72) starts with the message "You are usin an unsupported command-line flag: --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports. Stability and security will suffer."

I've also tried Chrome DEV (73) and Chrome Canary (74) but these give the same results as version 72 and earlier (it looks like the HTMLImports are still present in these versions as well)

Can somebody tell me how to test if our components keep working with version 73?

Op maandag 30 juli 2018 09:35:19 UTC+2 schreef Hayato Ito:

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.

[Peter Burns‏]

The simplest solution would be to try your app in another browser. If it works in Firefox, Safari, or Edge, then you're loading the HTML Imports polyfill correctly and you should get the same behavior once Chrome disables these features.

--

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/h-JwMiPUnuU/unsubscribe.
To unsubscribe from this group and all its topics, 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/4c413fcf-964b-46fb-ab94-352c767d0bfc%40chromium.org.

[Jeremy Roman‏]

On Wed, Jan 30, 2019 at 12:14 PM <jeffrey...@gmail.com> wrote:

Hi,

We are using Polymer 2 components on our site, and I'd like to test the deprecation of HTMLImports in Chrome 73.

The documentation specifies using the following Chrome flags: --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports

But when I use these flags Chrome (version 72) starts with the message "You are usin an unsupported command-line flag: --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports. Stability and security will suffer."

This is because enabling and disabling our features, while it may be useful for quick tests like this, is not a supported configuration to be running Chrome in generally. We don't test non-default configurations and it is possible that some configurations you could create in this way may not work correctly. The warning is there to discourage you from running with these flags on an ongoing basis. You can check that HTML imports is off, for instance, by checking

'import' in HTMLLinkElement.prototype

 

(I believe it's false if HTML imports are disabled.)

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

[jeffrey...@gmail.com‏]

That's good news, in the other browsers the components work! So the polyfill is loaded correctly.

Thanks for the quick reply

Op woensdag 30 januari 2019 21:20:06 UTC+1 schreef rictic:

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 <span style="font-size:9.5pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-

[jeffrey...@gmail.com‏]

You're correct, with the --disable-blink-features turned on,

'import' in HTMLLinkElement.prototype == FALSE

and without the blink features

'import' in HTMLLinkElement.prototype == TRUE

Our components keep working in both situations :)

Thnks for the reply

Op woensdag 30 januari 2019 22:26:41 UTC+1 schreef Jeremy Roman:

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<span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:

[thomasmu...@yahoo.com‏]

Hi, does this mean PolyGerrit will stop working in chrome? It uses Polymer 1.x and also i see the deprecated warning in the browser console log.

[PhistucK‏]

Did you check whether it works with the flags?

I understand Gerrit works in non-Chrome browsers (that never supported shadow DOM/custom elements v0 and HTML imports), so I expect it to continue working when all of those are removed (barring any stinky browser detection).

☆PhistucK

On Fri, Feb 1, 2019 at 6:09 PM thomasmulhall410 via blink-dev <blin...@chromium.org> wrote:

Hi, does this mean PolyGerrit will stop working in chrome? It uses Polymer 1.x and also i see the deprecated warning in the browser console log.

--

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/b983e22c-ec16-4947-9a56-6dfcddf82e09%40chromium.org.

[fau...@thexs.ca‏]

We are now testing some older apps built with Polymer v1

When using Chrome 73 (beta) and Chrome 74 (dev) the 

'import' in HTMLLinkElement.prototype == TRUE

It looks like v73 and v74 still include the ShadowDOMV0,CustomElementsV0,HTMLImports 

Is that correct or am I missing something?

Note: even though Event.path was originally defined with Shadow DOM V0, and is superseded by <a href="https://dom.spec.whatwg.org/#dom-event-composedpath" style="text-decoration:none" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fdom.spec.whatwg.org%2F%23dom-event-composedpath\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFHN80EAVP7Ce0PZehZaQiI39Jg7A';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fdom.spec.whatwg.org%2F%23dom-event-composedpath\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFHN80EAVP7Ce0PZeh

[Mike West‏]

yoichio@, can you give us an update on the expected status for M74?

-mike

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c221134b-634d-4232-a2f9-43aa433b412e%40chromium.org.

[Yoichi Osato‏]

> It looks like v73 and v74 still include the ShadowDOMV0,CustomElementsV0,HTMLImports.

Yes, we don't remove the APIs on any Chrome.

> yoichio@, can you give us an update on the expected status for M74?

Sure.

For M74, I will disable the APIs.

We're working for migration:

 DevTools: finished.

 WebUI: on-going.

 PDF: on-going.

 Browser tests: finished.

Actually since WebUI and PDF look not finish whole work, I let (only) them use the APIs.

It is like reverse origin trial and they should finish the work within 1 year, too.

2019年2月17日(日) 6:07 Mike West <mk...@chromium.org>:

[jerem...@gmail.com‏]

Hi yoichio,

Do you have any updates on when it will be removed in canary(version is 74 now). We would like to plan the migration path and time, so that it doesn't impact our end users. We have quite a few applications which are using v0 spec. And how about the "reverse" origin trials, will it follow the same link as origin trials or is there a special link we should be looking for.

Please let us know, if there any updates. Or if there is a way we can disable now, so that we can see the impact and how the polyfill behaves.

Thank you :)

Jeremy

To view this discussion on the web visit <a href="https

[Yoichi Osato‏]

This is the patch to remove the APIs. I'm working to commit this.

https://chromium-review.googlesource.com/c/chromium/src/+/1481130

2019年2月28日(木) 2:28 <jerem...@gmail.com>:

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/e7cf0f89-623b-40e6-99ab-928992a43182%40chromium.org.

[Hayato Ito‏]

Hi Jeremy,

I chatted with yoichio@. We are still working on CLs which are blockers to disable APIs. There is an on-going effort.

So v0 APIs are still available on Chrome Canary, I think.

We'll update the thread later.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e7cf0f89-623b-40e6-99ab-928992a43182%40chromium.org.

--

Hayato

[Yoichi Osato‏]

The patch was landed!

Next canary will be v0-removed one.

2019年2月28日(木) 17:35 Hayato Ito <hay...@chromium.org>:

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_2bMF0bgM7Jd_a%3DVjUkyg1vfEmxgZjG%3D3OLtB44urC%3D%2Bw%40mail.gmail.com.

[Yoichi Osato‏]

We're on track.

The v0 APIs will be removed since M74.

2019年3月1日(金) 17:01 Yoichi Osato <yoi...@google.com>:

[Nelson Silva‏]

So, Chromium, which has hundreds of contributors. is struggling to find the time and resources to do the required work in preparation for the removal of V0 APIs and HTML imports but concern is to remove the APIs asap, because everyone else who is currently relying on those APIs will surely be able to do a better job....

Most of Chrome internal usage (such as Chrome Web UI) has migration plans and it is tracked at <span style

[Thomas Steiner‏]

There’re user reports about issues with YouTube and Canary regarding this change: http://twitter.com/infowolfe/status/1102251085308268544.

[Philip Jägenstedt‏]

Hi Nelson,

A great deal of time and resources have gone into removing these APIs in a responsible manner, consistent with the Blink principles of web compatibility. No doubt there is still work required be those who used these APIs to transition to the APIs that work cross-browser. Can you elaborate on what additional groundwork you think is needed here?

Thanks!

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15f6f8a2-eecb-4d5f-9956-f57717c717b6%40chromium.org.

[PhistucK‏]

I think Nelson refers to the fact that internally, Chrome will still be using the deprecated/removed APIs for the time being, while externally, you expect developers to stop using it when "even you cannot make it in time".

☆PhistucK

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/CAARdPYcuSa2p%3D%3DWxWdsoRzNwnp928KUsQvu6O%2BsqT3voOV25FA%40mail.gmail.com.

[Philip Jägenstedt‏]

Internally in DevTools, or elsewhere as well? Hayato-san, is there a tracking bug for transitioning that too?

[Nelson Silva‏]

Hi Philip,

I've expressed my point previously on this thread. Essentially I feel the removal of these APIs was hasty, especially for HTML imports which should not be coupled with removal of Custom Elements V0 APIs.

ES modules support landed in 2017 so the "alternative" for HTML imports arrived almost a year after CE and Shadow DOM V1 were introduced. Support for dynamic imports arrived even later and cross browser support is still in its infancy.

I am all for the removal of non standard and/or deprecated APIs but once an API goes public people will build things leveraging it (ie Polymer 2 released in 2017, with only Polymer 3 moving away from HTML imports in mid 2018) so a proper maintenance and deprecation window should be ensured and a migration path / alternative should be available.

IMHO the fact that Chromium, YouTube, etc.. teams are on a race against the clock to make sure all the required changes land before this removal should be a sign that the window was just too short in this particular case.

Thanks,

Nelson

[PhistucK‏]

The Developer Tools team has finished the migration. :)

Elsewhere, like the PDF viewer extension and a few more.

There are issues for (some of?) them, they block -

crbug.com/806159

crbug.com/766694

☆PhistucK

[Philip Jägenstedt‏]

The total timeline for this deprecation+removal is probably the longest of any in the Blink project's history, but deprecation period is only 3 milestones before it is turned off by default. That's about 4.5 months from first console message to the API going away be default, but with the ability to turn it back on until some time in 2020Q1. Is it the short time to react the deprecation messages that is problematic, or that 2020Q1 is not far enough into the future?

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d4db639c-d7a3-4bc4-bc60-cc53e8a50e56%40chromium.org.

[Yoichi Osato‏]

Updates: postpone API removal to M75.

Since web sites including YouTube got broken due to the API removed canary, the patch was reverted. I heard that YouTube was migrating and effect was small,,,

Because no any short-term solution from Blink side, I decided to postpone API removal to M75.

External usage: Chrome status (as 2019 Mar current). Diff is from 2018 Jan.

Shadow DOM V0: 1.5% (+-0)

Custom Elements V0: 5.0% (+0.5%)

HTML Imports: 2.1% (+0.3%)

I don’t know why the usage is increasing,,,

Anyway we need more effort for web authors to migration.

There are reverse origin trials, deprecation messages and PR efforts.

However I don’t know any better solution to move this forward rather than just removing APIs.

How about throttling performance?

2019年3月4日(月) 19:31 Philip Jägenstedt <foo...@chromium.org>:

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/CAARdPYdNEPS2G5wa99LCM9ZazqaAerKib5T39iycUSeWSz6fKQ%40mail.gmail.com.

[michel buffa‏]

Hi! We're using HTML imports a lot in some of our apps, we developed WebAudio applications with a plugin system that loads dynamically virtual instruments and effects by adding on the fly HTML imports... Changing this will involve on our side using ES modules and compiling all our components in ES, etc. This is a huge change in all our SDKs and specs for plugin developers, and adds a lot of extra steps in order to develop and pack a plugin. Before it was 100% declarative, and just using standard ES features, emulating what the import did is not just changing a few lines of code.

At least, a tutorial/guidelines/guide on how to migrate an application that relied on imports to something that will work in the future would have been highly appreciated. Or maybe such a guide exists and I missed its link?

Thanks in advance for guidelines about how we should do this migration...

Michel

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/h-JwMiPUnuU/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAAEV3pkcddY-MT9YaodqQdUROFq0BhwaOkD1n93FzYRY%2BzYLPg%40mail.gmail.com.

[PhistucK‏]

Is your application Chrome only (only Chrome supported HTML imports)? If so, that was probably a big mistake...

If it works in non-Chrome, you might just need to update or fix your polyfills.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL7pXh2homd8U%3DLvPf607JTbiMQn6zERFLy6DQiYEdidwq%3DjmA%40mail.gmail.com.

[michel buffa‏]

We're using polyfills but apparently they break when inserting link rel = imports dynamically. I will investigate...

[cheruk...@gmail.com‏]

Yoichi,

We enrolled in the reverse origin trial.

Is there any way to test and confirm if the reverse origin trial is working for our apps with the latest Chrome 74?

-DC

<span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transpa

[Yoichi Osato‏]

Thanks. 

You can test your origin trial token on "chrome.exe --disable-blink-features=HTMLImports,ShadowDOMV0,CustomElementsV0".

2019年3月7日(木) 9:19 <cheruk...@gmail.com>:

--

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/f18906db-f69c-45cf-961e-bdddb40b8a64%40chromium.org.

[cheruk...@gmail.com‏]

Thanks Yoichi.

When i start chrome with --disable-blink-features, I am unable to open chrome developer tools. I see the following errors in the terminal where I opened chrome with the --disable-blink-features

[88538:28219:0307/074059.363748:ERROR:begin_frame_provider.h(60)] Not implemented reached in virtual void blink::BeginFrameProvider::BindSurfaceEmbedder(mojom::blink::SurfaceEmbedderRequest)

2019-03-07 07:41:08.578 Google Chrome[79749:6547063] action itemSelected:

[79749:775:0307/074109.271935:ERROR:CONSOLE(3123)] "Uncaught TypeError: document.registerElement is not a function", source: chrome-devtools://devtools/bundled/shell.js (3123)

[79749:775:0307/074109.281596:ERROR:CONSOLE(2)] "Uncaught ReferenceError: SDK is not defined", source: chrome-devtools://devtools/bundled/devtools_app.js (2)

Is there any way to see the developer console also?

-DC

[PhistucK‏]

Are you sure you are launching the latest Chrome 74? The Developer Tools no longer use document.registerElement(...) since about a month and a half ago.

https://github.com/ChromeDevTools/devtools-frontend/commit/7fbe24c094a53d6a95cbb0d19b4bf889c7dcee53?w=true

☆PhistucK

--

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/6cf3bb46-0241-410b-a60f-3560d997cc7a%40chromium.org.

[cheruk...@gmail.com‏]

Thanks PhistucK.

I switched to chrome 74 using /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports

Looks like nested HTML imports are not working anymore.

Only the top level HTML import is successfully get imported. i.e., if the HTML import is in index.html then the browser downloads it correctly.

I created a sample app (https://gepoc.vo.llnwd.net/static/polymer1-app/index.html) to show this problem.

App folder structure is:

index.html

bower_components

--polymer

----polymer.html

----polymer-micro.html

----polymer-mini.html

src

--polymer1-app

----polymer1-app.html

index.html has the reverse origin trial token.

index.html has an HTML import for polymer1-app.html. This gets successfully imported

polymer1-app.html has HTML imports for ../../bower_components/polymer/polymer.html and this FAILS or is ignored. Browser displays a blank screen. Chrome developer tools - console shows error: Uncaught ReferenceError: Polymer is not defined

    at polymer1-app.html:14

You can see that the sample app(https://gepoc.vo.llnwd.net/static/polymer1-app/index.html) works fine if I don't disable the web components v0 features i.e., if I open the app in a normal Chrome browser.

Any help would be greatly appreciated.

-DC

[PhistucK‏]

Can you file this at crbug.com, please? You can reply with a link to the created issue.

Thank you!

☆PhistucK

--

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/0b53f069-7036-4fa1-abf6-b510ce95f64f%40chromium.org.

[cheruk...@gmail.com‏]

Yoichi,

I opened the following crbug issue for "nested HTML imports not working" with reverse origin trial.

https://bugs.chromium.org/p/chromium/issues/detail?id=939465&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Please let us know if we are doing something wrong here.

Please also let us know if you need additional information to help troubleshoot this problem.

-DC

2019年3月7日(木) 9:19 <cheruk...@gmail.com>:

• 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 <a href="https://crbug.com/806159" style="text-decoration:none" rel="

[tigerh...@gmail.com‏]

ES Modules are still not supported by the Google WebcComponents team uniformly -- see https://www.webcomponents.org/element/googlewebcomponents/google-map and the corresponding https://github.com/GoogleWebComponents/google-map for a nice high-profile one.

In fact, plenty of the web components published by Google themselves haven't received updates (though a few have): https://github.com/GoogleWebComponents .

I agree with others that this whole process is being very rushed, especially if Google can't pull it off in-house during their own time frame!

I would suggest that 2-3 milestones after internal Google projects and properties all have been updated as the earliest milestone for removal. You can't expect to hold others to a standard you can't meet yourself.

• 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

[j.j.‏]

Am Dienstag, 5. März 2019 07:02:10 UTC+1 schrieb Yoichi Osato:

Updates: postpone API removal to M75.

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)

still claim "will be removed in M73"

[Yoichi Osato‏]

> still claim "will be removed in M73" 

Thank you for reporting. Yes it should be updated.

2019年3月17日(日) 12:26 j.j. <fri...@jeka.info>:

--

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/51ac8385-f38a-4772-aad2-9eb96b74c4d8%40chromium.org.

[valeria...@elca.ch‏]

Hi Yoichi,

Is M75 the definitive version for this API removal? I'm still confused as this doesn't match other available informations. For instance

• crbug.com/806159 is marked for M76 and as blocking the API removal. Will the concerned systems have a specific access to the API?
• The API removal doesn't seem present on Canary. Do you plan to apply the change to it soon?
• It doesn't seem compatible with what was suggested earlier in this thread

• 
  

  I would suggest that 2-3 milestones after internal Google projects and properties all have been updated as the earliest milestone for removal.
  

• Do you plan to take it into account in the release planning of this API removal?
  

Thanks in advance for your clarification

On Monday, March 18, 2019 at 1:54:05 AM UTC+1, Yoichi Osato wrote:

> still claim "will be removed in M73" 

Thank you for reporting. Yes it should be updated.

2019年3月17日(日) 12:26 j.j. <fri...@jeka.info>:

Am Dienstag, 5. März 2019 07:02:10 UTC+1 schrieb Yoichi Osato:

Updates: postpone API removal to M75.

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)

still claim "will be removed in M73"

--
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 blin...@chromium.org.

[PhistucK‏]

Whoever is working on the deprecation/removal now - the Google Dictionary extension is apparently still using shadow DOM v0.

☆PhistucK

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/618019e8-5a59-41bc-a822-048a319bade1%40chromium.org.

[fau...@thexs.ca‏]

Considering M75 is already in beta without these changes, I guess,  it won't happen on M75

Even M76 is going Freeze in a week on May.17 and still doesn't have these changes, so it might not happen either on M76

I am happy with the delay, but it would be great to have some updates from the team on how is the current plan for this update

Thanks

[Mason Freed‏]

Sorry for the delay in updating this thread. As you (and others) have mentioned, clearly these features did not get removed in M73, primarily because the usage level is still high. We have a new target removal milestone of M80, and a blog post that goes into more detail about the delay, plus gives more pointers on removing v0 dependencies:

https://developers.google.com/web/updates/2019/07/web-components-time-to-upgrade

Please take a look - hopefully this is helpful.

[masatak...@gmail.com‏]

Hi.

On Tuesday, July 16, 2019 at 3:23:30 AM UTC+9, Mason Freed wrote:

Sorry for the delay in updating this thread. As you (and others) have mentioned, clearly these features did not get removed in M73, primarily because the usage level is still high. We have a new target removal milestone of M80, and a blog post that goes into more detail about the delay, plus gives more pointers on removing v0 dependencies:

https://developers.google.com/web/updates/2019/07/web-components-time-to-upgrade

Thanks for the update. One thing I wonder is if there will be the "reverse" Origin Trial period with the new plan. IIRC the M73 plan was to *disable* them by default in 73 and start grace period with the reverse Origin Trial opt-in to re-enable, then remove after that. But reading the article there won't be any such. Are you really going to remove then in M80

Thanks,

Masataka

[Mason Freed‏]

Hello, that's a great question, thanks. We didn't address that in the blog post, but yes, our intention is to continue the reverse Origin Trial for this removal. You can register for that origin trial here. The text on the page currently says that it will end in M80, but I will get that date/milestone extended beyond M80 very soon.

--

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/fb755860-ef4e-45f2-be11-b2ef6d8ae40a%40chromium.org.

[ultra...@gmail.com‏]

Maybe too late but I'll miss these apis, especially html imports; the solution is well thought and sustainable enough to grow its usage over time. What was the take of those who originally wrote the spec?

[mason...@google.com‏]

Following up on this thread, the M80 Canary build tomorrow (October 23, 2019) will disable Shadow DOM v0 and Custom Elements v0. For the very short term, HTML Imports will remain enabled, while we work to remove the first two features. There will likely be a period of time during which the features are enabled and disabled in Canary, as we find problems and work to mitigate them. These should all happen in M80 only - other versions should not be affected. Again, please see this post for further details.

[PhistucK‏]

What is the reason for separating them again?

☆PhistucK

--

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/74de1d25-08b8-4fb8-86bd-69e2336460b3%40chromium.org.

[Mason Freed‏]

On Tuesday, October 22, 2019 at 11:50:27 PM UTC-7, PhistucK wrote:

What is the reason for separating them again?

 

Good question. This is going to be a difficult set of features to remove. Because Polymer 2 still uses HTML Imports, and the user-base for Polymer 2 is higher than for version 1, it will be easier to first get through the initial hurdles of removing Shadow DOM and Custom Elements before moving on to HTML Imports. Our plan is still to remove HTML Imports in M80.

[PhistucK‏]

Oh. And Gerrit is now experimenting with Polymer 2... So is it basically experimenting with something deprecated? Or does it always come with a polyfill anyway (making this moot)?

A bit weird since Polymer 3 exists...

☆PhistucK

--
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/8ba4dce4-620f-4e3b-8952-da4b11bd08b2%40chromium.org.

[Demetrios Papadopoulos‏]

On Wed, Oct 23, 2019 at 1:09 PM PhistucK <phis...@gmail.com> wrote:

Oh. And Gerrit is now experimenting with Polymer 2... So is it basically experimenting with something deprecated? Or does it always come with a polyfill anyway (making this moot)?

A bit weird since Polymer 3 exists...

Migrating from Polymer1 straight to Polymer3 is not trivial, nor recommended. Migrating from 1 -> 2 -> 3 is the recommended path (AFAIK from reading Polymer docs and talking with the Polymer team). This is also the approach Chromium's own WebUI pages have followed so far. The following list might make it more clear what is used where

Deprecated APIs used by each Polymer version:

• Polymer1: Shadow DOM v0 or polyfil (aka Shady DOM), CustomElements v0, HTML Imports
• Polymer2: HTML Imports (with SDv1, CEv1)
• Polymer3: None (JS modules + SDv1 + CEv1)

1->2 migration is non trivial because there are several breaking changes in the core Polymer library between those versions

2->3 migration has no breaking changes in the core Polymer library, but the fact that HTML imports need to be changed to JS modules makes it non trivial as well.

Thanks,

Demetrios

☆PhistucK

On Wed, Oct 23, 2019 at 8:55 PM Mason Freed <mason...@chromium.org> wrote:

On Tuesday, October 22, 2019 at 11:50:27 PM UTC-7, PhistucK wrote:

What is the reason for separating them again?

 

Good question. This is going to be a difficult set of features to remove. Because Polymer 2 still uses HTML Imports, and the user-base for Polymer 2 is higher than for version 1, it will be easier to first get through the initial hurdles of removing Shadow DOM and Custom Elements before moving on to HTML Imports. Our plan is still to remove HTML Imports in M80.

--
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/8ba4dce4-620f-4e3b-8952-da4b11bd08b2%40chromium.org.

--

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/h-JwMiPUnuU/unsubscribe.
To unsubscribe from this group and all its topics, 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/CABc02_L0VUcndM8jtrd1CfMbV8mORZ%2B%3DQg-bp47hhSpgvC8z4A%40mail.gmail.com.