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

DanielF: You would only list the custom tags that should be treated as
blocking. If *every* tag in Brick and Polymer should be blocking, then we
have a really big issue because right now they're NOT-blocking and there's
nothing in Web Components per se to specify a blocking behavior.

JJB: Website owners aren't going to be happy with either situation:
  - If custom tags are async (backfilled) by default and the custom tag is
a critical part of the page, subjecting users to a page that suddenly
changes layout isn't good.
  - If custom tags (really HTML imports) are sync (block rendering) by
default, then users stare at a blank screen during slow downloads.

I believe we need to pick the best default while also giving developers the
ability to choose what's best for them. Right now I don't see a way for a
developer to choose to have a custom element block rendering, as opposed to
be backfilled later. Do we think this is important? (I think so.) If so,
what's a good way to let web devs make custom elements block?

-Steve



On Thu, Nov 21, 2013 at 3:07 PM, John J Barton
<johnjbarton@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 <daniel@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.
>>
>
>