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=import>s. 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.
