Intent to Deprecate: style application from stylesheets in HTML imports

[Takayoshi Kochi]

Primary eng email

ko...@chromium.org

Summary

Currently stylesheets in HTML Imports (via either inline <style> or external <link rel="stylesheet">)

is applied to their master document. Deprecate and eventually remove this behavior.

Eventually we can remove the chapter 9 of HTML imports spec.

Current plan is to start showing deprecation message in 61 and remove in 65 (Mar. 2018).

Note: stylesheets defined within <template> element, which is often used for stamping

Shadow DOM contents, are not affected, as they are never applied to anything until they are

stamped.

Spec

The whole section of style in HTML Imports spec will be removed:

http://w3c.github.io/webcomponents/spec/imports/#style-imports

> The contents of the style elements and the external resources of the link elements in import

> must be considered as input sources of the style processing model [CSS2] of the master

> document.

A reference PR for removing this section:

https://github.com/w3c/webcomponents/pull/642

Motivation

Applying style from stylesheets in HTML (via <script> or <link rel="stylesheet">) has made

Blink's style engine complex, and been confusing to web developers as they are unexpectedly

applied to the master document, while none of the DOM tree inside HTML Imports is rendered.

This was originally introduced for giving "default style" for something in modular way, such

as theming using HTML imports. But as /deep/ and ::shadow combinators of Shadow DOM v0

are deprecated and they are not even available in Shadow DOM v1, the value of this feature

has become smaller.

Removing this will reduce the complexity which historically caused difficulty in making

changes in style system (e.g. see crbug.com/567021 or crbug.com/717506).

We will eventually be deprecating HTML imports as a whole once a concrete successor

gets consensus; Deprecating the style application part is a stepping stone for it.

Interoperability and Compatibility Risk

HTML Imports has been available only for Blink, and the stylesheet usage in imports

is 0.044% (source) within the whole HTML Imports usage (0.411%, source), so

currently 10+% of HTML import contains one or more stylesheets, although we do not

have concrete data about how much of them are actually styling the master document.

As no other browsers than Chrome and Opera shipped HTML Imports,

compatibility risk is only within Blink implementation and its users.

Alternative implementation suggestion for web developers

Working around the issue is as easy as hoisting the stylesheet declaration to the

master document manually or by script. For example, in an import, it is as simple

as putting the following script in an import:

<script>

var importDoc = document.currentScript.ownerDocument;

var style = importDoc.querySelector('style'); //  assuming only one <style>

document.head.appendChild(style);

</script>

See https://github.com/TakayoshiKochi/deprecate-style-in-html-imports for more

concrete examples.

For Polymer (both 1.x and 2.x) users, custom-style usage is affected by this.

The framework will be updated to handle this accordingly.

Follow https://github.com/Polymer/polymer/issues/4679 for the details.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/940

OWP launch tracking bug

http://crbug.com/523952

and file a new bug for OWP launch tracking for removal.

Entry on the feature dashboard

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

Requesting approval to remove too?

No at this point. The deprecation message, starting in 61, will include

a target removal date of 65 (March 2018).

At that time I plan to send a separate Intent to Remove where we can

reevaluate the effect of the deprecation message on driving down usage.

--

Takayoshi Kochi

[PhistucK]

Is this the first step of deprecating and removing HTML imports entirely?

If so, you better make that clear somewhere (not in a console warning, obviously, because the usage is too high, but in a Google Developers Updates article with an alternative way of achieving the HTML import functionality, for example).

