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

My bad, many apologies. I get what you mean now.

However, if web components are explaining the platform then <body> is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine <select> as a built-in component which is resolved
and given a shadow DOM by internals.


On 29 January 2014 09:19, Brian Kardell <bkardell@gmail.com> wrote:

> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald <jaffathecake@gmail.com>wrote:
>
>> :unresolved { display: none; } plus "lazyload" (
>> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
>> would allow devs to create the non-blocking behaviour. But this is the
>> wrong way around. Devs should have to opt-in to the slow thing and get the
>> fast thing by default.
>>
>>
> Isn't that what I suggested?  I suggested that it be asyc, just as you
> said - and that all we do is add the ability to use the :unresolved pseudo
> class on the body.  This provides authors as a simple means of control for
> opting out of rendering in blocks above the level of the component without
> resorting to the need to do it via script or a root level element which
> serves no other real purpose. This level of ability seems not just simpler,
> but probably more desirable - like a lot of authors I've done a lot of work
> with things that pop into existence and cause relayout -- often the thing I
> want to block or reserve space for isn't the specific content, but a
> container or something.  Seems to me with addition of a body level
> :unresolved you could answer pretty much any use case for partial rendering
> from "just dont do it" all the way to "screw it, the thing pops into
> existence" (the later being the default) very very simply - and at the
> right layer (CSS).
>
>
>
>

Received on Wednesday, 29 January 2014 17:30:36 UTC