Html imports is deprecated

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

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:

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 referenced after a 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.

Related videos on Youtube

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 & Service Worker) Web Storage (localStorage & 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 & sessionStorage) IndexedDB Fetch (next gen xmlHttpRequest) Touch Events GeoLocation Web Workers (for multi-threaded development) Media API (Video & 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 & Transitions CSS Transforms CSS Filters CSS Masking and Clipping CSS Pseudo-Classes & 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 & .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

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

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.

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

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

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.

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.

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.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

HTML Imports is deprecated and will be removed in M73 #422

HTML Imports is deprecated and will be removed in M73 #422

Comments

[Deprecation] HTML Imports is deprecated and will be removed in M73, around March 2019. Please use ES modules instead. See https://www.chromestatus.com/features/5144752345317376 for more details.

The text was updated successfully, but these errors were encountered:

Does anyone have a solution to this huge issue? Every single Electron example that utilizes more than a single page is entirely dependent on this functionality. Are we stuck having to learn how to incorporate external UI frameworks into Electron instead? If that’s the case, it would be nice if there were at least some examples for it from the Electron devs themselves.

The above is somewhat inaccurate per the link

HTML Imports are deprecated at M70, and will be removed in M80.

We’re on M76 in master at present, so consumer apps won’t be affected until perhaps ~april 2020 when Electron will likely. with M80.

@codebytere em. actually for me the text by the link you provided says «HTML Imports are deprecated at M70, and will be removed in M75, around Jun 2019. For more info: https://groups.google.com/a/chromium.org/d/msg/blink-dev/h-JwMiPUnuU/sl79aLoLBQAJ». 🤔 From their group summary:

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

But it also seems they’re delaying the removal so there’s a mismatch. But it will break soon anyway.

I just dropped this code into the bottom of my body. I still get the warning, but it does the job..

Array.from(document.getElementsByTagName('link')).forEach(item => < if(item.rel === 'import')< fetch(item.href). then(response =>< if(!response.ok) throw Error(response.statusText); return response.text() >). then(text => < const div = document.createElement('replaced') item.parentNode.replaceChild(div, item); div.innerHTML = text >). catch(error => console.log(error) ); > >); 

Источник

The downfall of HTML Imports is upon us (to me)

I just read this in my console today after my Chrome browser just updated to M61. And it’s the saddest news all I’ve read all day. The next step in the downfall of HTML Imports. And I can’t believe it’s happening because it is the perfect delivery method for CSS/JS libraries, frameworks, and of course, Custom Elements. I first noticed the beginning of the end when I saw this:

HTML Modules #645

Now that JavaScript modules are on the verge of widespread browser support, we should think about an HTML module system that plays well with it. HTML Imports doesn’t have a mechanism for exporting symbols, nor can they be imported by JavaScript, however its loading behavior is quite compatible with JavaScript modules. @dglazkov sketched out a proposal for HTML modules here: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md The main points are that, using the JavaScript modules plumbing, you can import HTML. Either in HTML:

script type pl-s">module" url pl-s">foo.html">

import * as foo from "foo.html";

But within the scope of that sketch there are still several questions about the specifics of exporting symbols from HTML and importing to JavaScript.

It’s a proposal to make an amendment to HTML Imports to add the functionality through Javascript instead of through . While I’m not totally against the idea of being able to import elements and such inside JS, I hate the idea of it replacing the HTML way. I love the idea of Custom Elements and it’s honestly my favorite feature I’ve seen added since I started web dev. I have a repository dedicated to custom elements where I make a bunch. The most notable section of which is a folder with a bunch of Fluent Design inspired elements. And the whole project can be used in one line.

 rel="import" href="https://rawgit.com/Nektro/custom-elements/master/fl/fl.html"> 

That one file sets some basic CSS, and imports all the other elements. However, Chrome is the only browser that has native support. Everyone else has to use a bodged polyfill because every other browser isn’t even interested in implementing it for some reason. In the end, I hope this HTML based feature stays supported in HTML.

Источник