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

I don't see this solution scaling at all.

Imports are a tree. If you have any import that includes any other import,
now the information about what tags to "wait" for has to be duplicated
along every node in that tree.

If a library author chooses to make any sort of "all-in-one" import to
reduce network requests, they will have an absurdly huge list.

For example:

Brick

<link rel="import" href="brick.html" elements="x-tag-appbar x-tag-calendar
x-tag-core x-tag-deck x-tag-flipbox x-tag-layout x-tag-slidebox
x-tag-slider x-tag-tabbar x-tag-toggle x-tag-tooltip">

or

Polymer

<link rel="import" href="components/polymer-elements.html"
elements="polymer-ajax polymer-anchor-point polymer-animation
polymer-collapse polymer-cookie polymer-dev polymer-elements
polymer-expressions polymer-file polymer-flex-layout polymer-google-jsapi
polymer-grid-layout polymer-jsonp polymer-key-helper polymer-layout
polymer-list polymer-localstorage polymer-media-query polymer-meta
polymer-mock-data polymer-overlay polymer-page polymer-scrub
polymer-sectioned-list polymer-selection polymer-selector
polymer-shared-lib polymer-signals polymer-stock polymer-ui-accordion
polymer-ui-animated-pages polymer-ui-arrow polymer-ui-breadcrumbs
polymer-ui-card polymer-ui-clock polymer-ui-collapsible polymer-ui-elements
polymer-ui-field polymer-ui-icon polymer-ui-icon-button
polymer-ui-line-chart polymer-ui-menu polymer-ui-menu-button
polymer-ui-menu-item polymer-ui-nav-arrow polymer-ui-overlay
polymer-ui-pages polymer-ui-ratings polymer-ui-scaffold polymer-ui-sidebar
polymer-ui-sidebar-header polymer-ui-sidebar-menu polymer-ui-splitter
polymer-ui-stock polymer-ui-submenu-item polymer-ui-tabs
polymer-ui-theme-aware polymer-ui-toggle-button polymer-ui-toolbar
polymer-ui-weather polymer-view-source-link">


On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner <daniel@mozilla.com> wrote:

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