Re: HTML imports and rendering

Morrita-san is right.

Guy, the only time you would see FOUC with imports is in the same
situations when you see FOUC with styles: when the rendering engine
decided to give up the import ever loading.

:DG<

On Sun, Jun 23, 2013 at 11:31 PM, Hajime Morrita <morrita@google.com> wrote:
> Hello,
>
> HTML Imports spec relies on the concept of "things that is blocking
> scripts".
> In HTML, <link>-ed styles are blocking scripts. So All styles that precede a
> <script> are loaded before the script execution.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element
>
> HTML Imports behaves in similar manner. The <link>s to HTML Import block
> following <script> execution.
> So in practice, linked imports are loaded before the page rendering like
> liked styles are applied before that,
> because most of the pages will have some kind of initialization script.
>
>
> Does this make sense?
>
> # @dglazkov correct me if I'm wrong.
>
> --
> morrita
>
>
>
> On Mon, Jun 24, 2013 at 6:45 AM, Guy Bedford <guybedford@googlemail.com>
> wrote:
>>
>> HTML imports don't seem to block the rendering of the HTML page at all.
>>
>> If this is the case, custom elements must always be progressively enhanced
>> with a flash of content and style. This is not always ideal. It can make
>> sense for certain custom elements to only display after having their style
>> and initial scripts run.
>>
>> Has there been any discussion around having attributes on the link tag to
>> specify blocking behaviour at all? Surely it is important to have control
>> over HTML rendering at this level?
>>
>> Yes, build tools / multiplexing should occur for these blocking parts when
>> used in production for performance reasons, but I don't believe the fact
>> that it can become a performance issue is reason enough to force all
>> components to use progressive enhancement. Or am I missing something here?
>
>
>
>
> --
> morrita

Received on Monday, 24 June 2013 18:19:58 UTC