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

I'm not talking about the script blocking as usual - I'm referencing the
presence of a script causing the import to block until completed, when the
script follows it.


On Fri, Nov 22, 2013 at 8:57 AM, John J Barton
<johnjbarton@johnjbarton.com>wrote:

>
>
>
> On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner <daniel@mozilla.com>wrote:
>
>> 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?
>>
> As far as I know, <script> already blocks rendering and I don't think even
> Dimitri can change that ;-)  Blocking script until HTML Import succeeds is
> not needed as we discussed earlier: scripts that want to run after Import
> already have an effective and well known mechanism to delay execution,
> listening for load events.
>
>
>> - 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>