What a confusing alternative implementation (document.currentScript.ownerDocument). :( I thought document and ownerDocument are supposed to be the same in this kind of statement.

☆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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADP2%3DhoP4XVmWRxTywE8aSXxVOZ_Y48Mz99J8SZK6RYhmm233A%40mail.gmail.com.

[Takayoshi Kochi]

Hi,

On Fri, Jun 9, 2017 at 10:35 PM, PhistucK <phis...@gmail.com> wrote:

Is this the first step of deprecating and removing HTML imports entirely?

Yes - but the whole plan is still unclear at this moment.

At this moment, Blink is the only engine that implements HTML imports, and no other browsers

are likely to implement it.  So HTML imports will get into a dead-end some time in the future.

If so, you better make that clear somewhere (not in a console warning, obviously, because the usage is too high, but in a Google Developers Updates article with an alternative way of achieving the HTML import functionality, for example).

Yeah, it makes sense to add some notes in tutorial-like contents for HTML imports like one in html5rocks.

 

What a confusing alternative implementation (document.currentScript.ownerDocument). :( I thought document and ownerDocument are supposed to be the same in this kind of statement.

document.currentScript.ownerDocument is a commonly used idiom to get the current import document where

the current script is running.  So anyone who's familiar with using HTML imports should be able to interpret

the statement.

See the old tutorial, if interested.

https://www.html5rocks.com/en/tutorials/webcomponents/imports/

--

Takayoshi Kochi

[Takayoshi Kochi]

Thanks for sharing the great and detailed writeup, Ashley.

My view of HTML Imports is not that different from what is described in the article,

but in reality, no other browser vendors are going to implement HTML Imports as is,

so we must face it.

The benefit of removing the style application may be difficult to understand for users of HTML imports -

the reduction of implementation complexity frees up some time of Blink developers and thus

they can spend more time on new features or optimizations, at the cost of breaking the existing

users.  We are deliberately balancing the things.

One counter argument to the article would be to this sentence (at the last paragraph in

"What went wrong for HTML imports?" section:

> the Chrome team (and some other browser makers) appear to be taking the view that it's a failed feature.

The feature 

The failure is not the feature itself, as it worked great for some use cases like what you described.

But for the web platform as a whole, it failed to get implemented by other browsers.

The reasons for each browser may vary, but mainly for duplicate mechanism of loading dependencies

with ES6 modules, or complexity that HTML imports introduce (in terms of implementation) didn't justify

the benefit.

Now that ES6 modules are almost ready for most browsers, it is time to restart the successor of

HTML imports.

On Sun, Jun 11, 2017 at 11:04 PM, Ashley Gullen <ash...@scirra.com> wrote:

I am convinced this is a mistake. We built a complete game development IDE in a browser involving 250,000 lines of hand-written JS code, and HTML imports are by far the most important web component for this kind of development. There are a wide range of reasons for this, so I just wrote a blog post trying to comprehensively cover it all:

https://www.scirra.com/blog/ashley/34/html-imports-are-the-best-web-component

In particular I must say that even if you want to remove HTML imports, the approach of removing styling first is a particularly inept way to go about it, for several reasons:

1. Styling from imports is a useful feature, as described in my blog post.

2. AFAIK Chrome's own policy for deprecation suggests features should have around 0.03% usage before being deprecated; usage is significantly (50%) higher than that according to your own data.

3. You are trying to roll back this feature before providing a compelling alternative, or even a proposal for an alternative.

4. You will break apps already using HTML imports - including our own. We depend on styling from HTML imports for our PWA to work correctly. We have polyfilled the feature, but because you are leaving HTML imports supported but breaking them, our polyfill will not kick in. It would be better to entirely remove them in one go than make a major breaking change, but you shouldn't do that before you even have a clear idea what comes next. There does not appear to be any convenient way to feature-detect this change. So this is pretty much the worst way you can go about deprecating a feature.

We are aware of the usage is higher than usual threshold - unless the usage drops down to some level,

we cannot remove the feature - but we try to drive the usage down.

Let me work out for feature detection part.  But hoisting the stylesheet declaration to the master document

should always work with or without this change.

 

I implore you to entirely reconsider your approach.

Ashley Gullen

Scirra Ltd

--

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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADP2%3DhoP4XVmWRxTywE8aSXxVOZ_Y48Mz99J8SZK6RYhmm233A%40mail.gmail.com.

--

Takayoshi Kochi

[PhistucK]

On Mon, Jun 12, 2017 at 9:59 AM, Takayoshi Kochi <ko...@chromium.org> wrote:

3. You are trying to roll back this feature before providing a compelling alternative, or even a proposal for an alternative.

​An alternative was provided, though.​ And just putting it in every file covers all of the cases, I believe.

One kind of feature detection -

data:text/html,<link rel=import href="data:text/html,<style>body{--style-imported-detection:1;}</style>" onload="console.log('<style> moved?', getComputedStyle(document.body).getPropertyValue('--style-imported-detection') === '1')"/>

☆PhistucK

[Ashley Gullen]

We recently tried to switch our PWA to a polyfill but we ran in to a Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=733682

Please don't change HTML imports until we can figure out what's going on there - otherwise we will have no options left!

[Takayoshi Kochi]

On Fri, Jun 16, 2017 at 1:14 AM, Ashley Gullen <ash...@scirra.com> wrote:

We recently tried to switch our PWA to a polyfill but we ran in to a Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=733682

Please don't change HTML imports until we can figure out what's going on there - otherwise we will have no options left!

Thanks for filing a bug.  tkent@ already looked into it and it is not totally an HTML imports issue.

As indicated in the original post, this deprecation is only about *styling to master document* part of HTML Imports,

and is scheduled to be removed by March next year.  HTML Imports will stay longer than that, and

we hope we can provide some alternative by then.

--

Takayoshi Kochi

[Ashley Gullen]

OK, March next year should be enough time. We found a workaround so hopefully we can ship our PWA using the polyfill soon.

[lzsof...@gmail.com]

Hi Mr. Kochi, first of all thanks for the explanation, they're very reasonable to be honest. However I still have some thoughts:

1. Other browsers implementation

Just like you said, Firefox and Safari haven't implemented HTML Import because there's a duplicating mechanism between Import and ES6 Modules, so they want to wait until ES6 modules is done. However "taking a long time and get blocked by some other stuff for now" doesn't neccessarily mean "we have to remove the feature" right? Is there any chance that after ES6 Modules being shipped in all the major browsers, they'll start looking at HTML Import again? I think it's possible right?

2. The simplicity of component packaging

It's true that it's not the end of the world if we stop rendering style from HTML Import - yes we can simply move the <link> into the main doc. However, to me one of the biggest purpose of HTML Import is that it "pack" resources and references, encapsolate all the details of a component and provides an abstract and simple entry for 3rd party user. A developer doesn't need to know how many css/js files a component has, all s/he needs to do to be able to use a component is simply <link> the component's "package page", and the js/css referred on that page will run and render things by themselves. This is probably the first time in Web history that we have an fundamental web platform solution for component isolation/encapsulation, and the solution has a beautiful simplicity. But now stop rendering style in HTML Import breaks that simplicity, because we have to expose the details that should be hidden within it's own implementation to the public.

I totally understand that the complexity of rendering style in HTML Import is intolerable to the blink team, trust me I do. It's just HTML Import w/ rendering style and running scripts is the best and only 1st party component encapsulation solution we have. This is not about whether we can do it in different ways - we can always survive alternative work-arounds - instead, this is about how we can do it in the best/beautiful way. Front-End architecture shouldn't be only about functionality, it is also about simplicity and elegent, so it's really sad to see the change happens.

use-case some-element.html:

<template>
    <img>
    <div></div>
    <!-- some other element content -->
</template>
<script src="some-element.js"></script>
<script src="shim.js"></script>
<link href="some-element.css">
<link href="global.css">
<link href="mobile.css">

use-case index.html

<html>

<head>
    <link rel="import" href="some-element.html>
</head>

<body>
    <some-element></some-element>
</body>

</html>

3. Successor that can import a document

As a developer I really feel like we need a way to just include another piece of HTML into the main document, and it needs to work well with Custom-Elements life cycle. We can use js async loading, we can compose the HTML into a string const in the js, but none of those solutions is "natural". Including/referring to another HTML to an existing document and providing a programmatic way to access it should be something semantically implemented by the HTML spec itself, I think that's exactly why "HTML Import" was defined years ago right? So if "HTML Import" spec is going to be deprecated in the future, can we have something that allow us to do the samething?

--

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/CADP2%3DhoP4XVmWRxTywE8aSXxVOZ_Y48Mz99J8SZK6RYhmm233A%40mail.gmail.com.

--

Takayoshi Kochi

[kriste...@aranzgeo.com]

Hi, I'm trying to follow up on the prospect of activating the HTML Imports polyfill, as I'd like to know there is a contingency in case our Polymer upgrade (which includes a fix) is not complete by the Mar 6 release date of Chrome 65. I have the identical concern as point #4 in the quoted email message of Ashley Gullen's message of 15/06/2017:

 

We have polyfilled the feature, but because you are leaving HTML imports supported but breaking them, our polyfill will not kick in. It would be better to entirely remove them in one go than make a major breaking change, but you shouldn't do that before you even have a clear idea what comes next. There does not appear to be any convenient way to feature-detect this change.

 

I'm interested to follow up on your reply:

Let me work out for feature detection part.  But hoisting the stylesheet declaration to the master document

should always work with or without this change.

My reason for preferring to be able to activate the HTML Imports polyfill is because the offending documents (which style the master document) are Polymer-authored elements (flex layout modules, theme-level global styles and fonts). This means we don't exactly control those files in order to edit the code and hoist them into the owner document.  As mentioned, we are working on a framework version upgrade but I'd like to have a contingency for the Mar. 6 release date so that our Polymer 1.x app does not experience a large and immediate negative impact in its layout and styling.

I'd be interested to know if we can force the polyfill to activate in some way, but I'm not sure it supports this due to the feature-detection method of activation.

Thanks in advance for your advice,

--

Kristen Cooke

--

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/CADP2%3DhoP4XVmWRxTywE8aSXxVOZ_Y48Mz99J8SZK6RYhmm233A%40mail.gmail.com.

--

Takayoshi Kochi