Re: Properties of Custom Layout

Hi François,

On Tue, Jun 2, 2015 at 3:07 AM, François REMY <francois.remy.dev@outlook.com
> wrote:

> > Shane & [Ian] sat down what we think are some of the desirable
> properties.
> > https://gist.github.com/bfgeek/93408fe4182d87e92b7b
>
>
> I still have a lot to learn about how browsers handle layout internally so
> I'll leave to more experienced people the opportunity to chime in, but here
> are a few comments of mine.
>

For me, this is what custom layout is about; exposing "how browsers handle
layout internally". I'd love to live in a world where we could re-implement
modern (flex, grid) layout modes in user space, and allow developers to
create better / more interesting modes. :)


> - If the browser can decide not to layout some element because it's
> off-viewport, should a custom layout be able to do the same? How/based on
> which pieces of information?
>

In terms of a custom layout function performing performance optimizations,
I don't think we want this at the author level, at least not initially. The
browser has a much better high level view of what to perform layout on &
how expensive that'll be. To get this to work well we'd have to pipe in a
bunch of information like what the current scroll viewport window is,
current time left for the frame, velocity of elements, complexity of
layouts below the current node, etc, etc.

Using/adding this to the spec early would probably be a premature
optimization. If after having used custom layout in the wild there is a
strong use-case for this, then we should reconsider then.

- If a custom layout decides some elements do not need to be included in
> the layout right now to avoid blocking the frame, can it just ask for
> another layout opportunity during the next frame, even if the style wasn't
> updated?
>

I don't believe we want this behavior for custom layout. We want to
encourage developers to make their functions as 'pure'/'idempotent' as
possible. That is called with the same inputs, it should result in the same
layout. (The reason for this is that browser engines may call a custom
layout function a different number of times per frame, and display a
different layout / result).

Similarly some layouts on the web require multiple layouts. (I.e. table &
some other modes, flex?). That is they need to perform layout on a child
node at least twice. With nesting this can grow to N^2. It's unclear to me
how you would reason about layout in this recursive case if you ask for a
layout continuation mid way through.

Additionally this behavior will allow browsers to perform their own
optimizations reliably. This is also an argument for keeping the set of
inputs to custom layout small (not adding the performance information
above) into the mix.

- What if we want to emulate something like scrollbars or carousels? Should
> custom layout be allowed to layout out boxes that are not in the DOM for
> their own purposes, and get some basic events on them and on the layouted
> element itself if it's focusable (I was thinking about: pointer-over,
> pointer-click, focus, enter-key, space-key, left-key, right-key, up-key,
> down-key)? Should we resort to using a web component as a backend for the
> custom layout? If so, is it that far away from the now-shelved "decorator"
> property proposal?
>

Custom Layout will need to know about boxes not in the DOM for layout
purposes (I.e. the fragment tree). I'm not sure what form this will take
yet. As an example, a text node which is a child of a flexbox, can be
wrapped in an anonymous box which isn't in the DOM.

I don't believe that we want to expose any events within custom layout.

As some background: we probably need to run custom layout in a separate
execution context (think of a worker) to reduce/prevent layout cycles, bad
DOM operations, provide idempotency, etc. As an example, if you were in a
custom layout callback (on the main js thread), and decided to remove some
DOM, what happens?

In a separate script execution context world, introducing events into this
execution context would effectively be creating a separate thread of
control which will be hard to rationalize.

Thanks,
Ian