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

JJB, this is precisely why the <paint> concept seemed like a good idea to
me:

   - Easy to use in just one or two places if needed, without a steep cliff
      - The choice shouldn't be: either put up with the browser's default
      render flow, or become a low-level, imperative, perf hacker
      - Enables load/render/paint tuning of both graphical and non-visible,
   purely-functional elements
   - Flexible enough to allow for complex cases, while being (relatively)
   easy to grok for beginners
   - Doesn't require devs to juggle a mix of declarative, top-level
   settings, and imperative, per-element settings

- Daniel

On Wed, Nov 27, 2013 at 12:19 PM, John J Barton <johnjbarton@johnjbarton.com
> wrote:

> I just can't help thinking this is whole line of reasoning all too
> complicated to achieve wide adoption and thus impact.
>
> The supposed power of declarative languages is ability to reason from top
> to bottom. Creating all of these exceptions causes the very problems being
> discussed: FOUC occurs because HTML Import runs async even though it looks
> like is it sync.  Then we patch that up with eg "elements" and "paint".
>
> On the other hand, JS has allowed very sophisticated application loading
> to be implemented. If the async HTML Import were done with JS and if we
> added (if needed) rendering control support to JS, then we allow high
> function sites complete control of the loading sequence.
>
> I think we should be asking: "what can we do to have the best chance that
> most sites will show reasonable default content while loading on mobile
> networks?" A complex solution with confusing order of operations is fine
> for some sites, let them do it in JS. A declarative solution where default
> content appears before high-function content seems more likely to succeed
> for the rest. A complex declarative solution seems like the worst of both.
> HTH,
> jjb
>
>
> On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner <daniel@mozilla.com>wrote:
>
>> Right on Dimitri, I couldn't agree more. It seems like an involved (but
>> highly beneficial) pursuit - but heck, maybe we'll find an answer quickly,
>> let's give it a shot!
>>
>> Alex, I completely agree that declarative features should play a huge
>> role in the solution, and I love the power/granularity you're alluding to
>> in your proposal. WARNING: the following may be completely
>> lol-batshit-crazy, so be nice! (remember, I'm not *really *a CS
>> person...I occasionally play one on TV). What if we created something like
>> this:
>>
>>      <head>
>>        <paint policy="blocking">  *// "non-blocking" would be the
>> default policy*
>>          <link rel="import" href="first-load-components.html" />
>>          <script>
>>
>>       *// Some script here** that is required for initial setup of or
>> interaction*
>> *       // ** with the custom elements imported from
>> first-load-components.html*
>>
>>     </script>
>>   </paint>
>> </head>
>>
>> <body>
>>
>>   <section>
>>      *// content here is subject to default browser paint flow*
>>   </section>
>>
>>   <aside>
>>     <paint framerate="5">
>>
>> *// this content is essentially designated as low-priority,       // but
>> framerate="5" could also be treated as a lower-bound target.*
>>     </paint>
>>   </aside>
>>
>> </body>
>>
>>
>> Here's what I intended in the example above:
>>
>>    - A <paint> element would allow devs to easily, and explicitly, wrap
>>    multiple elements with their own paint settings. *(you could go also
>>    use attributes I suppose, but this way it is easy for someone new to the
>>    code to Jump Right In™) *
>>    - If there was a <paint> element, we could build-in a ton of tunable,
>>    high-precision features that are easy to manipulate from all contexts
>>
>> I'm going to duck now - I anticipate things will soon be thrown at me.
>>
>> - Daniel
>>
>>
>> On Wed, Nov 27, 2013 at 11:03 AM, Alex Russell <slightlyoff@google.com>wrote:
>>
>>> On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>>
>>>> Stepping back a bit, I think we're struggling to ignore the elephant in
>>>> the room. This elephant is the fact that there's no specification (or API)
>>>> that defines (or provides facilities to control) when rendering happens.
>>>> And for that matter, what rendering means.
>>>>
>>>> The original reason why <script> blocks execution until imports are
>>>> loaded was not even related to rendering. It was a simple solution to an
>>>> ordering problem -- if I am inside a <script> block, I am assured that any
>>>> script before it had also run (whether it came from imports or not). It's
>>>> the same reason why ES modules need a new HTML element (or script type at
>>>> the very list).
>>>>
>>>> Blocking rendering was as a side effect, since we simply took the
>>>> plumbing from stylesheets.
>>>>
>>>> Then, events took a bewildering turn. Suddenly, this side effect turned
>>>> into a feature/bug and now we're knee-deep in the sync-vs-async argument.
>>>>  And that's why all solutions look bad.
>>>>
>>>> With "elements" attribute, we're letting the user of the import pick
>>>> the poison they prefer (would you like your page to be slow or would you
>>>> rather it flash spastically?)
>>>>
>>>> With "sync" or "async" attribute, we're faced with an enormous
>>>> responsibility of predicting the "right" default for a new feature. Might
>>>> as well flip a coin there.
>>>>
>>>> I say we call out the elephant.
>>>>
>>>
>>> Agree entirely. Most any time we get into a situation where the UA can't
>>> "do the right thing" it's because we're trying to have a debate without all
>>> the information. There's a big role for us to play in setting defaults one
>>> way or the other, particularly when they have knock-on optimization
>>> effects, but that's something we know how to do.
>>>
>>>
>>>> We need an API to control when things appear on screen. Especially,
>>>> when things _first_ appear on screen.
>>>>
>>>
>>> +1000!!!
>>>
>>> I'll take a stab at it. To prevent running afoul of existing heuristics
>>> in runtimes regarding paint, I suggest this be declarative. That keeps us
>>> from blocking anything based on a <script> element. To get the engine into
>>> the right mode as early as possible, I also suggest it be an attribute on
>>> an early element (<html>, <link>, or <meta>). Using <meta http-equiv="...">
>>> gives us a hook into possibly exposing the switch as an HTTP header,
>>> although it makes any API less natural as we don't then have a place in the
>>> DOM to hang it from.
>>>
>>> In terms of API capabilities, we can cut this a couple of ways (not
>>> entirely exclusive):
>>>
>>>
>>>    1. Explicit paint control, all the time, every time. This is very
>>>    unlike the current model and, on pages that opt into it, would make them
>>>    entirely dependent on JS for getting things on screens.
>>>       1. This opens up a question of scoping: should all paints be
>>>       blocked? Only for some elements? Should layouts be delayed until paints are
>>>       requested? Since layouts are difficult to scope, what does paint scoping
>>>       mean for them?
>>>       2. An alternative might be a flag that's a one-time edge trigger:
>>>       something that delays the *first* paint and, via an API, perhaps other
>>>       upcoming paints, but which does not block the course of regular
>>>       painting/layout.
>>>       3. We would want to ensure that any API doesn't lock us into a
>>>       contract of running code when a page is hidden doesn't actually need to be
>>>       repainted (based on layout invalidation, etc.) or is hidden.
>>>    2. Some sort of a "paint threshold" value (in ms) that defines how
>>>    quickly the system should try to call back into script to kick off a paint
>>>    and a timeout value for how long it should wait before painting anyway.
>>>    Could be combined with #1.
>>>
>>> A first cut that takes some (but not all) of this into account might
>>> look like:
>>>
>>>  <html paintpolicy="explicit"> <!-- defaults to "implicit" -->
>>>   ...
>>>
>>>   <script>
>>>
>>>     // Explicit first-paint which switches
>>>     // mode to implicit painting thereafter:
>>>
>>>     window.requestAnimationFrame(function(timestamp) {
>>>
>>>       document.documentElement.paint();
>>>
>>>       document.documentElement.paintPolicy = "implicit";
>>>
>>>     });
>>>
>>>   </script>
>>>
>>>
>>> This leaves questions of what individual elements can do to paint
>>> themselves unresolved, but something we should also investigate.
>>>
>>> Thoughts?
>>>
>>>
>>>> :DG<
>>>>
>>>>
>>>
>>
>

Received on Wednesday, 27 November 2013 20:33:55 UTC