What problem does this solve or what need does it fill?
When implementing scrolling on top of a Taffy layout, one needs to know how far the user ought to be able to scroll. This depends on the size of the content within the scrollable region. Taffy has access to the information needed to compute this, so it makes sense to do so and output it as part of the computed layout.
What solution would you like?
For each node:
- Compute the scrollable overflow rectangle (spec: https://www.w3.org/TR/css-overflow-3/#scrollable)
- Store this in
Layout along with the outer size of the node.
- Return it up to it's parent as part of the
SizeAndBaselines struct so that ancestor nodes can use it to compute their own scrollable overflow rectangle.
Notes
- Borders live outside of the scrollable area, but padding scrolls
- The overflowing content of
overflow: visible nodes can affect the scrollable overflow rectangle of it's parent.
- We'll probably want to want to implement
overflow: clip (https://developer.mozilla.org/en-US/docs/Web/CSS/overflow#values) along with this issue. The (only) difference between overflow: visible and overflow: clip would be that overflowing contents of overflow: clip nodes would not affect their parent.
- We'll need to work out how this works for leaf nodes. Currently my thoughts are to implement padding/border/overflow for leaf nodes and to define the return value from
MeasureFuncs to be the intrinsic content-box size the node. We may need to add some kind of perform_layout equivalent for measure funcs. We may also need to pass padding and such into measure funcs.
- The way in which space taken up by scrollbars can cause the scroll width/height to get <scrollbar-width> is not accounted for by just "size" and "scrollable overflow region". So we may also want to output
scrollbar_width and/or has_scrollbar in each axis for each node.
What alternative(s) have you considered?
Don't implement this functionality and leave it for users of Taffy to implement themselves. This is
Additional context
What problem does this solve or what need does it fill?
When implementing scrolling on top of a Taffy layout, one needs to know how far the user ought to be able to scroll. This depends on the size of the content within the scrollable region. Taffy has access to the information needed to compute this, so it makes sense to do so and output it as part of the computed layout.
What solution would you like?
For each node:
Layoutalong with the outer size of the node.SizeAndBaselinesstruct so that ancestor nodes can use it to compute their own scrollable overflow rectangle.Notes
overflow: visiblenodes can affect the scrollable overflow rectangle of it's parent.overflow: clip(https://developer.mozilla.org/en-US/docs/Web/CSS/overflow#values) along with this issue. The (only) difference betweenoverflow: visibleandoverflow: clipwould be that overflowing contents ofoverflow: clipnodes would not affect their parent.MeasureFuncs to be the intrinsic content-box size the node. We may need to add some kind ofperform_layoutequivalent for measure funcs. We may also need to pass padding and such into measure funcs.scrollbar_widthand/orhas_scrollbarin each axis for each node.What alternative(s) have you considered?
Don't implement this functionality and leave it for users of Taffy to implement themselves. This is
Additional context
Overflow::Scroll) inbevy_uibevyengine/bevy#8104