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 <bkard...@gmail.com> wrote: > On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald > <jaffathec...@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). > > > >