AFAIK there's consensus that the HTML imports proposal has failed to gain traction on the web and is likely to be replaced with ES6 modules. At some point I assume we should be looking into the feasibility of deprecating and removing our support for HTML imports.
To be clear on our position on deprecate and remove HTML imports,
until we have any alternative for HTML Imports, we will keep the
implementation, though considering the current situation that any
other browser does not adopt HTML Imports we would not recommend
start depending on HTML Imports.
One exception is issue 523952 , which is currently on track for
deprecating and removing style application from HTML Imports to
the master document. It is expected to happen in Mar. 2018.
Anything I can do to help with this? Removal of imports will significantly simplify the work for cleaning up the layout/paint logic (issue #521692).
I'm happy to scan the HTTP Archive for all of the sites using imports to make sure they are using the feature detection and polyfill fallback for starters.
It looks like there are 276 desktop sites in the latest HTTP Archive crawl of the top 500k domains that tripped the HTMLImports feature usage counter.
In bigquery:
#standardSQL
SELECT
url
FROM
`httparchive.pages.2018_04_15_desktop`
WHERE
JSON_EXTRACT(payload, '$._blinkFeatureFirstUsed.Features.HTMLImports') IS NOT NULL
I have them in a sheet here and will try them out with the feature disabled and add notes if they are polymer-based or if they have a polyfill fallback.
https://docs.google.com/spreadsheets/d/1TgAFyM_HzSTisEE_sR6yhc5oEDnEdWJKtso-qr66Ma4/edit?usp=sharing
One thing that jumped out while looking through sites. One of the sites that triggered the feature looks like it triggered it through Chrome's internal use of imports for UI. It looks like there are parts of Chrome's UI that use imports directly or use polymer 1 but without the polyfill since it knows it is running in Chrome.
i.e. https://cs.chromium.org/chromium/src/ui/file_manager/gallery/gallery.html?q=rel%3D%22import%22&sq=package:chromium&dr=C
Searching for rel="import" in cs.chromium.org turns up 7182 references (granted, a bunch will be tests).
We will either need to migrate the UI components to polymer 2 or at least include the webcomponent polyfill.
Thank you for investigating!
How much is HTMLImports blocking rendering work? Is that urgent?
We originally planed to deprecate HTMLImports but there were push-back
:https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/VZraFwqnp9Y/discussion
Today, HTMLImports is used 2.5% in wild:
https://www.chromestatus.com/metrics/feature/timeline/popularity/455
That's too high to deprecate it immediately.
Then I introduced the UKM to know how frequently HTML Imports is used on each web site
so that we can reach the sites from the biggest and ask them to stop using HTML Imports.
However the UKM is not on stable and I'm not doing any promotion work.
Polymer team is also working on Polyfill which emulates HTML Imports if the feature is disabled chrome.
I have 2 plans in the meanwhile:
A. Reach the site to stop using HTML Imports, if the usage counter gets enough low, deprecate HTML Imports.
This takes long time.
B. If we confirm the sites using HTML Imports work well on disabled chrome, deprecate it aggressively.
I'm bit suspicious that we can confirm sites working. For broken sites after deprecation, offering Origin Trials
to reenable HTMLImports works?:
https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md
There isn't anything particularly urgent about the rendering work, just removing a bunch of special logic that can go away. I can work on the CSS side of things which is also a blocker as long as it looks like imports will eventually go away (otherwise I actually need to do some work to imports but I was hoping to avoid that).
On the usage front, there are a few things going on and I don't think the UMA or UKM will be useful until they are handled.
1 - The vast majority of sites that are using web components use feature detection and if the browser doesn't support web components they load a polyfill. Since web components are supported they are using them triggering the feature usage even though the sites also work fine without them.
The polyfill is here: https://www.webcomponents.org/polyfills
If you can break the feature detection but keep the underlying support (say, by removing "import" from the link element's IDL) then the use counter should only catch sites that use imports regardless of browser support (by UA sniffing or otherwise assuming they are in Chrome).
2 - YouTube. The site itself will drive a ton of usage but it also triggers usage in other sites when the player is embedded. In UKM that may end up showing up as a lot of sites but only because of embedded videos.
I'd recommend waiting for YouTube to migrate off of imports (or work with the team on options) and dealing with any Chrome UI that uses imports. It looked like the trace viewer (at least the catapult version) is a heavy user but it also looks like different parts of Chrome's UI also depend on imports.
Once YouTube and the Chrome UI are off of imports and the feature detection is broken (but functionality is left in place) I would wager that the usage would drop very close to zero.
@phistuck at Google, YouTube is our property and relatively easier to
negotiate them out of using HTML imports than non-Google properties.
(although of course, YouTube has its own difficulty to change)
#19 - yep, I know. I meant that since they probably significantly skew the results, you should probably start with them (and as soon as possible), otherwise the use counter will never really go down.
Re comment#18
For feature detection, we assume the recommended detection in the linked
document (https://www.webcomponents.org/polyfills) doesn't count in our
UMA/UKM, which just checks the existence of the property names in Object
prototypes. we only count actual invocation of those methods or getters.
So specifically for HTML imports, our counters should count the sites
that use actual imports, and not sites that feature-detects it.
Sorry, I didn't mean that the detection was triggering the UMA but that they were using imports because the detection worked. That said, thinking about it more, the way the polyfill works may still end up using imports so breaking the feature detection won't make them stop using the feature.
The goal is to filter out the sites that are using imports but that don't depend on it since they are including the polyfill fallback and not count them towards the total.
I'll poke around a bit and see if there is a way to detect those cases from within Chrome. I'll also see about automating a scan of the 276 sites in the HTTP Archive using imports to see how many are using the polyfill.
Ah, okay. Then the hypothesis is that if we could exclude sites that use
feature detection + polyfill can survive even after HTML Imports feature
is completely removed, and find out those sites that do not feature detect
and directly uses HTML Imports native.
BTW re comment#18 again
do you really see embedded YouTube player is using HTML Imports?
For example, at
https://www.theverge.com/2018/5/21/17369956/oneplus-6-review-phone-android-phone-price-specs
(if seen from desktop chrome, YouTube player is on top of the page)
it doesn't seem to trigger HTML Imports UMA feature (#455).
Although there may be various versions, and even YouTube may browser sniff
or serve different versions to different users via A/B tests, I can't be
sure just for a few examples.
I'm not 100% sure about the YouTube embeds. There were 2 sites I was looking at that triggered the feature usage at the time of the HTTP Archive scan that don't show any current signs of imports and both have a youtube video embedded in an iFrame:
http://www.cmtrading.com/http://www.ssfusd.org/
I'll see if I can dig up the actual HTTP Archive tests and check out the HTML from the time of the tests to see if it was something else.
The cmtrading one was a false alarm and came from a ticker widget which includes a polyfill.
I haven't been able to track down where http://www.ssfusd.org/ pulls it in yet. There is a good chance it is coming in through embedly widgets which then embed youtube but I haven't found the actual references yet. The only "import" references I have found in the included code are in the YouTube base js but I can't tell if any of those bits are executing:
https://www.youtube.com/yts/jsbin/player-vflXIriOh/en_US/base.js
Comment 1 by tkent@chromium.org
, Sep 22 2017Owner: kochi@chromium.org
Status: Assigned (was: Untriaged)