Re: [HTML Imports]: Sync, async, -ish?
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 wrote:
>
>
>
> On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald
> wrote:
>
>> My bad, many apologies. I get what you mean now.
>>
>> However, if web components are explaining the platform then is
>> :resolved by browser internals (I don't know if this is how :resolved works
>> currently). Eg, imagine 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 wrote:
>>
>>> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald >> > 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
>
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald wrote:
> My bad, many apologies. I get what you mean now.
>
> However, if web components are explaining the platform then is
> :resolved by browser internals (I don't know if this is how :resolved works
> currently). Eg, imagine 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 wrote:
>
>> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
>> 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
Re: [HTML Imports]: Sync, async, -ish?
My bad, many apologies. I get what you mean now.
However, if web components are explaining the platform then is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine as a built-in component which is resolved
and given a shadow DOM by internals.
On 29 January 2014 09:19, Brian Kardell wrote:
> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
> 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).
>
>
>
>
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald 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).
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 wrote:
>
>
>
> On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald wrote:
>
>> (I'm late to this party, sorry)
>>
>> I'm really fond of the
>> 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
>
Re: [HTML Imports]: Sync, async, -ish?
On 28 January 2014 18:19, Ryosuke Niwa wrote: > > > How about making link[rel=import] async by default, but make elements > with a dash in the tagname display:none by default? > Is it really the right thing to do in all cases? Nope, but no default is. The default shouldn't be slow for the user.
Re: [HTML Imports]: Sync, async, -ish?
On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald wrote:
> (I'm late to this party, sorry)
>
> I'm really fond of the
> 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
Re: [HTML Imports]: Sync, async, -ish?
On Jan 28, 2014, at 2:11 PM, Jake Archibald wrote: > I'm really fond of the 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? Is it really the right thing to do in all cases? Isn't it better to delegate this to the component author? I have a trouble believing that we can impose one default behavior on all web components without providing abilities for web components to override those defaults. > 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. But that would mean that document authors need to be aware of exact dimensions, styles, theme, etc... of each component they use on the page, and add relevant CSS rules. In addition, each component then needs to cancel/override those rules when they get instantiated. > * Performance by default (we'd have made scripts async by default if we could > go back right?) > * Avoids FOUC by default Could you clarify how this proposal avoids FOUC? If unresolved elements were to be initially display: none and turns into display: block/inline later, then that would most likely cause a reflow/relayout of the page and causes a FOUC. - R. Niwa
Re: [HTML Imports]: Sync, async, -ish?
(I'm late to this party, sorry) I'm really fond of the 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.
Re: [HTML Imports]: Sync, async, -ish?
Thanks Elliott! I'll admit I don't (yet) have a deep understanding of imports/web components so I'm not surprised to have overlooked things. Thank you for clarifying these areas for me. So to summarize: * imports should not block parsing/DOM tree construction * imports should block rendering (e.g. render tree construction), just like stylesheets * we should add support for loading stylesheets and imports without blocking rendering, so developers can load imports that they'll use in the future without blocking rendering of other content on their load completing * Elliott proposes adding support for an 'async' tag. indicates that the load of that stylesheet/import must not block rendering. This is useful for both imports and stylesheets (more on this below) On Tue, Dec 3, 2013 at 8:37 PM, Elliott Sprehn wrote: > > On Tue, Dec 3, 2013 at 2:22 PM, Bryan McQuade wrote: > >> Second question: should *rendering* of page content block on the load of >> >> >> Steve Souders wrote another nice post about this topic: >> http://www.stevesouders.com/blog/2013/11/26/performance-and-custom-elements/which >> I recommend reading (read the comments too). >> >> We should start by looking to how the web platform behaves today. All >> browsers I am aware of block rendering on the load of pending stylesheets. >> Note that blocking rendering (blocking of render tree construction and >> painting content to the screen) is different from blocking parsing. >> Browsers do not block HTML parsing (DOM construction) on stylesheets. Nor >> should they block DOM construction on loading of s. >> >> > Correct. Imports are even better than the main document though. > document.write doesn't work, and we allow the parser to "run ahead" and not > block on inside an import. That means putting