Polymer: Http2 Server Push for HTML Imports not working in Firefox and perhaps outside Blink?

[mmm111mmm]

I'm filing this here since Polymer seems to be the main user of HTML Imports.

If we look at the https://w3c.github.io/preload/#attributes, the 'document' type, i.e. Link: </bower_components/polymer/polymer.html>; rel=preload; as=document says this should preload an iframe.

However, in this demo site we're prefetching polymer.html. This is obviously not an iframe, but an HTML Import. And so it shouldn't work, from my understanding, as per the spec, at least.

In Blink, regardless of the above, the demo preloads polymer.html so it arrives before the DOMContentLoaded event. But in Firefox (48.0a2 (2016-05-11) in my case), polymer.html is loaded after DOMContentLoaded.

If we look at the below image of Firefox's network internals you can see polymer.html is loaded after the blue line, the DOMContentLoaded event, thereby indicating the preloading of HTML imports is not working.

Would you agree that Firefox is not preloading HTML Imports?

[ebidel]

There are spec-level discussions happening about imports and as="document". Even Blink is not handling it properly: https://bugs.chromium.org/p/chromium/issues/detail?id=593267

I'd file this against FF's issue tracker. Since they don't implement imports, I highly suspect it's just a bug in their engine. Having tested h2 push in other browsers, there are definitely still outstanding bugs.

[mmm111mmm]

I've filed a bug asking Firefox to have something similar to about://net-internals so we can check https://bugzilla.mozilla.org/show_bug.cgi?id=1272740

And one asking if they are indeed being server pushed https://bugzilla.mozilla.org/show_bug.cgi?id=1272742

Have Firefox moved on their support of HTML Imports, do you know?

[ebidel]

They have no plans to implement Imports atm. They're waiting to see how ES6
modules shake out.

On Fri, May 13, 2016 at 11:49 AM NewFiveFour [email protected]
wrote:

I've filed a bug asking Firefox to have something similar to
about://net-internals so we can check
https://bugzilla.mozilla.org/show_bug.cgi?id=1272740

And one asking if they are indeed being server pushed
https://bugzilla.mozilla.org/show_bug.cgi?id=1272742

Have Firefox moved on their support of HTML Imports, do you know?

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
https://github.com/Polymer/polymer/issues/3652#issuecomment-219128737

[mmm111mmm]

Even if ES6 modules shake out well, they still won't help us, since they only import Javascript.

They won't solve the problem of "I want to download a block of HTML (which I'll then turn into a component to be used in the main document)".

And Mozilla probably don't see this as a problem, since they see creating a web component to be like this, i.e. you just need a JS file with createElement calls.

Do you have any ideas of how to convince Mozilla that importing a block of HTML in a separate file--and then being able to grab its content for use in a module--would be a great thing for compartmentalized web development?

It seems like 'declarative web development' won't really take off without a consensus on this.

I guess I'll try to make something to proves HTML Imports are great by themselves, but any other ideas on how to convince Mozilla would be great.

[ebidel]

The Polymer team's experience agrees with you. Unfortunately, specs and the standard process is hard. I don't know how we can convince folks. There have already been many discussions around the topic. To me, the approach that seems best is to have Shadow DOM and Custom Elements land in other browsers, first. At that point the missing pieces will hopefully be obvious.

@dglazkov @justinfagnani @mattsmcnulty

[mmm111mmm]

I'm a little worried, from using ReactJS briefly, that someone might say "Just use Facebook's JSX", counter to the argument that embedding the web component's DOM in javascript is a bad idea.

This would certainly ease the pain of embedded HTML in Javascript, but would be an extra build step, is non-standards compliant and would further weaken the separation of concerns between programmatic javascript and declarative HTML.

Anyway, I think there's a good use case of HTML Imports alone. Use document.createElement with the HTML Import's DOM as the element's content, and clone that into the main document, creating dumb but useful components. If I can prove that would be useful itself it may help the argument. Hopefully I'll have time to do that shortly.

[mmm111mmm]

I think we can advocate that you can have simple components now--one of the things people love about react when talking about 'modules'--using the web standard i.e. HTMLImports alone, without JS or the JSX build step to embed the DOM.

Say you have this simple HTML index file.

<html>
  <head>
    <script src="bower_components/webcomponentsjs/webcomponents-lite.min.js"></script>
    <link rel="import" href="your-component.html" defer>
  </head>
  <body>
    <div class="your-component" name="Jamie"></div>
    <div class="your-component" name="Danny"></div>
  </body>
</html>

The your-component classes say "here I want a component", and to pass in the name parameter. And the import above includes it.

Within the HTMLImport we have simple HTML and five lines of Javascript excluding parameter passing to replace the above your-component nodes with the DOM in the HTMLImport:

<script src="somelibrary.js">
<link href="somestylesheet.css" type="text/css" rel="stylesheet">
<div id="main">
  <span>Hi there, </span><span id="name"></span>
</div>

<script>
  var all = document.querySelectorAll(".your-component");
  for(var i=0;i<all.length;i++) {
    var nodeToAddTo = all[i]; // The main doc's node to convert
    var nameParam = nodeToAddTo.getAttribute("name"); // Param passing
    var component = document._currentScript.ownerDocument.querySelector("#main").cloneNode(true);
    component.querySelector("#name").innerHTML = nameParam; // Param passing
    nodeToAddTo.appendChild(component); // Append our 'component' into the doc
  }
</script>

(The above can also be wrapped in a function to automate the parameter passing and other things, but it may be worthwhile showing how simple it is before you hide the implementation details away)

Advantages

• Finally you can separate your app into 'module' or component files
• No overhead of a third party framework, using only a web standard
• Your components/modules can have their own js/css
• No build steps necessary
• No messing around with embedding HTML into Javascript calls or using a pre-processer
• Even in Firefox, you can http2 preload the webcomponentjs file to experience even less of a delay in these dumb components creation.

Obviously you still have the pre-existing problems of encapsulated CSS, fully-fledged tags--but we already have the answers for those.

Is it worthwhile advocating this as the use case of HTMLImports--as an independent spec--in order to get it some traction in the non-supporting browsers?

[TimvdLippe]

Thank you for your suggestions! Since your issue has been opened, a proposal for your use-case has been opened on w3c/webcomponents. Feel free to read up on the existing discussion and provide suggestions if appropriate.