You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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:
Layout
along with the outer size of the node.SizeAndBaselines
struct so that ancestor nodes can use it to compute their own scrollable overflow rectangle.Notes
overflow: visible
nodes 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: visible
andoverflow: clip
would be that overflowing contents ofoverflow: clip
nodes would not affect their parent.MeasureFunc
s to be the intrinsic content-box size the node. We may need to add some kind ofperform_layout
equivalent for measure funcs. We may also need to pass padding and such into measure funcs.scrollbar_width
and/orhas_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
Overflow::Scroll
) inbevy_ui
bevyengine/bevy#8104The text was updated successfully, but these errors were encountered: