Re: [HTML Imports]: Sync, async, -ish?

Steve and I talked at the Chrome Dev Summit today and generated an idea
that may align the stars for our async/sync needs:

<link rel="import" elements="x-foo, x-bar" />

The idea is that imports are always treated as async, unless the developer
opts-in to blocking based on the presence of specific tags. If the parser
finds custom elements in the page that match user-defined "elements" tag
names, it would block rendering until the associated link import has
finished loading and registering the containing custom elements.

Thoughts?

- Daniel


On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner <daniel@mozilla.com> wrote:

>
> On Nov 20, 2013 11:07 AM, "John J Barton" <johnjbarton@johnjbarton.com>
> wrote:
> >
> >
> >
> >
> > On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner <daniel@mozilla.com>
> wrote:
> >>
> >> Dimitri: right on.
> >>
> >> The use of script-after-import is the forcing function in the blocking
> scenario, not imports.
> >
> > Yes.
> >>
> >> Let's not complicate the new APIs and burden the overwhelming use-case
> to service folks who intend to use the technology in alternate ways.
> >
> > I  disagree, but happily the current API seems to handle the alternative
> just fine. The case Steve raise is covered and IMO correctly, now that you
> have pointed out that link supports load event. His original example must
> block and if he wants it not to block it's on him to hook the load event.
> >>
> >> For my bit, as long as the size of the components I include are not
> overly large, I want them to load before the first render and avoid getting
> FUCd or having to write a plethora of special CSS for the not-yet-upgraded
> custom element case.
> >
> > According to my understanding, you are likely to be disappointed: the
> components are loaded asynchronously and on a slow network with a fast
> processor we will render page HTML before the component arrives.  We should
> expect this to be the common case for the foresable future.
> >
>
> There is, of course, the case of direct document.register() invocation
> from a script tag, which will/should block to ensure all elements in
> original source are upgraded. My only point, is that we need to be
> realistic - both cases are valid and there are good reasons for each.
>
> Might we be able to let imports load async, even when a script proceeds
> them, if we added a *per component type* upgrade event? (note: I'm not
> talking about a perf-destroying per component instance event)
>
> > jjb
> >>
> >> Make the intended/majority case easy, and put the onus on the less
> common cases to think about more complex asset arrangement.
> >>
> >> - Daniel
> >>
> >> On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" <dglazkov@google.com>
> wrote:
> >>>
> >>> John's commentary just triggered a thought in my head. We should stop
> saying that HTML Imports block rendering. Because in reality, they don't.
> It's the scripts that block rendering.
> >>>
> >>> Steve's argument is not about HTML Imports needing to be async. It's
> about supporting legacy content with HTML Imports. And I have a bit less
> sympathy for that argument.
> >>>
> >>> You can totally build fully asynchronous HTML Imports-based documents,
> if you follow these two simple rules:
> >>> 1) Don't put scripts after imports in main document
> >>> 2) Use custom elements
> >>>
> >>> As an example:
> >>>
> >>> index.html:
> >>> <link rel=import href=my-ad.html>
> >>> ...
> >>> <my-ad></my-ad>
> >>> ..
> >>>
> >>> my-ad.html:
> >>> <script>
> >>> document.register("my-ad", ... );
> >>> ...
> >>>
> >>> There won't be any rendering blocked here. The page will render, then
> when my-add.html loads, it will upgrade the "my-ad" element to display the
> punch-the-monkey thing.
> >>>
> >>> :DG<
> >
> >
>