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

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


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

>
>
>
> On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald <jaffathecake@gmail.com>wrote:
>
>> (I'm late to this party, sorry)
>>
>> I'm really fond of the <link rel="import" elements="x-foo, x-bar">
>> pattern, but I yeah, you could end up with a massive elements list.
>>
>> How about making link[rel=import] async by default, but make elements
>> with a dash in the tagname display:none by default?
>>
>> On a news article with components, the news article would load, the
>> content would be readable, then the components would appear as they load.
>> Similar to images without a width & height specified.
>>
>> As with images, the site developer could apply styling for the component
>> roots before they load, to avoid/minimise the layout change as components
>> load. This could be visibility:hidden along with a width & height (or
>> aspect ratio, which I believe is coming to CSS), or display:block and
>> additional styles to provide a view of the data inside the component that's
>> good enough for a pre-enhancement render.
>>
>> This gives us:
>>
>> * Performance by default (we'd have made scripts async by default if we
>> could go back right?)
>> * Avoids FOUC by default
>> * Can be picked up by a preparser
>> * Appears to block rendering on pages that are build with a root web
>> component
>>
>> Thoughts?
>>
>> Cheers,
>> Jake.
>>
>
> I think that there are clearly use cases where either way feels "right".
>  It's considerably easier to tack on a pattern that makes async "feel" sync
> than the reverse.  I'd like to suggest that Jake's proposal is -almost-
> really good.  As an author, I'd be happier with the proposal if there were
> just a little bit of sugar that made it very very easy to opt in and I
> think that this lacks that only in that it relies either on a root level
> component or some script to tweak something that indicates the body
> visibility or display.  If we realize that this is going to be a common
> pattern, why not just provide the simple abstration as part of the system.
>  This could be as simple as adding something to section 7.2[1] which says
> something like
>
> """
> The :unresolved pseudoclass may also be applied to the body element.  The
> body tag is considered :unresolved until all of the elements contained in
> the original document have been resolved.  This provides authors a simple
> means to additionally manage rendering FOUC including and all the way up to
> fully delaying rendering of the page until the Custom Element dependencies
> are resolved, while still defaulting to asyc/non-blocking behavior.
>
> Example:
> -------------
> /* Apply body styles like background coloring,
> but don't render any elements until it's all ready...
> */
> body:unresolved * {
>     display: none;
> }
> """
>
> WDYT?
>
>
> [1] -
> http://w3c.github.io/webcomponents/spec/custom/#unresolved-element-pseudoclass
>
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>