RE: Properties of Custom Layout

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

 

Custom layout might need to know about boxes not in the DOM. I don't think we should allow it to *create* them during the layout though. It's very hard to reason about the tree you're iterating over being modified.

 

Maybe we want to say that the style computation phase can create them, e.g. for the case Ian pointed out. Or, maybe we want to say you need to modify the actual DOM to get what you want. That'll be something we figure out as we work out the details of how something like the flexbox example Ian gave should work.

 

I’m not sure this is going to work. Whether you want to wrap things in a wrapper is totally layout-dependent.

 

Now, of course, maybe this is an indication there are actually two phases in layout: (1) defining which elements layout which elements (possibly wrapped in boxes) and then (2) the proper layout which receives a read-only box tree generated by the previous step and assigns positions to them.

 

A way to achieve things like a custom “position: absolute” would be a tunnel-bubble algorithm where each element gets to define which of its descendants it takes for layout, in which wrapper boxes if such boxes are needed, and so one. The tunnel phase would allow a “position: relative” element to claim all its direct positioned descendants, while the bubble phase would allow normal layouts like “display: block” to claim still-unclaimed children (normal flow) or sub-children elements (subgrid, run-ins, etc).