W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

From: Brian Kardell <bkardell@gmail.com>
Date: Wed, 29 Jan 2014 11:02:07 -0500
Message-ID: <CADC=+jfYdov41Zt-3VfmthnSsiiZ5JRk1ssJNZEaWUtNYgcsKg@mail.gmail.com>
To: Jake Archibald <jaffathecake@gmail.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
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
Received on Wednesday, 29 January 2014 16:02:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC