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

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" <johnjbarton@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 <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.
>>>>
>>>
>>>
>>
>