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.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. >>>> >>> >>> >> >