New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 13 users

Issue metadata

Status: Duplicate
Merged: issue 766694
Closed: Jun 2018
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 735633
issue 822135

issue 766694

Sign in to add a comment

Issue 523952: Deprecate and remove HTML Imports styling the main document

Reported by, Aug 24 2015 Project Member

Issue description

It is confusing behavior.

Comment 1 by, Aug 27 2015

Project Member
The following revision refers to this bug:

r201301 | | 2015-08-27T09:28:01.136288Z

Changed paths:

[HTMLImport] Add an Usecounter for the case imported document has stylesheets.

BUG= 523952 

Review URL:

Comment 2 by, Aug 30 2015

Currently imports block rendering the main page (they do not block parsing). With this change, does anything change in that regard? i.e. should imports become async by default?

Comment 3 by, Aug 31 2015

That's a good question, I think we might be able to make them async by default.

Comment 4 by, Aug 31 2015

We should definitely discuss that with the Polymer team if/when the switch is made. I know my own adventures using async imports has led to timing issues and even bugs.

Comment 5 by, Aug 31 2015

Styles not applying by default does not mean a prohibition on loading styles via imports. Rather, it means users will need to employ code to apply those styles. IMO, nothing about this issue changes the arguments wrt `async` being default.

Comment 6 by, Aug 31 2015

Ah yeah, async means scripts don't block on them, but then:

<link rel=import href=foo.html>
  new Foo()

doesn't work. So we can't change that.

Comment 7 by, Sep 1 2015

Project Member
The following revision refers to this bug:

commit d094e1a1a3c6ba266c7c1389f35bed9c0b52b25d
Author: yoichio <>
Date: Tue Sep 01 01:18:37 2015

Add some UMAs from Blink

Related CLs in Blink are following.
[HTMLImport] Add an Usecounter for the case imported document has stylesheets:
Add UseCounters for usage of -webkit-text:

BUG= 523952 

Review URL:

Cr-Commit-Position: refs/heads/master@{#346547}


Comment 8 by, Oct 2 2015

 Issue 537119  has been merged into this issue.

Comment 9 by, Oct 15 2015

Just FYI

Looks like is distributing a theme CSS
in the form of HTML which assumes to be imported.

If you try download a theme, it is zipped with 3 files, README.txt,
and 2 theme CSS, one is "*.css" and the other is "*.html".

According to its README, *.html version is intended to be imported to
the main document, while *.css version is to be imported from your
component, and the only diff between 2 files is that for the former
the CSS content is surrounded by <style></style> tag.

Comment 10 by, Mar 7 2016

yoichio@, are you still working on this?

Comment 11 by, Aug 1 2016

Status: Available (was: Started)

Comment 12 by, Aug 1 2016

Labels: html-imports
Status: Assigned (was: Available)

Comment 13 by, Oct 12 2016

Components: -Blink>WebComponents Blink>HTML>Modules

Comment 14 by, Feb 24 2017

Status: WontFix (was: Assigned)
It got too late to change the spec / impl.

Let's make HTML modules not repeat this.

Comment 15 by, Feb 24 2017

Could you help me understand what you mean by "too late"? Here is my thought process:

* we will need to deprecate and remove HTML imports at some point, and limiting style applications is a good stepping stone.

* according to use counters, style in imports have a shot at deprecation:

* Looking at the graph, I feel divided: on one hand, I am glad because I don't see the usage climbing rapidly, but at the same time, I am worried because I need more certainty in being able to remove it.

What do you think?

Comment 16 by, Feb 27 2017

Status: Assigned (was: WontFix)
Additional data: HTML Imports are used ~0.3%
and style in imports is ~0.04%

So still 10+% of HTML imports users use styling from imports, and
it seems not changing throughout last year.

I am wondering the balance between the cost of deprecating styling portion
which includes spec update and implementation/tests cleanup for breaking
10% of HTML imports users vs deprecating HTML Imports at once.

I'd like to reconsider realistic timeframe for deprecating.

Comment 17 by, Feb 27 2017

Ok. If I am hearing you correctly, you would like to better understand whether the benefit of the deprecating the styling portion outweighs its cost, and how that strategy compares to just deprecating HTML imports at once.

I am also realizing that I made an assumption that deprecating the styling is a good stepping stone for HTML Imports deprecations. This assumption may or may not be correct.

It sounds like we are both looking for a general strategy for HTML imports deprecation, and gaining clarity on these questions by developing that strategy. WDYT?

Comment 18 by, Feb 28 2017

Yes, in general we are going to deprecate and remove HTML imports at some point.

My mental model is like this:

HTML Imports will be removed in X months, and in Y (Y <= X) months
<style> application to main document will be removed. Deprecation starts
some fixed length (6 months?) before X and Y for each.

Probably X is greater than 12. And the closer Y becomes to 0, the larger
the cumulative benefit (less code complexity, etc.) will be.
The loss (breaking <style> in imports) may be constant, as the trend goes.
Deprecation period may help reducing this loss.

X is by far the more uncertain parameter than Y.

Above equates that starting Y as early as possible maximizes the benefit...
On the flip side, deferring Y as much as possible makes the benefit
become asymptotic to zero.  (this is behind what I felt "too late", if
I'd put it in logical)

Also, I was not sure the web developer's benefit - once <style> application
is removed, <style> will be inert but still can be used for a container of
stylesheet in an import as comment#5, which may be useful.

I vaguely suppose Y doesn't affect X, so starting Y sooner or later is not a
major factor to make X smaller.  But assuming X is big enough, then
the benefit of starting Y as early as possible can still outweigh the cost.

Comment 19 by, Feb 28 2017

I like your analysis. A couple of more points to add:

* To mitigate the negative impact of removing style application, we could try to publicize the fairly simple workaround -- just add a script that hoists the <style> elements back into the main document.

* Since the removal depends on the usage, we are likely very interested in actively driving the usage down. How can we do that? Some thoughts:

a) Ship an alternative primitive onto which to switch away from HTML Imports
b) Make switching easy (narrative, guides, tooling, etc.) 
c) Offer additional incentives for switching (deprecation campaign?)

