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

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