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

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