RE: Properties of Custom Layout

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

Yes, for sure!

I got for instance contacted for a special grid mode where items would span the "right" amount of columns automatically to fit their content by using some prior knowledge on the column size (no "auto" columns, or "auto" width, and maybe some other restrictions). This requires a layout algorithm that's quite different from the usual one, but which is not impossible to write as a custom layout.

A note, though: I didn't see in the proposed desired properties the ability to rely on an existing layout mode. Maybe the customized grid layout may (after some precomputations and adjustements) actually want to rely on the normal grid for the last steps of the layout. I don't know how feasible this is. If this is not feasible, it's ok, we just need to think about it.


 
>> - 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. [...]
> 
> Using/adding this to the spec early would probably be a premature 
> optimization.

Okay, that's fair, I was just making sure.



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

Okay, so a custom layout can create anonymous boxes. It may be able to 
display a scrollbar, for instance.

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

I agree the events shall not be handled on the main thread, and will not have
access to the DOM. However, I think there may be a way to consider events
in a way similar to Mutation Observers.

I think the event could be logged, invalidate the layout, and made available
when the next layout is computed, so that scrolls/other overflow technologies
may be implemented by a custom layout (so you get a list of all events which
happened on your generated boxes since last layout).

In other words, the events would not be able to interact with the DOM, just
be used to invalidate the layout and react to changes.

Does that look feasible?

Received on Wednesday, 3 June 2015 20:14:17 UTC