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

> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald 
> <>wrote:
>> :unresolved { display: none; } plus "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).

Reply via email to