On what specific grounds were HTML Imports rejected, deprecated and removed?

5,299

Solution 1

After reading several articles on this, the general consensus is that HTML Imports were redundant, since you need JavaScript to bring them alive anyways (they don't just automatically add themselves into the document - the term "include" is kind of misleading if you compare it to what that usually means in other languages).

From the article that @Bronwyn linked:

As previously stated, Mozilla is not currently intending to implementing HTML Imports. This is in part because we’d like to see how ES6 modules pan out before shipping another way of importing external assets, and partly because we don’t feel they enable much that isn’t already possible.

We’ve been working with Web Components in Firefox OS for over a year and have found using existing module syntax (AMD or Common JS) to resolve a dependency tree, registering elements, loaded using a normal tag seems to be enough to get stuff done.

The state of Web Components - Mozilla Hacks

So in short, they didn't really enable you to do anything that you can't do with existing JS modules.

Solution 2

Nota Bene:

HTML Imports are deprecated as a standalone technology, but it turns out the underlying concept has not been ditched.


It appears (after much searching) that HTML Imports (deprecated) may yet be succeeded by HTML Modules.

Here are two very readable documents from the W3C introducing HTML Modules:

  1. HTML Modules Proposal - W3C
  2. HTML Modules Explainer - W3C

The first document details the specific problems thrown up by HTML Imports and reveals how HTML Modules will solve these problems.

Specific problems with HTML Imports include:

  • Parsing Obstruction: Any <script> referenced after a <link rel="import"> declaration must wait for the imported HTML to fully download, obstructing the parsing and delaying the download of the rest of the main document

  • Global Namespace Conflicts: Any JS variable declared within the HTML Import will clash with an identically-named JS variable declared in the main document

The second document discusses in more detail how HTML Modules will work in practice.


More info on HTML Modules proposals:


In Conclusion:

It wasn't so much that the concept behind HTML Imports was no good.

It was simply that the implementation architecture - initially developed in 2011, a long time before ES6 Modules were finalised - has proven far from optimal, especially given the evolution, more recently, of more sophisticated technologies.

Share:
5,299

Related videos on Youtube

Rounin - Standing with Ukraine
Author by

Rounin - Standing with Ukraine

Hi, I'm a front-end digital developer. I design and develop web-apps and websites. I have 24 years experience of working with markup, styling, scripting, data, vector graphics, animations and developing apps using client-side and server-side technologies: Modern Javascript / ES2015+ (Front-End Development) PHP7 (Server Side Development) .htaccess (Server Configuration) CSS3 HTML5 SVG JSON Regular Expressions WebComponents IndexedDB Progressive Web App (Webmanifest &amp; Service Worker) Web Storage (localStorage &amp; sessionStorage) Javascript (ES5 / ES3) a dash of jQuery In mid-2022, I'm now learning Deno, TypeScript and Vue 3. Markup and Development HTML5: I am familiar with working with a large number of HTML5 APIs, not least: Web Storage (localStorage &amp; sessionStorage) IndexedDB Fetch (next gen xmlHttpRequest) Touch Events GeoLocation Web Workers (for multi-threaded development) Media API (Video &amp; Audio) Page Visibility File System Styling CSS3: I am familiar with working with a large number of CSS3 Modules, not least: CSS Custom Properties CSS Grid CSS Flexbox CSS Typed Object Model CSS Animations &amp; Transitions CSS Transforms CSS Filters CSS Masking and Clipping CSS Pseudo-Classes &amp; Pseudo-Elements CSS Counters CSS Fonts CSS Columns Media Queries I have 18 years experience writing CSS Stylesheets and presenting cross-device compatible web pages using Responsive Web Design, Adaptive Web Design, RESS etc. Scripting and more (Server Side and Client Side) Javascript: I have 8 years experience in writing ES5 and 4 years experience in writing ES2015+. JSON: I can quickly and competently write and edit valid JSON and manipulate in both Javascript and PHP. In 2019, I wrote a single-page Javascript app presenting a user-interface for quickly creating valid JSON strings of any length and complexity. PHP5 and .htaccess: I have 10 years experience in server-side scripting using PHP and server configuration using .htaccess (mod_rewrite, setting HTTP headers etc.) . Ajax and Fetch API: I am adept in using Ajax to asynchronously access server side scripts from the client side. I am increasing my competency in using the Fetch API (the ES2015 next generation alternative to Ajax / xmlHttpRequest). Regular Expressions: I frequently use Regex in javascript, PHP &amp; .htaccess. Website Maintenance: I am familiar with robots.txt and XML Sitemaps. In 2014 I wrote a PHP app which auto-generates XML Sitemaps. jQuery: When I need to do so, I can quickly and competently translate backwards and forwards between jQuery and Javascript.

Updated on September 18, 2022

Comments

  • Rounin - Standing with Ukraine
    Rounin - Standing with Ukraine over 1 year

    TLDR: On what specific grounds did browser-makers reject, deprecate and remove HTML Imports?


    This is me (four hours ago):

    Apparently I have been living under a rock, because only today I have discovered a web-shaking innovation which sounds tremendously exciting:

    HTML Imports - #Include for the Web (Nov 2013)

    Crikey. November 2013? That's more than half a decade ago!

    HTML IMPORTS?! Really?! Really really?!!

    This is something I've wanted to see since the early 2000s!

    Wow, look at this: <link rel="import" href="/document-to-import.html">

    This looks... amazing. Let's see if there are any other articles about this unheard-of innovation...

    :: Pulls out no fewer than 39 articles from search engine discussing HTML Imports. ::

    Wow... there's so much to read. (39 pages! No kidding!!) Everyone seems to know all about this stuff. Half the world appears to have written about what an exciting new innovation this is. (Innovation from 2013, anyway...)


    :: Pauses for thought after reading several pages in breathless wonder ::

    Although... how come I've never heard of HTML Imports ??

    Doesn't Firefox... ? Let me just...

    :: Runs to check Can I Use HTML Imports ::

    Ahhhhhh. I see. Never implemented in Firefox. (Or in Safari).


    And what's this I'm now reading everywhere about HTML Imports being deprecated?

    HTML Imports deprecated from Chrome 73 onwards and due to be removed in Chrome 80 (Jan 2020)? Whaaaat?! Noooo!! No - I've only just discovered this!!

    And the feature is right here on Can I Use HTML Imports. On Chrome and Opera. And - look! - it's just started on Edge, too!!

    See?! Not deprecated! Even Edge will now be supporting HTML Imports! It surely can't be deprecated? More and more browsers are supporting it!


    Oh. Hang on. Doesn't Opera use WebKit instead of Presto now?

    :: Checks ::

    Ah. Right. Opera uses the Blink Browser Engine. Same as Chrome. So Opera supports HTML Imports only because Blink does.

    Hmm.

    What's that?

    :: Checks again ::

    Oh. Edge 79 is based on Chromium 79. So Edge also uses the Blink Browser Engine now. Same as Chrome. So Edge supports HTML Imports only because Blink does.

    So, basically no browser engine supports HTML Imports. Except Blink.

    And even Blink deprecated HTML Imports in Chromium 73.

    • WebKit doesn't support.
    • Presto never supported.
    • EdgeHTML never supported.
    • Gecko doesn't support.

    And now Blink has removed HTML Imports.


    Well, that was a rollercoaster.

    6 years' worth of fun in 2 hours.

    After reading all that, my impression is that Mozilla, particularly, was never keen on:

    <link rel="import" href="/document-to-import.html">

    I can't see any response from Safari, but I don't see any explicit enthusiasm from that corner, either.

    Yet, after scouring the web, I still can't find the reasons articulated anywhere for opposing, rejecting, deprecating and removing HTML Imports.

    Question:

    On what specific grounds did browser-makers reject, deprecate and remove HTML Imports?

    • Bronwyn V
      Bronwyn V over 4 years
      It's my understanding that it was only ever experimental, was then deprecated and is now obsolete.. mainly due to vendors. Interesting read on it here: hacks.mozilla.org/2015/06/the-state-of-web-components
    • Rounin - Standing with Ukraine
      Rounin - Standing with Ukraine over 4 years
      Thank you, @BronwynV - that was an informative reference. I've done some more hunting around and I've seen that as long ago as 2016-17, HTML Modules were proposed as a potential successor to HTML Imports here: Webcomponents Issues and here: HTML-Imports-and-ES-Modules.
    • Anssssss
      Anssssss over 4 years
      Just adding a keyword for future internet searches - transclusion.
    • user2752467
      user2752467 over 4 years
      This question is really confusing to read. It doesn't ever explain what exactly HTML Imports are or why they're useful. The links and comments provide some more context, but generally an SE question should include all relevant information in the question body.
    • Rounin - Standing with Ukraine
      Rounin - Standing with Ukraine over 4 years
      I agree that an SE question should include all relevant information in the question body. The reason I did not explain the term HTML Imports is because I thought the term self-explanatory: a technology which enables web documents to import HTML. If that's not immediately obvious, I am happy to add an explanatory note to the question above.