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

On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald <jaffathecake@gmail.com>wrote:

> 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.
>
> 7.2 of custom elements states:

"""
The :unresolved pseudoclass *must* match all custom
elements whose created callback has not yet been invoked.
"""

I suppose this leaves wiggle room that it may actually in theory match on
native elements as well.  As you say, this is a nice explanation maybe for
all elements - though - it doesn't seem remarkable what a custom element
would have something a native wouldn't.  Either way, I think my proposal
holds up in basic theory, the only caveat is whether the thing on body is
just a specialized meaning of "resolved" that only applies to custom
elements, or whether you need a specific name for that thing, right?  It's
really entirely bikesheddable what that thing should be called or maps to -
there must be a name for "the document is done upgrading elements that we
in the tree at parse" - I dont think that is DOMContentLoaded, but
hopefully you take my point.  If we could agree that that solution works,
we could then have a cage match to decide on a good name :)



>
> 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).
>>
>>
>>
>>
>
>


-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Wednesday, 29 January 2014 17:53:52 UTC