Re: [HTML Imports]: Sync, async, -ish?
On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald jaffathec...@gmail.comwrote:
(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
Re: [HTML Imports]: Sync, async, -ish?
On 28 January 2014 18:19, Ryosuke Niwa rn...@apple.com 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. script's default is terrible, and we're still fighting its default with education. img's default however is pretty good. Isn't it better to delegate this to the component author? Yep, you can get the blocking behaviour back. In fact, you can display:none body until all your components are there if you want, but that's the bar you should have to jump over to create something that results in the user looking at a blank screen during loading. 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. Nope, in some cases appearing would be fine. In others you can reserve space. In others you can show the inner data without interaction. If you really must, you can show a blank screen until everything has loaded. * 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. You never see a flash of unstyled content. Content is only shown once its styles are ready. Basically, html imports are taking cues from script, and script's default behaviour is a mistake. If we must follow the behaviour of something legacy, it should be img. Don't block rendering, show on load, allow the user to do something more blocking if they must.
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 bkard...@gmail.com wrote:
On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald jaffathec...@gmail.comwrote:
(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
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@gmail.comwrote:
: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?
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.
On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
jaffathec...@gmail.comwrote:
: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:30 PM, Jake Archibald jaffathec...@gmail.comwrote:
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 bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
jaffathec...@gmail.comwrote:
: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?
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 bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald
jaffathec...@gmail.comwrote:
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 bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@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
Re: [HTML Imports]: Sync, async, -ish?
(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.
Re: [HTML Imports]: Sync, async, -ish?
On Jan 28, 2014, at 2:11 PM, Jake Archibald jaffathec...@gmail.com wrote: 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? 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?
On Tue, Dec 3, 2013 at 2:22 PM, Bryan McQuade bmcqu...@google.com wrote: Second question: should *rendering* of page content block on the load of link rel=import 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 link rel=imports. 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 script inside an import. That means putting script src=slow-resource.js/script in your import will not slow down the parser as it processes the import tree. It'll continue building the documents of imports while the resource loads. The reason to block rendering while a custom element's load is pending is to prevent a flash of unstyled content/reflow of content on the page. At a high level: We are not blocking rendering on custom elements. We're waiting for a critical resource to load because it may contain style or script. 1. if there are no custom elements in the DOM, [...] 2. if there are custom elements in the DOM [...] We should not be focusing on custom elements here. Imports and custom elements are separate but related features and neither depends on the other. Lots of things could be inside the import. Custom elements don't block anything. However, if the positioning of the custom element changes as a result of its being upgraded, i.e. its x/y/width/height changes, [...] So how do we strike a balance between fast rendering and avoiding reflow/content moving around on the screen? In the case of custom elements there are a few things that browsers can do: 1. if there are no custom elements in the DOM, then even if a load of a custom element import is pending, then there is no reason to block rendering of the rest of the page, since the custom element's load can't impact the styling of content in the DOM. This is not correct. Imports are not just for custom elements, they're a generic system for importing stuff. You can put a style in the import and it will apply to the main page. 2. if there are custom elements in the DOM and a custom element import's load is pending, *and* it can be determined by the rendering engine that the load/upgrade of that element will not cause its *position* to change (e.g. that element has a style=width:x;height:y; attribute, or a style=display:none, etc - we'll have to overlook !important styles for this...) then we should not block rendering of the rest of the page, since the content other than the custom element will not change position as a result of the custom element loading. This is a heuristic that browsers could apply, yes. I don't believe there is a spec for browsers waiting to paint on remote stylesheets though, in fact they probably should paint if the sheet is taking forever to load. However, if there are custom elements in the DOM whose position isn't specified in an inline style, and a custom element import load is pending, then rendering (not parsing!) should block until that custom element has finished loading, to prevent a FOUC/reflow. The parser does not block on rel=import and document.write() is disabled down there for this reason. There's no predictability for where it's going to write since the parser could be anywhere when your import finally loads. If we take this approach, then developers have two ways to prevent the load of custom elements from blocking rendering: ... So, I propose that, similar to pending stylesheets, the load of custom elements should block rendering We can't block anything on custom elements, but we certainly can on imports. I think we should as well and then add an async attribute to allow an author to declare the import as non-critical. . With custom elements, however, we can be a bit smarter than with stylesheets: rendering should block only in cases where the upgrade of a custom element in the DOM might cause a reflow, moving other page content on the screen. There is no way to do this. A document might contain custom elements that are not upgraded until hours later when the author decides to call document.register. In general imports are separate from custom elements as well, we block on them because they're effectively a set of packaged style and script blocks which would have blocked painting had they been inside the main document. - E
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. link async 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 espr...@chromium.org wrote: On Tue, Dec 3, 2013 at 2:22 PM, Bryan McQuade bmcqu...@google.com wrote: Second question: should *rendering* of page content block on the load of link rel=import 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 link rel=imports. 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 script inside an import. That means putting script src=slow-resource.js/script in your import will not slow down the parser as it processes the import tree. It'll continue building the documents of imports while the resource loads. Great! The reason to block rendering while a custom element's load is pending is to prevent a flash of unstyled content/reflow of content on the page. At a high level: We are not blocking rendering on custom elements. We're waiting for a critical resource to load because it may contain style or script. Just to clarify, do you mean not blocking rendering (e.g. render tree construction) or do you mean not blocking parsing (i.e. dom tree construction)? It's clear that we don't block dom tree construction but it seems to be up for debate (and perhaps not spec'd anywhere) whether imports block render tree construction (or whatever equivalent to render tree construction exists in other browsers). Stylesheets block render tree construction to prevent a FOUC. Given that imports may include styles, it seems sensible that they would behave like styles and also block rendering/render tree construction (unless they are marked as async, as you suggest below). 1. if there are no custom elements in the DOM, [...] 2. if there are custom elements in the DOM [...] We should not be focusing on custom elements here. Imports and custom elements are separate but related features and neither depends on the other. Lots of things could be inside the import. Custom elements don't block anything. Thank you - I has assumed imports were only used for custom elements. I understand now that they're more generic and powerful. Given this, I agree - we should not focus on custom elements. However, if the positioning of the custom element changes as a result of its being upgraded, i.e. its x/y/width/height changes, [...] So how do we strike a balance between fast rendering and avoiding reflow/content moving around on the screen? In the case of custom elements there are a few things that browsers can do: 1. if there are no custom elements in the DOM, then even if a load of a custom element import is pending, then there is no reason to block rendering of the rest of the page, since the custom element's load can't impact the styling of content in the DOM. This is not correct. Imports are not just for custom elements, they're a generic system for importing stuff. You can put a style in the import and it will apply to the main page. Agree, thanks for correcting me. 2. if there are custom elements in the DOM and a custom element import's load is pending, *and* it can be determined by the rendering engine that the load/upgrade of that element will not cause its *position* to change (e.g. that element has a style=width:x;height:y; attribute, or a style=display:none, etc - we'll have to overlook !important styles for this...) then we should not block rendering of the rest of the page, since the content other than the custom element will not change position as a result of the custom element loading. This is a heuristic that browsers could apply, yes. I don't believe there is a spec for
Re: [HTML Imports]: Sync, async, -ish?
It seems that there are two distinct questions being discussed on this thread: 1. should script tags that come after link rel=import block their execution on load of the link rel=import completing? 2. should rendering of page content block on the load of link rel=import These are related, but different, and we should discuss each on its own. I'll send a separate reply for each. First: should script execution block on previous link rel=import? example: link rel=import href=foo.html script // should the code in here execute before the link rel=import that precedes it completes? /script As Dimitri notes, scripts do block execution on styles that precede them. So for example: link rel=stylesheet href=foo.css script // my execution blocks on foo.css loading and being parsed /script The reason for this is that the script may want to inspect properties of the document that depend on the style that precedes it. It's worth noting that at one point, WebKit did not block execution of (inline) scripts on the load of stylesheets: https://bugs.webkit.org/show_bug.cgi?id=8852 This was not fixed for quite a long time. The expected behavior has since been specified as part of HTML5: HTML5 compliant parsers are expected to block script execution on pending stylesheets (relevant sections: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts , http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html ) Once the fix to the WebKit bug was landed, blocking inline scripts on pending styles, Google saw a 10-20% load time regression for some pages (bug: https://bugs.webkit.org/show_bug.cgi?id=56842). A lot has changed in WebKit/Blink since this time (the speculative parser has likely become much smarter) so I'm skeptical to assume the cost is still 10-20% today, but we should assume there is a cost. So, the question: Do we want to diverge from the spec'd behavior for stylesheets and make the load of imports not block script execution, or do we want to maintain consistency with existing spec'd stylesheet behavior at the cost of making poorly structured pages possibly slower? I believe it is reasonable to diverge and impose more complexity on developers who do want their script execution to block on the load of imports (by e.g. listening to the load event). FWIW Hixie made the same recommendations for stylesheet loads in 2006: https://bugs.webkit.org/show_bug.cgi?id=8852#c6 As far as accessing style sheets that haven't loaded yet ... that's what the load event is for; if the load hasn't completed yet then trying to access the style sheets isn't going to work. 'Sup yo! There was a thought-provoking post by Steve Souders [1] this weekend that involved HTML Imports (yay!) and document.write (boo!), which triggered a Twitter conversation [2], which triggered some conversations with Arv and Alex, which finally erupted in this email. Today, HTML Imports loading behavior is very simply defined: they act like stylesheets. They load asynchronously, but block script from executing. Some peeps seem to frown on that and demand moar async. I am going to claim that there are two distinct uses of link rel=import: 1) The import is the most important part of the document. Typically, this is when the import is the underlying framework that powers the app, and the app simply won't function without it. In this case, any more async will be all burden and no benefit. 2) The import is the least important of the document. This is the +1 button case. The import is useful, but sure as hell doesn't need to take rendering engine's attention from presenting this document to the user. In this case, async is sorely needed. We should address both of these cases, and we don't right now -- which is a problem. Shoot-from-the-hip Strawman: * The default behavior stays currently specified * The async attribute on link makes import load asynchronously * Also, consider not blocking rendering when blocking script This strawman is intentionally full of ... straw. Please provide a better strawman below:
Re: [HTML Imports]: Sync, async, -ish?
Second question: should *rendering* of page content block on the load of link rel=import 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 link rel=imports. The reason to block rendering while a custom element's load is pending is to prevent a flash of unstyled content/reflow of content on the page. At a high level: * a FOUC is caused when the styling (e.g. color/font/border/background color/etc) of the element changes as a result of applying styles * a reflow is caused when the position (e.g. x/y/width/height) of the element changes as a result of applying styles If a custom element does not change its positioning as a result of being styled, i.e. its x/y/width/height coordinates do not change as a result of the custom element's styles being applied (i.e. as a result of being upgraded), then it seems reasonable to not block rendering of the rest of the page on the load of that element. Additionally, one can use :unresolved to style such an element while it is being loaded. However, if the positioning of the custom element changes as a result of its being upgraded, i.e. its x/y/width/height changes, then the styling of that element may cause a reflow, causing other content on the screen that may have already rendered to move around. Imagine two siblings in the DOM that each have display:inline-block. If the first is a custom element, and its width changes when it upgrades, it'll cause the next sibling and any subsequent siblings to shift right and possibly to wrap to the next line if they exceed the width of the parent. As Steve notes in a comment on his post, :unresolved can't be used to prevent other elements on the screen from moving around in this case. This results in a bad user experience (we've all experienced the annoying behavior of content moving as we are reading it, due to a reflow) and the web platform should try to prevent this. So how do we strike a balance between fast rendering and avoiding reflow/content moving around on the screen? In the case of custom elements there are a few things that browsers can do: 1. if there are no custom elements in the DOM, then even if a load of a custom element import is pending, then there is no reason to block rendering of the rest of the page, since the custom element's load can't impact the styling of content in the DOM. 2. if there are custom elements in the DOM and a custom element import's load is pending, *and* it can be determined by the rendering engine that the load/upgrade of that element will not cause its *position* to change (e.g. that element has a style=width:x;height:y; attribute, or a style=display:none, etc - we'll have to overlook !important styles for this...) then we should not block rendering of the rest of the page, since the content other than the custom element will not change position as a result of the custom element loading. However, if there are custom elements in the DOM whose position isn't specified in an inline style, and a custom element import load is pending, then rendering (not parsing!) should block until that custom element has finished loading, to prevent a FOUC/reflow. If we take this approach, then developers have two ways to prevent the load of custom elements from blocking rendering: 1. don't add custom elements to the DOM before the custom element's imported content has finished loading 2. explicitly specify the positioning of the custom element in an inline style to tell the rendering engine that its position is fixed and will not change as a result of being upgraded So, I propose that, similar to pending stylesheets, the load of custom elements should block rendering. With custom elements, however, we can be a bit smarter than with stylesheets: rendering should block only in cases where the upgrade of a custom element in the DOM might cause a reflow, moving other page content on the screen.
Re: [HTML Imports]: Sync, async, -ish?
* Bryan McQuade wrote: 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). That should be http://www.stevesouders.com/blog/2013/11/26/performance-and-custom-elements/ See http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0702.html Your mail client has issues. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [HTML Imports]: Sync, async, -ish?
Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens. And for that matter, what rendering means. The original reason why script blocks execution until imports are loaded was not even related to rendering. It was a simple solution to an ordering problem -- if I am inside a script block, I am assured that any script before it had also run (whether it came from imports or not). It's the same reason why ES modules need a new HTML element (or script type at the very list). Blocking rendering was as a side effect, since we simply took the plumbing from stylesheets. Then, events took a bewildering turn. Suddenly, this side effect turned into a feature/bug and now we're knee-deep in the sync-vs-async argument. And that's why all solutions look bad. With elements attribute, we're letting the user of the import pick the poison they prefer (would you like your page to be slow or would you rather it flash spastically?) With sync or async attribute, we're faced with an enormous responsibility of predicting the right default for a new feature. Might as well flip a coin there. I say we call out the elephant. We need an API to control when things appear on screen. Especially, when things _first_ appear on screen. :DG
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote:
Stepping back a bit, I think we're struggling to ignore the elephant in
the room. This elephant is the fact that there's no specification (or API)
that defines (or provides facilities to control) when rendering happens.
And for that matter, what rendering means.
The original reason why script blocks execution until imports are loaded
was not even related to rendering. It was a simple solution to an ordering
problem -- if I am inside a script block, I am assured that any script
before it had also run (whether it came from imports or not). It's the same
reason why ES modules need a new HTML element (or script type at the very
list).
Blocking rendering was as a side effect, since we simply took the plumbing
from stylesheets.
Then, events took a bewildering turn. Suddenly, this side effect turned
into a feature/bug and now we're knee-deep in the sync-vs-async argument.
And that's why all solutions look bad.
With elements attribute, we're letting the user of the import pick the
poison they prefer (would you like your page to be slow or would you rather
it flash spastically?)
With sync or async attribute, we're faced with an enormous
responsibility of predicting the right default for a new feature. Might
as well flip a coin there.
I say we call out the elephant.
Agree entirely. Most any time we get into a situation where the UA can't
do the right thing it's because we're trying to have a debate without all
the information. There's a big role for us to play in setting defaults one
way or the other, particularly when they have knock-on optimization
effects, but that's something we know how to do.
We need an API to control when things appear on screen. Especially, when
things _first_ appear on screen.
+1000!!!
I'll take a stab at it. To prevent running afoul of existing heuristics in
runtimes regarding paint, I suggest this be declarative. That keeps us from
blocking anything based on a script element. To get the engine into the
right mode as early as possible, I also suggest it be an attribute on an
early element (html, link, or meta). Using meta http-equiv=...
gives us a hook into possibly exposing the switch as an HTTP header,
although it makes any API less natural as we don't then have a place in the
DOM to hang it from.
In terms of API capabilities, we can cut this a couple of ways (not
entirely exclusive):
1. Explicit paint control, all the time, every time. This is very unlike
the current model and, on pages that opt into it, would make them entirely
dependent on JS for getting things on screens.
1. This opens up a question of scoping: should all paints be blocked?
Only for some elements? Should layouts be delayed until paints are
requested? Since layouts are difficult to scope, what does paint scoping
mean for them?
2. An alternative might be a flag that's a one-time edge trigger:
something that delays the *first* paint and, via an API, perhaps other
upcoming paints, but which does not block the course of regular
painting/layout.
3. We would want to ensure that any API doesn't lock us into a
contract of running code when a page is hidden doesn't actually
need to be
repainted (based on layout invalidation, etc.) or is hidden.
2. Some sort of a paint threshold value (in ms) that defines how
quickly the system should try to call back into script to kick off a paint
and a timeout value for how long it should wait before painting anyway.
Could be combined with #1.
A first cut that takes some (but not all) of this into account might look
like:
html paintpolicy=explicit !-- defaults to implicit --
...
script
// Explicit first-paint which switches
// mode to implicit painting thereafter:
window.requestAnimationFrame(function(timestamp) {
document.documentElement.paint();
document.documentElement.paintPolicy = implicit;
});
/script
This leaves questions of what individual elements can do to paint
themselves unresolved, but something we should also investigate.
Thoughts?
:DG
Re: [HTML Imports]: Sync, async, -ish?
Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly, let's give it a shot! Alex, I completely agree that declarative features should play a huge role in the solution, and I love the power/granularity you're alluding to in your proposal. WARNING: the following may be completely lol-batshit-crazy, so be nice! (remember, I'm not *really *a CS person...I occasionally play one on TV). What if we created something like this: head paint policy=blocking *// non-blocking would be the default policy* link rel=import href=first-load-components.html / script *// Some script here** that is required for initial setup of or interaction* * // ** with the custom elements imported from first-load-components.html* /script /paint /head body section *// content here is subject to default browser paint flow* /section aside paint framerate=5 *// this content is essentially designated as low-priority, // but framerate=5 could also be treated as a lower-bound target.* /paint /aside /body Here's what I intended in the example above: - A paint element would allow devs to easily, and explicitly, wrap multiple elements with their own paint settings. *(you could go also use attributes I suppose, but this way it is easy for someone new to the code to Jump Right In™) * - If there was a paint element, we could build-in a ton of tunable, high-precision features that are easy to manipulate from all contexts I'm going to duck now - I anticipate things will soon be thrown at me. - Daniel On Wed, Nov 27, 2013 at 11:03 AM, Alex Russell slightly...@google.comwrote: On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote: Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens. And for that matter, what rendering means. The original reason why script blocks execution until imports are loaded was not even related to rendering. It was a simple solution to an ordering problem -- if I am inside a script block, I am assured that any script before it had also run (whether it came from imports or not). It's the same reason why ES modules need a new HTML element (or script type at the very list). Blocking rendering was as a side effect, since we simply took the plumbing from stylesheets. Then, events took a bewildering turn. Suddenly, this side effect turned into a feature/bug and now we're knee-deep in the sync-vs-async argument. And that's why all solutions look bad. With elements attribute, we're letting the user of the import pick the poison they prefer (would you like your page to be slow or would you rather it flash spastically?) With sync or async attribute, we're faced with an enormous responsibility of predicting the right default for a new feature. Might as well flip a coin there. I say we call out the elephant. Agree entirely. Most any time we get into a situation where the UA can't do the right thing it's because we're trying to have a debate without all the information. There's a big role for us to play in setting defaults one way or the other, particularly when they have knock-on optimization effects, but that's something we know how to do. We need an API to control when things appear on screen. Especially, when things _first_ appear on screen. +1000!!! I'll take a stab at it. To prevent running afoul of existing heuristics in runtimes regarding paint, I suggest this be declarative. That keeps us from blocking anything based on a script element. To get the engine into the right mode as early as possible, I also suggest it be an attribute on an early element (html, link, or meta). Using meta http-equiv=... gives us a hook into possibly exposing the switch as an HTTP header, although it makes any API less natural as we don't then have a place in the DOM to hang it from. In terms of API capabilities, we can cut this a couple of ways (not entirely exclusive): 1. Explicit paint control, all the time, every time. This is very unlike the current model and, on pages that opt into it, would make them entirely dependent on JS for getting things on screens. 1. This opens up a question of scoping: should all paints be blocked? Only for some elements? Should layouts be delayed until paints are requested? Since layouts are difficult to scope, what does paint scoping mean for them? 2. An alternative might be a flag that's a one-time edge trigger: something that delays the *first* paint and, via an API, perhaps other upcoming paints, but which does not block the course of regular painting/layout. 3. We would want to ensure that any API doesn't
Re: [HTML Imports]: Sync, async, -ish?
I just can't help thinking this is whole line of reasoning all too complicated to achieve wide adoption and thus impact. The supposed power of declarative languages is ability to reason from top to bottom. Creating all of these exceptions causes the very problems being discussed: FOUC occurs because HTML Import runs async even though it looks like is it sync. Then we patch that up with eg elements and paint. On the other hand, JS has allowed very sophisticated application loading to be implemented. If the async HTML Import were done with JS and if we added (if needed) rendering control support to JS, then we allow high function sites complete control of the loading sequence. I think we should be asking: what can we do to have the best chance that most sites will show reasonable default content while loading on mobile networks? A complex solution with confusing order of operations is fine for some sites, let them do it in JS. A declarative solution where default content appears before high-function content seems more likely to succeed for the rest. A complex declarative solution seems like the worst of both. HTH, jjb On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner dan...@mozilla.com wrote: Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly, let's give it a shot! Alex, I completely agree that declarative features should play a huge role in the solution, and I love the power/granularity you're alluding to in your proposal. WARNING: the following may be completely lol-batshit-crazy, so be nice! (remember, I'm not *really *a CS person...I occasionally play one on TV). What if we created something like this: head paint policy=blocking *// non-blocking would be the default policy* link rel=import href=first-load-components.html / script *// Some script here** that is required for initial setup of or interaction* * // ** with the custom elements imported from first-load-components.html* /script /paint /head body section *// content here is subject to default browser paint flow* /section aside paint framerate=5 *// this content is essentially designated as low-priority, // but framerate=5 could also be treated as a lower-bound target.* /paint /aside /body Here's what I intended in the example above: - A paint element would allow devs to easily, and explicitly, wrap multiple elements with their own paint settings. *(you could go also use attributes I suppose, but this way it is easy for someone new to the code to Jump Right In™) * - If there was a paint element, we could build-in a ton of tunable, high-precision features that are easy to manipulate from all contexts I'm going to duck now - I anticipate things will soon be thrown at me. - Daniel On Wed, Nov 27, 2013 at 11:03 AM, Alex Russell slightly...@google.comwrote: On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote: Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens. And for that matter, what rendering means. The original reason why script blocks execution until imports are loaded was not even related to rendering. It was a simple solution to an ordering problem -- if I am inside a script block, I am assured that any script before it had also run (whether it came from imports or not). It's the same reason why ES modules need a new HTML element (or script type at the very list). Blocking rendering was as a side effect, since we simply took the plumbing from stylesheets. Then, events took a bewildering turn. Suddenly, this side effect turned into a feature/bug and now we're knee-deep in the sync-vs-async argument. And that's why all solutions look bad. With elements attribute, we're letting the user of the import pick the poison they prefer (would you like your page to be slow or would you rather it flash spastically?) With sync or async attribute, we're faced with an enormous responsibility of predicting the right default for a new feature. Might as well flip a coin there. I say we call out the elephant. Agree entirely. Most any time we get into a situation where the UA can't do the right thing it's because we're trying to have a debate without all the information. There's a big role for us to play in setting defaults one way or the other, particularly when they have knock-on optimization effects, but that's something we know how to do. We need an API to control when things appear on screen. Especially, when things _first_ appear on screen. +1000!!! I'll take a stab at it. To prevent running afoul of existing heuristics in runtimes regarding paint, I suggest this be
Re: [HTML Imports]: Sync, async, -ish?
JJB, this is precisely why the paint concept seemed like a good idea to me: - Easy to use in just one or two places if needed, without a steep cliff - The choice shouldn't be: either put up with the browser's default render flow, or become a low-level, imperative, perf hacker - Enables load/render/paint tuning of both graphical and non-visible, purely-functional elements - Flexible enough to allow for complex cases, while being (relatively) easy to grok for beginners - Doesn't require devs to juggle a mix of declarative, top-level settings, and imperative, per-element settings - Daniel On Wed, Nov 27, 2013 at 12:19 PM, John J Barton johnjbar...@johnjbarton.com wrote: I just can't help thinking this is whole line of reasoning all too complicated to achieve wide adoption and thus impact. The supposed power of declarative languages is ability to reason from top to bottom. Creating all of these exceptions causes the very problems being discussed: FOUC occurs because HTML Import runs async even though it looks like is it sync. Then we patch that up with eg elements and paint. On the other hand, JS has allowed very sophisticated application loading to be implemented. If the async HTML Import were done with JS and if we added (if needed) rendering control support to JS, then we allow high function sites complete control of the loading sequence. I think we should be asking: what can we do to have the best chance that most sites will show reasonable default content while loading on mobile networks? A complex solution with confusing order of operations is fine for some sites, let them do it in JS. A declarative solution where default content appears before high-function content seems more likely to succeed for the rest. A complex declarative solution seems like the worst of both. HTH, jjb On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner dan...@mozilla.comwrote: Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly, let's give it a shot! Alex, I completely agree that declarative features should play a huge role in the solution, and I love the power/granularity you're alluding to in your proposal. WARNING: the following may be completely lol-batshit-crazy, so be nice! (remember, I'm not *really *a CS person...I occasionally play one on TV). What if we created something like this: head paint policy=blocking *// non-blocking would be the default policy* link rel=import href=first-load-components.html / script *// Some script here** that is required for initial setup of or interaction* * // ** with the custom elements imported from first-load-components.html* /script /paint /head body section *// content here is subject to default browser paint flow* /section aside paint framerate=5 *// this content is essentially designated as low-priority, // but framerate=5 could also be treated as a lower-bound target.* /paint /aside /body Here's what I intended in the example above: - A paint element would allow devs to easily, and explicitly, wrap multiple elements with their own paint settings. *(you could go also use attributes I suppose, but this way it is easy for someone new to the code to Jump Right In™) * - If there was a paint element, we could build-in a ton of tunable, high-precision features that are easy to manipulate from all contexts I'm going to duck now - I anticipate things will soon be thrown at me. - Daniel On Wed, Nov 27, 2013 at 11:03 AM, Alex Russell slightly...@google.comwrote: On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote: Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens. And for that matter, what rendering means. The original reason why script blocks execution until imports are loaded was not even related to rendering. It was a simple solution to an ordering problem -- if I am inside a script block, I am assured that any script before it had also run (whether it came from imports or not). It's the same reason why ES modules need a new HTML element (or script type at the very list). Blocking rendering was as a side effect, since we simply took the plumbing from stylesheets. Then, events took a bewildering turn. Suddenly, this side effect turned into a feature/bug and now we're knee-deep in the sync-vs-async argument. And that's why all solutions look bad. With elements attribute, we're letting the user of the import pick the poison they prefer (would you like your page to be slow or would you rather it flash spastically?) With sync or async attribute, we're faced with an enormous
Re: [HTML Imports]: Sync, async, -ish?
What if: head ... link rel=import href=elements/pi-app.html ... /head body ... pi-app theme=polymer-ui-light-theme div class=app-loading/div /pi-app ... was instead: pi-app import=elements/pi-app.html theme=polymer-ui-light-theme div class=app-loading/div /pi-app If I want to avoid FOUC, I precede this code with style that fill app-loading or that display:none pi-app, then pi-app.html changes the styles. If I want to block script on pi-app I use load events. If I want script to block pi-app loading, I put that script before pi-app. I'm just suggesting this, as a dependency - driven model where the dependency is attached directly to the dependent rather than floating up in link. This is similar to JS modules where the importer says import, not .html saying script. (There are lots of HTML Import things that this may complicate, it's just a suggestion of another point of view). On Wed, Nov 27, 2013 at 12:32 PM, Daniel Buchner dan...@mozilla.com wrote: JJB, this is precisely why the paint concept seemed like a good idea to me: - Easy to use in just one or two places if needed, without a steep cliff - The choice shouldn't be: either put up with the browser's default render flow, or become a low-level, imperative, perf hacker - Enables load/render/paint tuning of both graphical and non-visible, purely-functional elements - Flexible enough to allow for complex cases, while being (relatively) easy to grok for beginners - Doesn't require devs to juggle a mix of declarative, top-level settings, and imperative, per-element settings - Daniel On Wed, Nov 27, 2013 at 12:19 PM, John J Barton johnjbar...@johnjbarton.com wrote: I just can't help thinking this is whole line of reasoning all too complicated to achieve wide adoption and thus impact. The supposed power of declarative languages is ability to reason from top to bottom. Creating all of these exceptions causes the very problems being discussed: FOUC occurs because HTML Import runs async even though it looks like is it sync. Then we patch that up with eg elements and paint. On the other hand, JS has allowed very sophisticated application loading to be implemented. If the async HTML Import were done with JS and if we added (if needed) rendering control support to JS, then we allow high function sites complete control of the loading sequence. I think we should be asking: what can we do to have the best chance that most sites will show reasonable default content while loading on mobile networks? A complex solution with confusing order of operations is fine for some sites, let them do it in JS. A declarative solution where default content appears before high-function content seems more likely to succeed for the rest. A complex declarative solution seems like the worst of both. HTH, jjb On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner dan...@mozilla.comwrote: Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly, let's give it a shot! Alex, I completely agree that declarative features should play a huge role in the solution, and I love the power/granularity you're alluding to in your proposal. WARNING: the following may be completely lol-batshit-crazy, so be nice! (remember, I'm not *really *a CS person...I occasionally play one on TV). What if we created something like this: head paint policy=blocking *// non-blocking would be the default policy* link rel=import href=first-load-components.html / script *// Some script here** that is required for initial setup of or interaction* * // ** with the custom elements imported from first-load-components.html* /script /paint /head body section *// content here is subject to default browser paint flow* /section aside paint framerate=5 *// this content is essentially designated as low-priority, // but framerate=5 could also be treated as a lower-bound target.* /paint /aside /body Here's what I intended in the example above: - A paint element would allow devs to easily, and explicitly, wrap multiple elements with their own paint settings. *(you could go also use attributes I suppose, but this way it is easy for someone new to the code to Jump Right In™) * - If there was a paint element, we could build-in a ton of tunable, high-precision features that are easy to manipulate from all contexts I'm going to duck now - I anticipate things will soon be thrown at me. - Daniel On Wed, Nov 27, 2013 at 11:03 AM, Alex Russell slightly...@google.comwrote: On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote: Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines
Re: [HTML Imports]: Sync, async, -ish?
(way behind, slowly catching up...) On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote: Steve and I talked at the Chrome Dev Summit today and generated an idea that may align the stars for our async/sync needs: link rel=import elements=x-foo, x-bar / +1. I think this is the right default: async by default, and the wrong thing to do (i.e. blocking) requires additional code and explicit opt-in. If you end up with a super-long elements list (as shown by dfreedm@), then that also serves as a great indicator that you're likely doing it wrong -- you have too many blocking elements and a performance liability on your hands.
Re: [HTML Imports]: Sync, async, -ish?
I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.com wrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). The best part of an explicit 'sync' attribute, is that we can now remove the block if a script comes after an import condition, right Dimitri? - Daniel On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com wrote: I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.com wrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). The best part of an explicit 'sync' attribute, is that we can now remove the block if a script comes after an import condition, right Dimitri? As far as I know, script already blocks rendering and I don't think even Dimitri can change that ;-) Blocking script until HTML Import succeeds is not needed as we discussed earlier: scripts that want to run after Import already have an effective and well known mechanism to delay execution, listening for load events. - Daniel On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com wrote: I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.comwrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). Except that sync XHR is considered one of the great miss designs of the web and is causing huge UI issues for users and great pain for developers. If we had the opportunity we would remove it in a heartbeat. / Jonas
Re: [HTML Imports]: Sync, async, -ish?
I'm not talking about the script blocking as usual - I'm referencing the presence of a script causing the import to block until completed, when the script follows it. On Fri, Nov 22, 2013 at 8:57 AM, John J Barton johnjbar...@johnjbarton.comwrote: On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner dan...@mozilla.comwrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). The best part of an explicit 'sync' attribute, is that we can now remove the block if a script comes after an import condition, right Dimitri? As far as I know, script already blocks rendering and I don't think even Dimitri can change that ;-) Blocking script until HTML Import succeeds is not needed as we discussed earlier: scripts that want to run after Import already have an effective and well known mechanism to delay execution, listening for load events. - Daniel On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com wrote: I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.comwrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
Of course I realize this Jonas, but I assure you, if you burden the most common use-cases with poor ergonomics, developers will find even more ghastly ways to degrade perf. Can someone post an overview of the proposed solutions, and how they apply to the use-cases stated a few posts back? On Fri, Nov 22, 2013 at 9:05 AM, Jonas Sicking jo...@sicking.cc wrote: On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). Except that sync XHR is considered one of the great miss designs of the web and is causing huge UI issues for users and great pain for developers. If we had the opportunity we would remove it in a heartbeat. / Jonas
Re: [HTML Imports]: Sync, async, -ish?
Steve and I talked at the Chrome Dev Summit today and generated an idea that may align the stars for our async/sync needs: link rel=import elements=x-foo, x-bar / The idea is that imports are always treated as async, unless the developer opts-in to blocking based on the presence of specific tags. If the parser finds custom elements in the page that match user-defined elements tag names, it would block rendering until the associated link import has finished loading and registering the containing custom elements. Thoughts? - Daniel On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner dan...@mozilla.com wrote: On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote: Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Yes. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. There is, of course, the case of direct document.register() invocation from a script tag, which will/should block to ensure all elements in original source are upgraded. My only point, is that we need to be realistic - both cases are valid and there are good reasons for each. Might we be able to let imports load async, even when a script proceeds them, if we added a *per component type* upgrade event? (note: I'm not talking about a perf-destroying per component instance event) jjb Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, Dimitri Glazkov dglaz...@google.com wrote: John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: link rel=import href=my-ad.html ... my-ad/my-ad .. my-ad.html: script document.register(my-ad, ... ); ... There won't be any rendering blocked here. The page will render, then when my-add.html loads, it will upgrade the my-ad element to display the punch-the-monkey thing. :DG
Re: [HTML Imports]: Sync, async, -ish?
I guess this is designed to solve the flash of unstyled content problem by blocking rendering of tags dependent upon unloaded custom elements? On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote: Steve and I talked at the Chrome Dev Summit today and generated an idea that may align the stars for our async/sync needs: link rel=import elements=x-foo, x-bar / The idea is that imports are always treated as async, unless the developer opts-in to blocking based on the presence of specific tags. If the parser finds custom elements in the page that match user-defined elements tag names, it would block rendering until the associated link import has finished loading and registering the containing custom elements. Thoughts? - Daniel On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner dan...@mozilla.comwrote: On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote: Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Yes. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. There is, of course, the case of direct document.register() invocation from a script tag, which will/should block to ensure all elements in original source are upgraded. My only point, is that we need to be realistic - both cases are valid and there are good reasons for each. Might we be able to let imports load async, even when a script proceeds them, if we added a *per component type* upgrade event? (note: I'm not talking about a perf-destroying per component instance event) jjb Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, Dimitri Glazkov dglaz...@google.com wrote: John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: link rel=import href=my-ad.html ... my-ad/my-ad .. my-ad.html: script document.register(my-ad, ... ); ... There won't be any rendering blocked here. The page will render, then when my-add.html loads, it will upgrade the my-ad element to display the punch-the-monkey thing. :DG
Re: [HTML Imports]: Sync, async, -ish?
Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
I don't see this solution scaling at all. Imports are a tree. If you have any import that includes any other import, now the information about what tags to wait for has to be duplicated along every node in that tree. If a library author chooses to make any sort of all-in-one import to reduce network requests, they will have an absurdly huge list. For example: Brick link rel=import href=brick.html elements=x-tag-appbar x-tag-calendar x-tag-core x-tag-deck x-tag-flipbox x-tag-layout x-tag-slidebox x-tag-slider x-tag-tabbar x-tag-toggle x-tag-tooltip or Polymer link rel=import href=components/polymer-elements.html elements=polymer-ajax polymer-anchor-point polymer-animation polymer-collapse polymer-cookie polymer-dev polymer-elements polymer-expressions polymer-file polymer-flex-layout polymer-google-jsapi polymer-grid-layout polymer-jsonp polymer-key-helper polymer-layout polymer-list polymer-localstorage polymer-media-query polymer-meta polymer-mock-data polymer-overlay polymer-page polymer-scrub polymer-sectioned-list polymer-selection polymer-selector polymer-shared-lib polymer-signals polymer-stock polymer-ui-accordion polymer-ui-animated-pages polymer-ui-arrow polymer-ui-breadcrumbs polymer-ui-card polymer-ui-clock polymer-ui-collapsible polymer-ui-elements polymer-ui-field polymer-ui-icon polymer-ui-icon-button polymer-ui-line-chart polymer-ui-menu polymer-ui-menu-button polymer-ui-menu-item polymer-ui-nav-arrow polymer-ui-overlay polymer-ui-pages polymer-ui-ratings polymer-ui-scaffold polymer-ui-sidebar polymer-ui-sidebar-header polymer-ui-sidebar-menu polymer-ui-splitter polymer-ui-stock polymer-ui-submenu-item polymer-ui-tabs polymer-ui-theme-aware polymer-ui-toggle-button polymer-ui-toolbar polymer-ui-weather polymer-view-source-link On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote: Steve and I talked at the Chrome Dev Summit today and generated an idea that may align the stars for our async/sync needs: link rel=import elements=x-foo, x-bar / The idea is that imports are always treated as async, unless the developer opts-in to blocking based on the presence of specific tags. If the parser finds custom elements in the page that match user-defined elements tag names, it would block rendering until the associated link import has finished loading and registering the containing custom elements. Thoughts? - Daniel On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner dan...@mozilla.comwrote: On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote: Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Yes. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. There is, of course, the case of direct document.register() invocation from a script tag, which will/should block to ensure all elements in original source are upgraded. My only point, is that we need to be realistic - both cases are valid and there are good reasons for each. Might we be able to let imports load async, even when a script proceeds them, if we added a *per component type* upgrade event? (note: I'm not talking about a perf-destroying per component instance event) jjb Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, Dimitri Glazkov dglaz...@google.com wrote: John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in
Re: [HTML Imports]: Sync, async, -ish?
Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.com wrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.comwrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
I don't see this solution scaling at all. Imports are a tree. If you have any import that includes any other import, now the information about what tags to wait for has to be duplicated along every node in that tree. If a library author chooses to make any sort of all-in-one import to reduce network requests, they will have an absurdly huge list. For example: Brick link rel=import href=brick.html elements=x-tag-appbar x-tag-calendar x-tag-core x-tag-deck x-tag-flipbox x-tag-layout x-tag-slidebox x-tag-slider x-tag-tabbar x-tag-toggle x-tag-tooltip or Polymer link rel=import href=components/polymer-elements.html elements=polymer-ajax polymer-anchor-point polymer-animation polymer-collapse polymer-cookie polymer-dev polymer-elements polymer-expressions polymer-file polymer-flex-layout polymer-google-jsapi polymer-grid-layout polymer-jsonp polymer-key-helper polymer-layout polymer-list polymer-localstorage polymer-media-query polymer-meta polymer-mock-data polymer-overlay polymer-page polymer-scrub polymer-sectioned-list polymer-selection polymer-selector polymer-shared-lib polymer-signals polymer-stock polymer-ui-accordion polymer-ui-animated-pages polymer-ui-arrow polymer-ui-breadcrumbs polymer-ui-card polymer-ui-clock polymer-ui-collapsible polymer-ui-elements polymer-ui-field polymer-ui-icon polymer-ui-icon-button polymer-ui-line-chart polymer-ui-menu polymer-ui-menu-button polymer-ui-menu-item polymer-ui-nav-arrow polymer-ui-overlay polymer-ui-pages polymer-ui-ratings polymer-ui-scaffold polymer-ui-sidebar polymer-ui-sidebar-header polymer-ui-sidebar-menu polymer-ui-splitter polymer-ui-stock polymer-ui-submenu-item polymer-ui-tabs polymer-ui-theme-aware polymer-ui-toggle-button polymer-ui-toolbar polymer-ui-weather polymer-view-source-link That's tad hyperbolic Other Daniel (I kid, I kid), you could just as soon use an all value to block until all custom elements were ready. The blocking-tag-name-list may be a poor idea, I have no illusions otherwise - I don't even like it! -- To be honest, I believe all these one-off deviations from developer expectations are the wrong answer. I'd much rather stick with a sync loading import that offered an 'async' attribute to force async loading, regardless of whether a script tag came after it or not. How about we review the use-cases again to get our bearings: 1. Loading a bundle custom elements for the page 2. Loading just custom elements required for the first view and load the rest async 3. Loading template elements for use in the page's lifecycle 4. Loading a random HTML file for random uses #1 is probably going to be the most common use-case. Regardless of what you elect to do with load juggling, developers are going to do whatever they need to to ensure they aren't FUC'd. Hell, if you shake that beehive enough, they'll just start using a script to sync load document.register() declarations. This is not optimal, the best practice/solution should be to sync load only the assets/declarations that are vital to the first render. #2 Yay, developers split their imports between two link tags, one containing the tags required for first render, and another with everything else they don't need until later. If we offered devs an easy way to choose between sync/async imports, it would afford them good ergonomics and good perf (for most use-cases in this sphere). How feasible is this? How often will devs take our advice and do it? Not sure, I guess it would depend on how hard we push import best practices. #3 This will be a super common use-case - devs will do this even when they aren't using Custom Elements. The issue here is much like the one present in case #1 - how likely are devs to split their template imports into two tags, one for first render and one for the rest? #4 I really have no idea how often devs using imports will use it to load random HTML files, but I'd venture this use-case generally will not depend on synchronous import loading. Those (imo) are the primary use-cases we're dealing with. Can we focus on making things transparent and not burdening the most common case among them? As for JJB's assertion that most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. - I couldn't disagree more, this is a fantasy (no offense intended). Just survey many of the most popular apps on any platform - they spin you until the assets and code are ready to show the first screen. - Daniel
Re: [HTML Imports]: Sync, async, -ish?
John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: link rel=import href=my-ad.html ... my-ad/my-ad .. my-ad.html: script document.register(my-ad, ... ); ... There won't be any rendering blocked here. The page will render, then when my-add.html loads, it will upgrade the my-ad element to display the punch-the-monkey thing. :DG
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Nov 20, 2013 at 9:51 AM, John J Barton
johnjbar...@johnjbarton.comwrote:
Another alternative:
First let's agree that Souder's example must block:
link rel=import href=import.php
...
div id=import-container/div
script
var link = document.querySelector('link[rel=import]');
var content = link.import.querySelector('#imported-content');
document.getElementById('import-container').appendChild(content.cloneNode(true));
/script
If we don't block on the script tag then we have a race between the
querySelector and the import, fail.
To me the async solution is on the script, just like it is today load
events:
div id=import-container/div
script
var link = document.querySelector('link[rel=import]');
link.addEventListener('load', function() {
var content = link.import.querySelector('#imported-content');
document.getElementById('import-container').appendChild(content.cloneNode(true));
}
/script
Now the script still blocks but it is short and just registers a handler.
When the link loads it is executed. Here the dependency is correctly set by
the script tag.
But I don't see a 'load' event in the Import spec,
http://www.w3.org/TR/html-imports/
The link element already has a generic load event in the HTML spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-crossorigin(I
tried to get as close as possible to the actual line without
overshooting).
jjb
On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov dglaz...@google.comwrote:
'Sup yo!
There was a thought-provoking post by Steve Souders [1] this weekend that
involved HTML Imports (yay!) and document.write (boo!), which triggered a
Twitter conversation [2], which triggered some conversations with Arv and
Alex, which finally erupted in this email.
Today, HTML Imports loading behavior is very simply defined: they act
like stylesheets. They load asynchronously, but block script from
executing. Some peeps seem to frown on that and demand moar async.
I am going to claim that there are two distinct uses of link rel=import:
1) The import is the most important part of the document. Typically, this
is when the import is the underlying framework that powers the app, and the
app simply won't function without it. In this case, any more async will be
all burden and no benefit.
2) The import is the least important of the document. This is the +1
button case. The import is useful, but sure as hell doesn't need to take
rendering engine's attention from presenting this document to the user. In
this case, async is sorely needed.
We should address both of these cases, and we don't right now -- which is
a problem.
Shoot-from-the-hip Strawman:
* The default behavior stays currently specified
* The async attribute on link makes import load asynchronously
* Also, consider not blocking rendering when blocking script
This strawman is intentionally full of ... straw. Please provide a better
strawman below:
__
__
__
:DG
[1]:
http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/
[2]: https://twitter.com/codepo8/status/401752453944590336
Re: [HTML Imports]: Sync, async, -ish?
Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, Dimitri Glazkov dglaz...@google.com wrote: John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: link rel=import href=my-ad.html ... my-ad/my-ad .. my-ad.html: script document.register(my-ad, ... ); ... There won't be any rendering blocked here. The page will render, then when my-add.html loads, it will upgrade the my-ad element to display the punch-the-monkey thing. :DG
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote: Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Yes. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. jjb Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, Dimitri Glazkov dglaz...@google.com wrote: John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: link rel=import href=my-ad.html ... my-ad/my-ad .. my-ad.html: script document.register(my-ad, ... ); ... There won't be any rendering blocked here. The page will render, then when my-add.html loads, it will upgrade the my-ad element to display the punch-the-monkey thing. :DG
Re: [HTML Imports]: Sync, async, -ish?
On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote: Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Yes. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. There is, of course, the case of direct document.register() invocation from a script tag, which will/should block to ensure all elements in original source are upgraded. My only point, is that we need to be realistic - both cases are valid and there are good reasons for each. Might we be able to let imports load async, even when a script proceeds them, if we added a *per component type* upgrade event? (note: I'm not talking about a perf-destroying per component instance event) jjb Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, Dimitri Glazkov dglaz...@google.com wrote: John's commentary just triggered a thought in my head. We should stop saying that HTML Imports block rendering. Because in reality, they don't. It's the scripts that block rendering. Steve's argument is not about HTML Imports needing to be async. It's about supporting legacy content with HTML Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: link rel=import href=my-ad.html ... my-ad/my-ad .. my-ad.html: script document.register(my-ad, ... ); ... There won't be any rendering blocked here. The page will render, then when my-add.html loads, it will upgrade the my-ad element to display the punch-the-monkey thing. :DG
Re: [HTML Imports]: Sync, async, -ish?
I sent this to Scott only by accident, then noticed when I realized I need to correct myself. First a softer version of my message to Scott: On Mon, Nov 18, 2013 at 5:53 PM, Scott Miles sjmi...@google.com wrote: I believe the primary issue here is 'synchronous with respect to rendering'. Seems like you ignored this issue. See Brian's post. Yes, I agree that issue should be discussed. Rendering synchrony makes a strong case against Dimitri's proposal (now I switch my earlier not-competing opinion). In my opinion, asynchronous component loading driven by dependencies gives the best user experience and simplest dev model. Second best is a synchronous model based on declaration order. Last is an asynchronous declarative model (quote because such solutions are not declarative). I guess you would agree that the best user experience occurs after the web components are loaded. So let's get there the fastest possible way: non blocking asynchronous i/o. After picking the fastest path, we get a bonus: we first render HTML5 content, anything our designers like: blank page, 'brought to you by ...', etc. Thus we get control of the load-time UI. The flash of unstyled content (FOUC) issue need not affect us because we use web components with proper dependences rather than a pile-of-div-s plus some independent JS. The synchronous solution takes longer to load and shows browser defined content in the meantime. Therefore the dependency-driven asynchronous solution has better user experience and a somewhat better dev model than declarative synchronous. The declarative synchronous model has three important advantages: it is simple to code, easy to reason about, and familiar. For the top- or application-level on simple pages I think these advantages are important, despite its failing in performance. A declarative asynchronous solution (async attribute on link tag) can be used to give the same user experience, but it loses on the development model. It gives developers no help in load order and it creates confusion by simulating imperative actions with declarative syntax. FOUC is a sign of the failing of this kind of solution: the unstyled content hits the rendering engine in the wrong order, before the JS that it depends upon. If our dependency design is correct, we only deliver useful content to the rendering engine. Scott On Mon, Nov 18, 2013 at 5:47 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote: I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. You can happily define modules in your imports, those two systems are friends as far as I can tell. I've said this before, I've yet to hear the counter argument. Yes indeed. Dimitri was asking for a better solution, but I agree that both are feasible and compatible. But if you believe in modularity for Web Components then you should believe in modularity for JS Polymer team relies on Custom Elements for JS modularity. But again, this is not mutually exclusive with JS modules, so I don't see the problem. Steve's example concerns synchrony between script and link rel='import'. It would be helpful if you can outline how your modularity solution works for this case. Dimitri's proposal makes the async case much more difficult: you need both the link tag with async attribute then again you need to express the dependency with the clunky onload busines I believe you are making assumptions about the nature of link and async. There are ways of avoiding this problem, Yes I am assuming Steve's example, so again your version would be interesting to see. but it begs the question, which is: if we allow Expressing the dependency in JS then why doesn't 'async' (or 'sync') get us both what we want? I'm not arguing against any other solution that also works. I'm only suggesting a solution that always synchronizes just those blocks of JS that need order-of-execution and thus never needs 'sync' or 'async' and which leads us to unify the module story for the Web. jjb Scott On Mon, Nov 18, 2013 at 2:58 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.comwrote: I love the idea of making HTML imports *not* block rendering as the default behavior So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases where imports are being used to enhance existing pages, but the assertion that this is the primary use case is at least arguable. I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. Today, in the current state of HTML Import and JS modules, this sounds too hard. But if you believe in modularity for Web Components then you should believe in modularity for JS (or look at the Node
Re: [HTML Imports]: Sync, async, -ish?
Now a correction:
On Tue, Nov 19, 2013 at 4:25 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
Last is an asynchronous declarative model (quote because such solutions
are not declarative).
Broadly I am advocating using ES6 modules with HTML imports. The
particular example I made up earlier was patterned after ES6 asynchronous
loading, here I repeat it:
script
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(
true));
});
/script
How does this differ from Dimitri's
link rel=import async href=/imports/heart.html
Well not as much as I claimed before.
Both cases are parsed synchronously and cause subsequent loading. Both can
trigger module loading recursively, my made up version by wiring ES6 module
loading to allow inputs to be HTML Imports and Dimitri's version through
subimports.
The primary difference in this starting the load operation is the
callback. In my made up version the callback would follow the System.load()
pattern from ES6. In Dimtrii's version you have to have a separate script
tag with an event handler and an event triggered by the import.
If the application needs no callback, these two forms are draw on all
counts.
So the crux of a ES6-compatible solution is a JS loader supporting
component loading. If the JS in an HTML import does not import any JS
modules, then asynchronous module loading works, we just don't get JS
modularity.
So I'm back to these don't compete. I think integrating ES6 modules with
HTML Imports can be on ES6. The ES6 solution would be better for the
reasons I outlined previously but everything is better in the future.
jjb
Re: [HTML Imports]: Sync, async, -ish?
Maybe Steve's example[1] could be on JS rather than on components:
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(true));
});
Here we mimic System.load(jsId, success, error). Then make link not
block script: it's on JS to express the dependency correctly.
jjb
On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov dglaz...@google.comwrote:
'Sup yo!
There was a thought-provoking post by Steve Souders [1] this weekend that
involved HTML Imports (yay!) and document.write (boo!), which triggered a
Twitter conversation [2], which triggered some conversations with Arv and
Alex, which finally erupted in this email.
Today, HTML Imports loading behavior is very simply defined: they act like
stylesheets. They load asynchronously, but block script from executing.
Some peeps seem to frown on that and demand moar async.
I am going to claim that there are two distinct uses of link rel=import:
1) The import is the most important part of the document. Typically, this
is when the import is the underlying framework that powers the app, and the
app simply won't function without it. In this case, any more async will be
all burden and no benefit.
2) The import is the least important of the document. This is the +1
button case. The import is useful, but sure as hell doesn't need to take
rendering engine's attention from presenting this document to the user. In
this case, async is sorely needed.
We should address both of these cases, and we don't right now -- which is
a problem.
Shoot-from-the-hip Strawman:
* The default behavior stays currently specified
* The async attribute on link makes import load asynchronously
* Also, consider not blocking rendering when blocking script
This strawman is intentionally full of ... straw. Please provide a better
strawman below:
__
__
__
:DG
[1]:
http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/
[2]: https://twitter.com/codepo8/status/401752453944590336
Re: [HTML Imports]: Sync, async, -ish?
I love the idea of making HTML imports *not* block rendering as the
default behavior
So, for what it's worth, the Polymer team has the exact opposite desire. I
of course acknowledge use cases where imports are being used to enhance
existing pages, but the assertion that this is the primary use case is at
least arguable.
It would be the web dev's responsibility to confirm that the import was
done loading
Our use cases almost always rely on imports to make our pages sane.
Requiring extra code to manage import readiness is a headache.
Dimitri's proposal above tries to be inclusive to both world views, which I
strongly support as both use-cases are valid.
Scott
On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders soud...@google.com wrote:
I love the idea of making HTML imports *not* block rendering as the
default behavior. I believe this is what JJB is saying: make link
rel=import NOT block script.
This is essential because most web pages are likely to have a SCRIPT tag
in the HEAD, thus the HTML import will block rendering of the entire page.
While this behavior is the same as stylesheets, it's likely to be
unexpected. Web devs know the stylesheet is needed for the entire page and
thus the blocking behavior is more intuitive. But HTML imports don't affect
the rest of the page - so the fact that an HTML import can block the entire
page the same way as stylesheets is likely to surprise folks. I don't have
data on this, but the reaction to my blog post reflects this surprise.
Do we need to add a sync (aka blockScriptFromExecuting) attribute? I
don't think so. It would be the web dev's responsibility to confirm that
the import was done loading before trying to insert it into the document
(using the import ready flag). Even better would be to train web devs to
use the LINK's onload handler for that.
-Steve
On Mon, Nov 18, 2013 at 10:16 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Maybe Steve's example[1] could be on JS rather than on components:
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(true));
});
Here we mimic System.load(jsId, success, error). Then make link not
block script: it's on JS to express the dependency correctly.
jjb
On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov dglaz...@google.comwrote:
'Sup yo!
There was a thought-provoking post by Steve Souders [1] this weekend
that involved HTML Imports (yay!) and document.write (boo!), which
triggered a Twitter conversation [2], which triggered some conversations
with Arv and Alex, which finally erupted in this email.
Today, HTML Imports loading behavior is very simply defined: they act
like stylesheets. They load asynchronously, but block script from
executing. Some peeps seem to frown on that and demand moar async.
I am going to claim that there are two distinct uses of link
rel=import:
1) The import is the most important part of the document. Typically,
this is when the import is the underlying framework that powers the app,
and the app simply won't function without it. In this case, any more async
will be all burden and no benefit.
2) The import is the least important of the document. This is the +1
button case. The import is useful, but sure as hell doesn't need to take
rendering engine's attention from presenting this document to the user. In
this case, async is sorely needed.
We should address both of these cases, and we don't right now -- which
is a problem.
Shoot-from-the-hip Strawman:
* The default behavior stays currently specified
* The async attribute on link makes import load asynchronously
* Also, consider not blocking rendering when blocking script
This strawman is intentionally full of ... straw. Please provide a
better strawman below:
__
__
__
:DG
[1]:
http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/
[2]: https://twitter.com/codepo8/status/401752453944590336
Re: [HTML Imports]: Sync, async, -ish?
On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com wrote:
I love the idea of making HTML imports *not* block rendering as the
default behavior
So, for what it's worth, the Polymer team has the exact opposite desire. I
of course acknowledge use cases where imports are being used to enhance
existing pages, but the assertion that this is the primary use case is at
least arguable.
I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'. Today, in the current
state of HTML Import and JS modules, this sounds too hard. But if you
believe in modularity for Web Components then you should believe in
modularity for JS (or look at the Node ecosystem) and gee they ought to
work great together.
It would be the web dev's responsibility to confirm that the import
was done loading
Our use cases almost always rely on imports to make our pages sane.
Requiring extra code to manage import readiness is a headache.
I think your app would be overall even more sane if the dependencies were
expressed directly where they are needed. Rather than loading components
A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B,
C, F. No more checking back to the list of link to compare to the JS
needs.
Dimitri's proposal above tries to be inclusive to both world views, which
I strongly support as both use-cases are valid.
Dimitri's proposal makes the async case much more difficult: you need both
the link tag with async attribute then again you need to express the
dependency with the clunky onload business. Expressing the dependency in JS
avoids both of these issues.
Just to point out: System.component()-ish need not be blocked by completing
ES module details and my arguments only apply for JS dependent upon Web
Components.
Scott
On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders soud...@google.com wrote:
I love the idea of making HTML imports *not* block rendering as the
default behavior. I believe this is what JJB is saying: make link
rel=import NOT block script.
This is essential because most web pages are likely to have a SCRIPT tag
in the HEAD, thus the HTML import will block rendering of the entire page.
While this behavior is the same as stylesheets, it's likely to be
unexpected. Web devs know the stylesheet is needed for the entire page and
thus the blocking behavior is more intuitive. But HTML imports don't affect
the rest of the page - so the fact that an HTML import can block the entire
page the same way as stylesheets is likely to surprise folks. I don't have
data on this, but the reaction to my blog post reflects this surprise.
Do we need to add a sync (aka blockScriptFromExecuting) attribute? I
don't think so. It would be the web dev's responsibility to confirm that
the import was done loading before trying to insert it into the document
(using the import ready flag). Even better would be to train web devs to
use the LINK's onload handler for that.
-Steve
On Mon, Nov 18, 2013 at 10:16 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Maybe Steve's example[1] could be on JS rather than on components:
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(true));
});
Here we mimic System.load(jsId, success, error). Then make link not
block script: it's on JS to express the dependency correctly.
jjb
On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov dglaz...@google.comwrote:
'Sup yo!
There was a thought-provoking post by Steve Souders [1] this weekend
that involved HTML Imports (yay!) and document.write (boo!), which
triggered a Twitter conversation [2], which triggered some conversations
with Arv and Alex, which finally erupted in this email.
Today, HTML Imports loading behavior is very simply defined: they act
like stylesheets. They load asynchronously, but block script from
executing. Some peeps seem to frown on that and demand moar async.
I am going to claim that there are two distinct uses of link
rel=import:
1) The import is the most important part of the document. Typically,
this is when the import is the underlying framework that powers the app,
and the app simply won't function without it. In this case, any more async
will be all burden and no benefit.
2) The import is the least important of the document. This is the +1
button case. The import is useful, but sure as hell doesn't need to take
rendering engine's attention from presenting this document to the user. In
this case, async is sorely needed.
We should address both of these cases, and we don't right now -- which
is a problem.
Shoot-from-the-hip Strawman:
* The default behavior stays currently specified
* The async attribute on link makes import load asynchronously
* Also, consider not blocking rendering when blocking script
This strawman is intentionally
Re: [HTML Imports]: Sync, async, -ish?
I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'.
You can happily define modules in your imports, those two systems are
friends as far as I can tell. I've said this before, I've yet to hear the
counter argument.
But if you believe in modularity for Web Components then you should
believe in modularity for JS
Polymer team relies on Custom Elements for JS modularity. But again, this
is not mutually exclusive with JS modules, so I don't see the problem.
Dimitri's proposal makes the async case much more difficult: you need
both the link tag with async attribute then again you need to express the
dependency with the clunky onload busines
I believe you are making assumptions about the nature of link and async.
There are ways of avoiding this problem, but it begs the question, which
is: if we allow Expressing the dependency in JS then why doesn't 'async'
(or 'sync') get us both what we want?
Scott
On Mon, Nov 18, 2013 at 2:58 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com wrote:
I love the idea of making HTML imports *not* block rendering as the
default behavior
So, for what it's worth, the Polymer team has the exact opposite
desire. I of course acknowledge use cases where imports are being used to
enhance existing pages, but the assertion that this is the primary use case
is at least arguable.
I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'. Today, in the current
state of HTML Import and JS modules, this sounds too hard. But if you
believe in modularity for Web Components then you should believe in
modularity for JS (or look at the Node ecosystem) and gee they ought to
work great together.
It would be the web dev's responsibility to confirm that the import
was done loading
Our use cases almost always rely on imports to make our pages sane.
Requiring extra code to manage import readiness is a headache.
I think your app would be overall even more sane if the dependencies were
expressed directly where they are needed. Rather than loading components
A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B,
C, F. No more checking back to the list of link to compare to the JS
needs.
Dimitri's proposal above tries to be inclusive to both world views, which
I strongly support as both use-cases are valid.
Dimitri's proposal makes the async case much more difficult: you need both
the link tag with async attribute then again you need to express the
dependency with the clunky onload business. Expressing the dependency in JS
avoids both of these issues.
Just to point out: System.component()-ish need not be blocked by
completing ES module details and my arguments only apply for JS dependent
upon Web Components.
Scott
On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders soud...@google.comwrote:
I love the idea of making HTML imports *not* block rendering as the
default behavior. I believe this is what JJB is saying: make link
rel=import NOT block script.
This is essential because most web pages are likely to have a SCRIPT tag
in the HEAD, thus the HTML import will block rendering of the entire page.
While this behavior is the same as stylesheets, it's likely to be
unexpected. Web devs know the stylesheet is needed for the entire page and
thus the blocking behavior is more intuitive. But HTML imports don't affect
the rest of the page - so the fact that an HTML import can block the entire
page the same way as stylesheets is likely to surprise folks. I don't have
data on this, but the reaction to my blog post reflects this surprise.
Do we need to add a sync (aka blockScriptFromExecuting) attribute? I
don't think so. It would be the web dev's responsibility to confirm that
the import was done loading before trying to insert it into the document
(using the import ready flag). Even better would be to train web devs to
use the LINK's onload handler for that.
-Steve
On Mon, Nov 18, 2013 at 10:16 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Maybe Steve's example[1] could be on JS rather than on components:
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(true));
});
Here we mimic System.load(jsId, success, error). Then make link not
block script: it's on JS to express the dependency correctly.
jjb
On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov
dglaz...@google.comwrote:
'Sup yo!
There was a thought-provoking post by Steve Souders [1] this weekend
that involved HTML Imports (yay!) and document.write (boo!), which
triggered a Twitter conversation [2], which triggered some conversations
with Arv and Alex, which finally erupted in this email.
Today, HTML Imports loading behavior
Re: [HTML Imports]: Sync, async, -ish?
Mixed response here... I love the idea of making HTML imports *not* block rendering as the default behavior In terms of custom elements, this creates as a standard, the dreaded FOUC problem about which a whole different group of people will be blogging and tweeting... Right? I don't know that the current solution is entirely awesome, I'm just making sure we are discussing the same fact. Also, links in the head and links in the body both work though the spec disallows the later it is defacto - the former blocks, the later doesn't I think. This creates some interesting situations for people that use something like a CMS where they don't get to own the head upfront. So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases where imports are being used to enhance existing pages, but the assertion that this is the primary use case is at least arguable. Scott, is that because of what I said above (why polymer has the exact opposite desire)? if we allow Expressing the dependency in JS then why doesn't 'async' (or 'sync') get us both what we want? Just to kind of flip this on its head a bit - I feel like it is maybe valuable to think that we should worry about how you express it in JS *first* and worry about declarative sugar for one or more of those cases after. I know it seems the boat has sailed on that just a little with imports, but nothing is really final else I think we wouldnt be having this conversation in the first place. Is it plausible to excavate an explantation for the imports magic and define a JS API and then see how we tweak that to solve all the things?
Re: [HTML Imports]: Sync, async, -ish?
Scott, is that because of what I said above (why polymer has the exact opposite desire)? Yes. Plus some salt from the KISS principle. I feel like it is maybe valuable to think that we should worry about how you express [dependencies] in JS I guess I thought ES6 modules already went through all these issues. I'm happy to let modules be The Way for handling JS dependencies. Imports can provide an entree to modules *and* be a vehicle for my other stuff. Scott On Mon, Nov 18, 2013 at 3:56 PM, Brian Kardell bkard...@gmail.com wrote: Mixed response here... I love the idea of making HTML imports *not* block rendering as the default behavior In terms of custom elements, this creates as a standard, the dreaded FOUC problem about which a whole different group of people will be blogging and tweeting... Right? I don't know that the current solution is entirely awesome, I'm just making sure we are discussing the same fact. Also, links in the head and links in the body both work though the spec disallows the later it is defacto - the former blocks, the later doesn't I think. This creates some interesting situations for people that use something like a CMS where they don't get to own the head upfront. So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases where imports are being used to enhance existing pages, but the assertion that this is the primary use case is at least arguable. Scott, is that because of what I said above (why polymer has the exact opposite desire)? if we allow Expressing the dependency in JS then why doesn't 'async' (or 'sync') get us both what we want? Just to kind of flip this on its head a bit - I feel like it is maybe valuable to think that we should worry about how you express it in JS *first* and worry about declarative sugar for one or more of those cases after. I know it seems the boat has sailed on that just a little with imports, but nothing is really final else I think we wouldnt be having this conversation in the first place. Is it plausible to excavate an explantation for the imports magic and define a JS API and then see how we tweak that to solve all the things?
Re: [HTML Imports]: Sync, async, -ish?
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote: I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. You can happily define modules in your imports, those two systems are friends as far as I can tell. I've said this before, I've yet to hear the counter argument. Yes indeed. Dimitri was asking for a better solution, but I agree that both are feasible and compatible. But if you believe in modularity for Web Components then you should believe in modularity for JS Polymer team relies on Custom Elements for JS modularity. But again, this is not mutually exclusive with JS modules, so I don't see the problem. Steve's example concerns synchrony between script and link rel='import'. It would be helpful if you can outline how your modularity solution works for this case. Dimitri's proposal makes the async case much more difficult: you need both the link tag with async attribute then again you need to express the dependency with the clunky onload busines I believe you are making assumptions about the nature of link and async. There are ways of avoiding this problem, Yes I am assuming Steve's example, so again your version would be interesting to see. but it begs the question, which is: if we allow Expressing the dependency in JS then why doesn't 'async' (or 'sync') get us both what we want? I'm not arguing against any other solution that also works. I'm only suggesting a solution that always synchronizes just those blocks of JS that need order-of-execution and thus never needs 'sync' or 'async' and which leads us to unify the module story for the Web. jjb Scott On Mon, Nov 18, 2013 at 2:58 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com wrote: I love the idea of making HTML imports *not* block rendering as the default behavior So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases where imports are being used to enhance existing pages, but the assertion that this is the primary use case is at least arguable. I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. Today, in the current state of HTML Import and JS modules, this sounds too hard. But if you believe in modularity for Web Components then you should believe in modularity for JS (or look at the Node ecosystem) and gee they ought to work great together. It would be the web dev's responsibility to confirm that the import was done loading Our use cases almost always rely on imports to make our pages sane. Requiring extra code to manage import readiness is a headache. I think your app would be overall even more sane if the dependencies were expressed directly where they are needed. Rather than loading components A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B, C, F. No more checking back to the list of link to compare to the JS needs. Dimitri's proposal above tries to be inclusive to both world views, which I strongly support as both use-cases are valid. Dimitri's proposal makes the async case much more difficult: you need both the link tag with async attribute then again you need to express the dependency with the clunky onload business. Expressing the dependency in JS avoids both of these issues. Just to point out: System.component()-ish need not be blocked by completing ES module details and my arguments only apply for JS dependent upon Web Components. Scott On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders soud...@google.comwrote: I love the idea of making HTML imports *not* block rendering as the default behavior. I believe this is what JJB is saying: make link rel=import NOT block script. This is essential because most web pages are likely to have a SCRIPT tag in the HEAD, thus the HTML import will block rendering of the entire page. While this behavior is the same as stylesheets, it's likely to be unexpected. Web devs know the stylesheet is needed for the entire page and thus the blocking behavior is more intuitive. But HTML imports don't affect the rest of the page - so the fact that an HTML import can block the entire page the same way as stylesheets is likely to surprise folks. I don't have data on this, but the reaction to my blog post reflects this surprise. Do we need to add a sync (aka blockScriptFromExecuting) attribute? I don't think so. It would be the web dev's responsibility to confirm that the import was done loading before trying to insert it into the document (using the import ready flag). Even better would be to train web devs to use the LINK's onload handler for that. -Steve On Mon, Nov 18, 2013 at 10:16 PM, John J Barton johnjbar...@johnjbarton.com wrote: Maybe Steve's example[1] could be on JS rather
Re: [HTML Imports]: Sync, async, -ish?
I believe the primary issue here is 'synchronous with respect to rendering'. Seems like you ignored this issue. See Brian's post. Scott On Mon, Nov 18, 2013 at 5:47 PM, John J Barton johnjbar...@johnjbarton.comwrote: On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote: I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. You can happily define modules in your imports, those two systems are friends as far as I can tell. I've said this before, I've yet to hear the counter argument. Yes indeed. Dimitri was asking for a better solution, but I agree that both are feasible and compatible. But if you believe in modularity for Web Components then you should believe in modularity for JS Polymer team relies on Custom Elements for JS modularity. But again, this is not mutually exclusive with JS modules, so I don't see the problem. Steve's example concerns synchrony between script and link rel='import'. It would be helpful if you can outline how your modularity solution works for this case. Dimitri's proposal makes the async case much more difficult: you need both the link tag with async attribute then again you need to express the dependency with the clunky onload busines I believe you are making assumptions about the nature of link and async. There are ways of avoiding this problem, Yes I am assuming Steve's example, so again your version would be interesting to see. but it begs the question, which is: if we allow Expressing the dependency in JS then why doesn't 'async' (or 'sync') get us both what we want? I'm not arguing against any other solution that also works. I'm only suggesting a solution that always synchronizes just those blocks of JS that need order-of-execution and thus never needs 'sync' or 'async' and which leads us to unify the module story for the Web. jjb Scott On Mon, Nov 18, 2013 at 2:58 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com wrote: I love the idea of making HTML imports *not* block rendering as the default behavior So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases where imports are being used to enhance existing pages, but the assertion that this is the primary use case is at least arguable. I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. Today, in the current state of HTML Import and JS modules, this sounds too hard. But if you believe in modularity for Web Components then you should believe in modularity for JS (or look at the Node ecosystem) and gee they ought to work great together. It would be the web dev's responsibility to confirm that the import was done loading Our use cases almost always rely on imports to make our pages sane. Requiring extra code to manage import readiness is a headache. I think your app would be overall even more sane if the dependencies were expressed directly where they are needed. Rather than loading components A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B, C, F. No more checking back to the list of link to compare to the JS needs. Dimitri's proposal above tries to be inclusive to both world views, which I strongly support as both use-cases are valid. Dimitri's proposal makes the async case much more difficult: you need both the link tag with async attribute then again you need to express the dependency with the clunky onload business. Expressing the dependency in JS avoids both of these issues. Just to point out: System.component()-ish need not be blocked by completing ES module details and my arguments only apply for JS dependent upon Web Components. Scott On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders soud...@google.comwrote: I love the idea of making HTML imports *not* block rendering as the default behavior. I believe this is what JJB is saying: make link rel=import NOT block script. This is essential because most web pages are likely to have a SCRIPT tag in the HEAD, thus the HTML import will block rendering of the entire page. While this behavior is the same as stylesheets, it's likely to be unexpected. Web devs know the stylesheet is needed for the entire page and thus the blocking behavior is more intuitive. But HTML imports don't affect the rest of the page - so the fact that an HTML import can block the entire page the same way as stylesheets is likely to surprise folks. I don't have data on this, but the reaction to my blog post reflects this surprise. Do we need to add a sync (aka blockScriptFromExecuting) attribute? I don't think so. It would be the web dev's responsibility to confirm that the import was done loading before trying to insert it into the document (using the import ready
