Skip to content

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

Conversation

nicoburns
Copy link
Collaborator

Objective

More correctness fixes for #204. This one covers three additional cases:

  • Content sizing tracks using items spanning 2 track (with fixed sized gaps between)
  • Content sizing tracks using items spanning 2 track (with percentage sized gaps between)
  • Sizing tracks with a fix-content track sizing function where the argument to that function is a percentage.

@nicoburns nicoburns mentioned this pull request Jan 22, 2023
87 tasks
@alice-i-cecile alice-i-cecile added the bug Something isn't working label Jan 22, 2023
@nicoburns nicoburns added this to the 0.3 "CSS Grid" milestone Jan 22, 2023
@@ -566,6 +600,12 @@ fn distribute_item_space_to_base_size(
return;
}

// 0. Prep limit function
Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Description added!

Copy link
Collaborator

@alice-i-cecile alice-i-cecile left a 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.

Copy link
Collaborator

@Weibye Weibye left a 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.

Comment on lines +15 to +21
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
Copy link
Collaborator

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?

Copy link
Collaborator Author

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)),
Copy link
Collaborator

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.

Copy link
Collaborator Author

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's Some)
  • Else returning 0.0

@alice-i-cecile alice-i-cecile enabled auto-merge (squash) January 23, 2023 20:47
@alice-i-cecile alice-i-cecile merged commit 0596475 into DioxusLabs:main Jan 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants