Hi cybeatb -- so it's a bit hard to reason about this-as-a-bug because it's not clear if any browser matches your expected results (do they?) But, if I understand you correctly: I *think* you're wondering why cell `a` is so large in the top half of the testcase in comment 0 -- you're wondering why that cell looks different from the bottom half of testcase 0, and why it doesn't match the (inverted) version in comment 3 where Firefox and Safari size it to itself. If so: this is a version of the same question that someone else recently filed as bug 1917142. Basically, the sizing of that cell is reliant on how many tracks your `auto-fit` expression expands to; and `auto-fill` and `auto-fit` don't do much of anything in `grid-template-rows` **unless you have a defined size in that axis (a defined `height` or `min-height` in this case)**. In the top half of your comment 0 testcase, your `repeat(auto-fit...)` expression just expands to a single iteration, without any actual repeats. (And that is correct, per the spec, even if it's not what you expect.) This is indeed an asymmetry where things work differently in the row axis vs. the column axis -- this is due to the order in which sizes are resolved in web layout (inline sizes [typically widths] get resolved first, before the content is fully laid out; block-sizes [typically heights] get resolved last, after the layout finishes). This means that things like percentages and `auto-fit` can be resolved in the inline axis (for width & columns) in more cases than they can be resolved in the block axis (for height and rows). Here's a simple example with a percent width and height on a div inside of a content-sized parent, whose width resolves correctly but whose height falls back to `auto` ``` data:text/html,<!DOCTYPE html><div style="float:left; border: 1px solid black"><div style="width: 50%; height: 50%; background: orange">Does the 50-percent resolve in both axes here? ``` See bug 1917142 comment 5 through bug 1917142 comment 7 for more on the details here. In the meantime, unless some other browser is doing this in-the-way-that-you-expect (please let us know if so!), I think this is invalid since we [and others] are matching the spec.
Bug 1916032 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hi cybeatb -- so it's a bit hard to reason about this-as-a-bug because it's not clear if any browser matches your expected results (do they?) But, if I understand you correctly: I *think* you're wondering why cell `a` is so large in the top half of the testcase in comment 0 -- you're wondering why that cell looks different from the bottom half of testcase 0, and why it doesn't match the (inverted) version in comment 3 where Firefox and Safari size it to itself. If so: this is a version of the same question that someone else recently filed as bug 1917142. Basically, the sizing of that cell is reliant on how many tracks your `auto-fit` expression expands to; and `auto-fill` and `auto-fit` don't do much of anything in `grid-template-rows` **unless you have a defined size in that axis (a defined `height` or `min-height` in this case)**. In the top half of your comment 0 testcase, your `repeat(auto-fit...)` expression just expands to a single iteration, without any actual repeats. (And that is correct, per the spec, even if it's not what you expect.) This is indeed an asymmetry where things work differently in the row axis vs. the column axis -- this is due to the order in which sizes are resolved in web layout (inline sizes [typically widths] get resolved first, before the content is fully laid out; block-sizes [typically heights] get resolved last, after the layout finishes). This means that things like percentages and `auto-fit` can be resolved in the inline axis (for width & columns) in more cases than they can be resolved in the block axis (for height and rows). Here's a simple analogous example with a `50%` width and height on a div inside of a content-sized parent; the inner div's width resolves "correctly" but its height falls back to `auto` because we can't resolve it. ``` data:text/html,<!DOCTYPE html><div style="float:left; border: 1px solid black"><div style="width: 50%; height: 50%; background: orange">Does the 50-percent resolve in both axes here? ``` In the same way in your testcases: we can resolve `auto-fit` for the column (horizontal) axis because we can resolve a definite container-width to measure how-many-repeats-will-fit, but we can't resolve a definite container-height to measure how-many-repeats-will-fit in that axis. So the spec tells us to just expand the repeat() expression to a single iteration. See bug 1917142 comment 5 through bug 1917142 comment 7 for more on the details here. In the meantime, unless some other browser is doing this in-the-way-that-you-expect (please let us know if so!), I think this is invalid since we [and others] are matching the spec.
Hi cybeatb -- so it's a bit hard to reason about this-as-a-bug because it's not clear if any browser matches your expected results (do they?) But, if I understand you correctly: I *think* you're wondering why cell `a` is so large in the top half of the testcase in comment 0 -- you're wondering why that cell looks different from the bottom half of testcase 0, and why it doesn't match the (inverted) version in comment 3 where Firefox and Safari size it to itself. If so: this is a version of the same question that someone else recently filed as bug 1917142. Basically, the sizing of that cell is reliant on how many tracks your `auto-fit` expression expands to; and `auto-fill` and `auto-fit` don't do much of anything in `grid-template-rows` **unless you have a defined size in that axis (a defined `height` or `min-height` in this case)**. In the top half of your comment 0 testcase, your `repeat(auto-fit...)` expression just expands to a single iteration, without any actual repeats. (And that is correct, per the spec, even if it's not what you expect.) This is indeed an asymmetry where things work differently in the row axis vs. the column axis -- this is due to the order in which sizes are resolved in web layout (inline sizes [typically widths] get resolved first, before the content is fully laid out; block-sizes [typically heights] get resolved last, after the layout finishes). This means that things like percentages and `auto-fit` can be resolved in the inline axis (for width & columns) in more cases than they can be resolved in the block axis (for height and rows). Here's a simple analogous example with a `50%` width and height on a div inside of a content-sized parent; the inner div's width resolves "correctly" but its height falls back to `auto` because we can't resolve it. ``` data:text/html,<!DOCTYPE html><div style="float:left; border: 1px solid black"><div style="width: 50%; height: 50%; background: orange">Does the 50-percent resolve in both axes here? ``` In the same way that this testcase can resolve a percent in one axis but not the other (because we can pre-compute the constraint size that it resolves against in only one axis): in your testcases, we can resolve `auto-fit` in one axis but not the other (because we can pre-compute the constraint size that it resolves against in only one axis). See bug 1917142 comment 5 through bug 1917142 comment 7 for more on the details here. In the meantime, unless some other browser is doing this in-the-way-that-you-expect (please let us know if so!), I think this is invalid since we [and others] are matching the spec.
Hi cybeatb -- so it's a bit hard to reason about this-as-a-bug because it's not clear if any browser matches your expected results (do they?) But, if I understand you correctly: I *think* you're wondering why cell `a` is so large in the top half of the testcase in comment 0 -- you're wondering why that cell looks different from the bottom half of testcase 0, and why it doesn't match the (inverted) version in comment 3 where Firefox and Safari size it to itself. If so: this is a version of the same question that someone else recently filed as bug 1917142. Basically, the sizing of that cell is reliant on how many tracks your `auto-fit` expression expands to; and `auto-fill` and `auto-fit` don't do much of anything in `grid-template-rows` **unless you have a defined size in that axis (a defined `height` or `min-height` in this case)**. In the top half of your comment 0 testcase, your `repeat(auto-fit...)` expression just expands to a single iteration, without any actual repeats. (And that is correct, per the spec, even if it's not what you expect.) This is indeed an asymmetry where things work differently in the row axis vs. the column axis -- this is due to the order in which sizes are resolved in web layout (inline sizes [typically widths] get resolved first, before the content is fully laid out; block-sizes [typically heights] get resolved last, after the layout finishes). This means that things like percentages and `auto-fit` can be resolved in the inline axis (for width & columns) in more cases than they can be resolved in the block axis (for height and rows). Here's a simple analogous example with a `50%` width and height on a div inside of a content-sized parent; the inner div's width resolves "correctly" but its height falls back to `auto` because we can't resolve it. ``` data:text/html,<!DOCTYPE html><div style="float:left; border: 1px solid black"><div style="width: 50%; height: 50%; background: orange">Does the 50-percent resolve in both axes here? ``` In the same way that this testcase can resolve a percent in one axis but not the other (because we can pre-compute the constraint size that it resolves against in only one axis): in your testcases, we can resolve `auto-fit` in one axis but not the other (because we can pre-compute the constraint size that it repeats-to-fill in only one axis). See bug 1917142 comment 5 through bug 1917142 comment 7 for more on the details here. In the meantime, unless some other browser is doing this in-the-way-that-you-expect (please let us know if so!), I think this is invalid since we [and others] are matching the spec.
Hi cybeatb -- so it's a bit hard to reason about this-as-a-bug because it's not clear if any browser matches your expected results (do they?) But, if I understand you correctly: I *think* you're wondering why cell `a` is so large in the top half of the testcase in comment 0 -- you're wondering why that cell looks different from the bottom half of testcase 0, and why it doesn't match the (inverted) version in comment 3 where Firefox and Safari size it to itself. Is that right? If I'm understanding you correctly: this is a version of the same question that someone else recently filed as bug 1917142. Basically, the sizing of that cell is reliant on how many tracks your `auto-fit` expression expands to; and `auto-fill` and `auto-fit` don't do much of anything in `grid-template-rows` **unless you have a defined size in that axis (a defined `height` or `min-height` in this case)**. In the top half of your comment 0 testcase, your `repeat(auto-fit...)` expression just expands to a single iteration, without any actual repeats. (And that is correct, per the spec, even if it's not what you expect.) This is indeed an asymmetry where things work differently in the row axis vs. the column axis -- this is due to the order in which sizes are resolved in web layout (inline sizes [typically widths] get resolved first, before the content is fully laid out; block-sizes [typically heights] get resolved last, after the layout finishes). This means that things like percentages and `auto-fit` can be resolved in the inline axis (for width & columns) in more cases than they can be resolved in the block axis (for height and rows). Here's a simple analogous example with a `50%` width and height on a div inside of a content-sized parent; the inner div's width resolves "correctly" but its height falls back to `auto` because we can't resolve it. ``` data:text/html,<!DOCTYPE html><div style="float:left; border: 1px solid black"><div style="width: 50%; height: 50%; background: orange">Does the 50-percent resolve in both axes here? ``` In the same way that this testcase can resolve a percent in one axis but not the other (because we can pre-compute the constraint size that it resolves against in only one axis): in your testcases, we can resolve `auto-fit` in one axis but not the other (because we can pre-compute the constraint size that it repeats-to-fill in only one axis). See bug 1917142 comment 5 through bug 1917142 comment 7 for more on the details here. In the meantime, unless some other browser is doing this in-the-way-that-you-expect (please let us know if so!), I think this is invalid since we [and others] are matching the spec.