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