What do you think? Do we have enough fodder to start a deprecation/removal strategy doc? Maybe try to discuss this it within the Sustainable Loading group?

Comment 20 by, Mar 2 2017

I also would like to add a point for the benefit:

Each <style> tag in an HTML import costs O(# of style sheets) per
<style> insertion, which results in O(N^2) where N = total number
of <style>s in document + imports (confirming +rune@ - are your
changes for activeStyleSheets helping/solving this?).

If a workaround is like appending <style> from an import to main document,
the cost may not go away, but batching them can (theoretically) reduce the
cost. But handling cascading order can be as not simple as just concatenating
these sheets.

Comment 21 by, Mar 3 2017

Parsing an import with N style elements should just cause a single update (O(N)) of active stylesheets in the import. Before my activeStyleSheets changes, parts of the active stylesheet update would happen in an O(N^2) fashion, but I don't see how style elements in imports would be different from style elements in the main document?

Comment 22 by, Mar 6 2017

Sorry I wasn't clear, what is the case when a document has N imports,
each of which has one <style> element (as opposed to 1 import having N

Comment 23 by, Mar 6 2017

That depends more on the loading behavior of those N imports than active stylesheet application. If the imports are scripts/rendering blocking, the active stylesheet update is going to be pretty much the same when the import(s) finishes loading.

Comment 24 by, Mar 8 2017

So if the top-level import which is rendering blocking, has (N-1) subimports, it doesn't
expose O(N^2) behavior now, IIUC?

Comment 25 by, Mar 13 2017

It shouldn't.

Comment 26 by, Mar 22 2017

Status: Started (was: Assigned)

Comment 27 by, May 26 2017

Please don't do this! You will break our PWA at We use HTML imports heavily, including styling from the import. They're a fantastic web components primitive that provides the overall component structure of our product.

The ideal use of a HTML import (with styling!) is to define a dialog, which we also use widely. The HTML has the markup for the dialog layout, a script provides logic for the dialog, and a stylesheet handles the layout of the dialog. Perhaps one reason that imports have not seen much adoption is because Chrome is also still the only browser that supports <dialog>.

Imports allow dependencies to be preserved in a tree structure, including DOM, script and style, which makes them much more useful for web apps than JS modules which only solve the script part.

We have polyfilled imports but it's difficult to make them fast since it's hard to do things like pre-fetching resources at the end of the import, and it's pretty ugly to have to develop with literally thousands of resources dumped in to a single document rather than spread out in their respective modules. I know imports haven't taken off, but they are honestly a very well designed and excellently thought out web primitive that helps make web apps a joy to build.

Comment 28 by, May 31 2017

Thanks for the comment.  I'll prepare a doc for mitigating the existing usages,
and would like to know more precisely how it is used.

If <style> is used for styling something in an import, does the following work
for your case?

1) separate the stylesheet as an independent file and include from the master
  document via <link rel="stylesheet" href="..">
2) leave the <style> in the import, but in its <script>, do
var master = document.currentScript.ownerDocument;
var sheet = document.querySelector('style');

Comment 29 by, Jun 5 2017

Tentative spec change PR:
(removing all the style section in HTML Imports)

Comment 30 by, Jun 16 2017

Project Member
The following revision refers to this bug:

commit 7ffbc84c441d02291f786b28cffca262b42b0c90
Author: Takayoshi Kochi <>
Date: Fri Jun 16 03:43:27 2017

