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

2014-01-29 Thread Brian Kardell
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?

2014-01-29 Thread Jake Archibald
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?

2014-01-29 Thread Jake Archibald
: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?

2014-01-29 Thread Brian Kardell
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?

2014-01-29 Thread Jake Archibald
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?

2014-01-29 Thread Brian Kardell
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?

2014-01-29 Thread Jake Archibald
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?

2014-01-28 Thread Jake Archibald
(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?

2014-01-28 Thread Ryosuke Niwa
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?

2013-12-04 Thread Elliott Sprehn
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?

2013-12-04 Thread Bryan McQuade
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?

2013-12-03 Thread Bryan McQuade
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?

2013-12-03 Thread Bryan McQuade
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?

2013-12-03 Thread Bjoern Hoehrmann
* 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?

2013-11-27 Thread Dimitri Glazkov
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?

2013-11-27 Thread Alex Russell
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?

2013-11-27 Thread Daniel Buchner
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?

2013-11-27 Thread John J Barton
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?

2013-11-27 Thread Daniel Buchner
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?

2013-11-27 Thread John J Barton
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?

2013-11-26 Thread Ilya Grigorik
(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?

2013-11-22 Thread John J Barton
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?

2013-11-22 Thread Daniel Buchner
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?

2013-11-22 Thread John J Barton
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?

2013-11-22 Thread Jonas Sicking
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?

2013-11-22 Thread Daniel Buchner
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?

2013-11-22 Thread Daniel Buchner
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?

2013-11-21 Thread Daniel Buchner
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?

2013-11-21 Thread John J Barton
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?

2013-11-21 Thread Daniel Buchner
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?

2013-11-21 Thread Daniel Freedman
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?

2013-11-21 Thread John J Barton
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?

2013-11-21 Thread Steve Souders
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?

2013-11-21 Thread Daniel Buchner
 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?

2013-11-20 Thread Dimitri Glazkov
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?

2013-11-20 Thread Daniel Freedman
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?

2013-11-20 Thread Daniel Buchner
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?

2013-11-20 Thread John J Barton
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?

2013-11-20 Thread Daniel Buchner
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?

2013-11-19 Thread John J Barton
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?

2013-11-19 Thread John J Barton
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


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

2013-11-18 Thread Dimitri Glazkov
'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?

2013-11-18 Thread John J Barton
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?

2013-11-18 Thread Scott Miles
 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?

2013-11-18 Thread John J Barton
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?

2013-11-18 Thread Scott Miles
 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?

2013-11-18 Thread Brian Kardell
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?

2013-11-18 Thread Scott Miles
 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?

2013-11-18 Thread John J Barton
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?

2013-11-18 Thread Scott Miles
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