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

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 19:51:05 UTC