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

I guess this is designed to solve the flash of unstyled content problem by
blocking rendering of tags dependent upon unloaded custom elements?



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