Add deprecation message for style application from HTML Imports.

The plan is to show start deprecation message in M61, and remove
the functionality in M65.

Intent to deprecate:

Bug:  523952 
Change-Id: Iab70bfb596072710aa1b798517d05ed102d8488f
Reviewed-by: Kent Tamura <>
Commit-Queue: Takayoshi Kochi <>
Cr-Commit-Position: refs/heads/master@{#479939}

Comment 31 by, Jun 21 2017

Blockedon: 735633

Comment 32 by, Jun 30 2017

Project Member
The following revision refers to this bug:

commit 42a1b7105e0e6c0aafc4879cf14a4ac2b4e37e7a
Author: Takayoshi Kochi <>
Date: Fri Jun 30 04:31:43 2017

Add "HTMLImportsStyleApplication" runtime flag for Blink

This is for testing the deprecation ( ) of
stylesheet application from HTML Imports.

Use with --disable-blink-features=HTMLImportsStyleApplication
flag on content_shell or chrome.

Bug:  523952 
Change-Id: Ied43ec6b62133c339f745fdc3079626bbe90864f
Commit-Queue: Takayoshi Kochi <>
Reviewed-by: Rune Lillesveen <>
Reviewed-by: Kent Tamura <>
Cr-Commit-Position: refs/heads/master@{#483627}

Comment 33 by, Jul 10 2017

Just for a historical record:
discussed the cascading order of style rules in HTML imports.

Once we finish this, there's no confusion with cascading order among imports.

Comment 34 by, Jul 28 2017

Most of chromium internal usage (e.g. material design settings) are by
<style is="custom-style"> which is a part of Polymer 1.0.
is the tracking issue for upstream Polymer to handle the case.

Comment 35 by, Sep 22 2017

Blocking: 766694

Comment 36 by, Nov 30 2017

Could deprecation warning contain a reference to a problematic stylesheet or document?

We build an application platform based heavily on HTML imports. We use it not only to load custom elements definitions but also to build entire view out of many partial sub-views. Like huge SPA with hundreds of nested client-side includes. Therefore the dependency tree is really big and deep. Also, all those modules come from different vendors (app authors). 

So, it's hard to find the problematic document.

Comment 37 by, Jan 18 2018

We would like to test the effects of deprecation mentioned under "HTML imports styling the main document" in the below link but the latest chrome canary still doesn't seem to have this change. Can you please help find a way to test?

Comment 38 by, Jan 29 2018

I tested this with the latest Canary (v66) starting with command line flag "--disable-blink-features=HTMLImportsStyleApplication", everything on our site broke as expected (-:

Comment 39 by, Feb 15 2018

Status update:
An "intent to remove" was sent to blink-dev, but there were some pushbacks:

I'll investigate more real-world usage etc. and improve how deprecation warning
is shown. Currently, even the workaround is applied, you may see the
deprecation message.

Comment 40 by, Feb 16 2018

Project Member
The following revision refers to this bug:

commit 9f2e67cbe4581931b5dd6685cb3441ab25bd106b
Author: Takayoshi Kochi <>
Date: Fri Feb 16 03:49:49 2018

Move "style in HTML imports" removal target.

M65 is already branched, and we have to put off at least
2 milestones before the removal.

Bug:  523952 

Change-Id: I1aa3950a07bbf12720e7aed8d94f3f6e3e380d2e
Commit-Queue: Takayoshi Kochi <>
Reviewed-by: Kent Tamura <>
Cr-Commit-Position: refs/heads/master@{#537183}

Comment 41 by, Mar 3 2018

Labels: Hotlist-Interop

Comment 42 by, Mar 10 2018

Blockedon: 820654

Comment 43 by, Mar 15 2018

Blockedon: 822135

Comment 44 by, Mar 16 2018


Comment 45 by, Mar 29 2018

Project Member
The following revision refers to this bug:

commit 334db5a10a90c09583f6f0f0fcb130f4d3e61db2
Author: Yoichi Osato <>
Date: Thu Mar 29 06:01:16 2018

Move HTML Import styling deprecation target.

This patch moves the target |Unknown| because
there was a pushback in removal discussion:

Until we can gather collect usage counter, postpone it.

Bug:  523952 
Change-Id: I7844b37759b32120a2d542ce8ddb75e2c2230844
Reviewed-by: Kent Tamura <>
Reviewed-by: Takayoshi Kochi <>
Commit-Queue: Yoichi Osato <>
Cr-Commit-Position: refs/heads/master@{#546740}

Comment 46 by, Apr 3 2018

Project Member
The following revision refers to this bug:

commit c913f4412749ab7a30b5e9034f6385e65d0db1ae
Author: Yoichi Osato <>
Date: Tue Apr 03 07:48:29 2018

HTMLImport: Add test case simultating polymer workaround

This patch adds a layout test that confirms unintentionally warning if
imported document adds style to the main document by appendChild
after load.
This simulates polymer's workaround for style deprecation:
(Copy <custom-style> styles to main document:

Bug:  523952 
Change-Id: I2eb696b26af06000bc07af6ea9eeb87a67179368
Reviewed-by: Takayoshi Kochi <>
Commit-Queue: Yoichi Osato <>
Cr-Commit-Position: refs/heads/master@{#547641}

Comment 47 by, Apr 3 2018

Project Member
The following revision refers to this bug:

commit c00eba8467d424436caa4e8de28a6c2155fe2be0
Author: Yoichi Osato <>
Date: Tue Apr 03 08:10:43 2018

HTMLImport: Add test case for workaround import

This patch adds a layout test that confirm no warning if
imported document adds style to the main document by appendChild.

Bug:  523952 
Change-Id: Idd5a603d3e585378fc57958969b491d866abf997
Reviewed-by: Takayoshi Kochi <>
Commit-Queue: Yoichi Osato <>
Cr-Commit-Position: refs/heads/master@{#547647}

Comment 48 by, Apr 26 2018

Project Member
The following revision refers to this bug:

commit ae2469c0f58dc1a9e20d86f67379c7d87c2397b5
Author: Yoichi Osato <>
Date: Thu Apr 26 04:07:01 2018

Opt in HTML Imports to UKM USeCounter

Bug: 766694,  523952 
Change-Id: Ic794281024e97783d9f2bde6f2ca6c7f2eefdbb8
Reviewed-by: Robert Kaplow <>
Commit-Queue: Yoichi Osato <>
Cr-Commit-Position: refs/heads/master@{#553909}

Comment 49 by, May 15 2018

Is there a reason why `<link rel="preload" as="style">` is also deprecated and triggers a warning? 

It does not introduce cascading nor style application problems. It's just pre-loading a resource as any other, which later could be used in the main document by `<link rel="stylesheet">` appended there.

So this is not "HTML Import styling the main document".

Comment 50 by, May 16 2018

Using links w/o rel="import" should not show the deprecation message.
Could you show a sample?

Comment 51 by, May 17 2018

My comment was about `rel="preload"` not `"import"`. But, please disregard it, as it occurred not to be a problem. Here is the test scenario

My bad, the warning was thrown because `link rel="styleshet"` deeper inside HTML Imports tree.

It would be nice to have a reference to the problematic `link` in the warning, (as suggested at

Comment 52 Deleted

Comment 53 by, May 28 2018

I see the following warning on chrome console

"[Deprecation] Styling master document from stylesheets defined in HTML Imports is deprecated, and is planned to be removed in M67, around May 2018. Please refer to for possible migration paths."

Can someone please confirm if the deprecation is happening starting Chrome version 67? or is it being postponed? because I don't see the deprecation in action in Chrome Canary, which is currently in version 69.


Comment 54 by, May 29 2018

We changed our plan, and the message was revised to not having the specific
milestone #c45, which is in M67.  So no, the deprecation will not happen on M67.
Sorry for the confusing deprecation message.

Comment 55 by, Jun 19 2018

Update: as of today HTML Imports is ~2.1% and Imports with style is ~2.0%,
which means only removing styling would break most of the usages
(although the breakage is largely mitigated by Polymer's custom-style
workaround, if the site uses Polymer).

Yoichi, could you work on removing the deprecation message for styling,
close  bug 822135 , and merge this into main HTML Imports deprecation bug
(issue 766694)?

Comment 56 by, Jun 19 2018

Blockedon: -820654

Comment 57 by, Jun 19 2018

Mergedinto: 766694
Status: Duplicate (was: Started)

Comment 58 by, Jun 25 2018

Regarding and

I have attempted to locate 'offending' sheets by debugging Chromium and setting a breakpoint in HTMLImportChild::DidFinishLoading() where the deprecation is checked and recorded, but this seems to only happen on first-level imports, but not imports-of-imports. I've tried for a few hours to locate a better location in the code, so I could log something along the lines of "this stylesheet from this file, which was imported, was applied to the master document", but have failed so far.

Like the previous posters, I don't know which first-party or third-party code is causing the warning. Could somebody more familiar with the codebase recommend a debug strategy to identify all imported stylesheets which are applied in this manner?

Second, regarding

Where is now the best place to track the timeline of this deprecation?

Comment 59 by, Jun 26 2018
might help you to investigate HTML Import styling.

Deprecating style from HTML Import is now merged into HTML Import deprecation itself. We're deprecation HTML Import entirely at once.

Sign in to add a comment