Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports. 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.
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.
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" <dglaz...@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<
>
