- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Wed, 29 Jan 2014 10:06:06 -0800
- To: Brian Kardell <bkardell@gmail.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CAJ5xic_tdCESB02kSFd8cx5utgqRY9at8NpV_voG+YqfTheRcA@mail.gmail.com>
I'm not excited about making render blocking easier, but I think you're
right.
However, this is all premature detail while the behaviour is blocking-first.
On 29 January 2014 09:53, Brian Kardell <bkardell@gmail.com> wrote:
>
>
>
> 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 18:06:33 UTC