-
Notifications
You must be signed in to change notification settings - Fork 130
Fix grid track sizing for fit-content(percentage)
and for items spanning percentage gaps
#335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix grid track sizing for fit-content(percentage)
and for items spanning percentage gaps
#335
Conversation
…k sizing rounds WIP
…a fit-content sizing function
…er than available_grid_space
…perty if growth_limit is infinite
src/compute/grid/track_sizing.rs
Outdated
@@ -566,6 +600,12 @@ fn distribute_item_space_to_base_size( | |||
return; | |||
} | |||
|
|||
// 0. Prep limit function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could use a bit more description; the nature and value of this step is fairly unclear when reading the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Description added!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice: I'm glad to see the extensive testing paying off. Generally quite clear, but I left a comment in a spot I think could be improved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like you churn out these PR's faster than I can read them 🚀 It's a luxury problem to have, so keep doing this good work that you do!
The code looks good in my eyes, with the usual caveats about low confidence deep within these algorithms.
<div></div> | ||
<div></div> | ||
<div></div> | ||
<div></div> | ||
<div></div> | ||
<div></div> | ||
<div></div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason why these has a lot of empty divs but the same was removed in a few other tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. For some of the other tests (like alignment for example) you do need multiple rows/columns to be able to test properly so I've been using a 3x3 grid. But that becomes annoying when you want to trace through the code execution as everything is repeated 9 times. The ones where the divs have been removed are the ones I had to debug!
@@ -360,7 +360,13 @@ fn resolve_intrinsic_track_sizes( | |||
&get_track_size_estimate, | |||
); | |||
|
|||
let margin = item.margin.map(|m| m.resolve_or_zero(available_grid_space.width.into_option())).sum_axes(); | |||
let margin = Rect { | |||
left: item.margin.left.resolve_or_zero(Some(0.0)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious if it would be possible to rewrite our resolve-systems so that we could write it something like this:
left: item.margin.left.resolve_or(zero()),
And that it would figure out what type the zero() would need to output.
Not sure if it would work, or if it did, if it would improve readability of the codebase at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that wouldn't actually do quite the same thing. It's actually a coincidence that the argument is zero here. In general the Some(0.0)
will be the actual size of the parent node. It's only zero in this case because in this specific scenario horizontal percentage margins always resolve to zero (because otherwise there would be a cyclic dependency).
What this function is doing is:
- Returning
Points
values - Resolving
Percent
values against the passed in argument (if it'sSome
) - Else returning
0.0
Objective
More correctness fixes for #204. This one covers three additional cases:
fix-content
track sizing function where the argument to that function is a percentage.