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

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