[css-sizing] Nobody follows the spec about cyclic percentages in preferred&max sizing properties of replaced element #11452
Labels
css-sizing-3
Current Work
Comments
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> oriol: When calculating intrinsic contributions, percentages are cyclic. Spec says what to do.<fantasai> oriol: In preferred and max properties, they typically behave as initial value of the property <fantasai> oriol: But spec says if element is replaced, for min-content contribution only, you resolve the cyclic percentages against zero <fantasai> oriol: It doesn't say treat everything as zero, just resolve percentages as zero <fantasai> oriol: so calc(length + percentage) would still have the lenght <fantasai> oriol: but nobody implements this <fantasai> oriol: Treating as zero instead <fantasai> oriol: This avoids some minor problems, e.g. it's possible given spec that the min-content contribution would be larger than when properly resolved <TabAtkins> Yeah, unless there's a compat restriction, treating `calc(100px + 0%)` as 0 is a ton of nonsense, that's what we were trying to avoid. :( <fantasai> oriol: Given everyone treats as zero, probably should spec that <astearns> ack fantasai <fantasai> fantasai: Intention of spec was to preserve the author-specified minimum as much as we could <fantasai> fantasai: e.g. if they wanted min-width: calc(10px + 5%) <fantasai> fantasai: we'd give them the 10px, which is what they'd get in a zero-sized container <fantasai> fantasai: I don't know if it's Web-compatible, but if it is, I'd prefer to follow the spec. <fantasai> oriol: Would prefer to match spec to reality, unless people are willing to change. <TabAtkins> fantasai: Ian, what od you think the web-compat is likely on this one? <TabAtkins> fantasai: because i think the spec behavior is better <fantasai> iank_: Not really sure what Web-compat would be. Would be pretty straightforward to query how often calc() appears inside a min-width/height <fantasai> iank_: though wouldn't know how often we're depending on the intrinsic size there <fantasai> emilio: what about min greater than max... need to compute both <fantasai> emilio: and do extra work <fantasai> emilio: Suppose you're in this case where min is bigger than max, spec says we clamp it <fantasai> emilio: then we also need to compute the max <fantasai> fantasai: min trumps max, so... why? <fantasai> emilio: if you set min-width: max-content; and width: min-content; ... <fantasai> emilio: that doesn't make sense <fantasai> emilio: As long as we don't change what clamps what it's fine <fantasai> emilio: does the spec define that? <fantasai> iank_: falls out <fantasai> iank_: only really important for content contributions, not for min-content/max-content values <fantasai> emilio: would be nice if max-content didn't give me a value smaller than min-content <fantasai> iank_: max-content on an element itself isn't using min-width, it's only for the content contribution <fantasai> emilio: you have 2 identical elements, and say you hit this case <fantasai> emilio: style one with width: max-content; and one with width: min-content; <fantasai> emilio: ... <fantasai> emilio: maybe it's not an issue <fantasai> oriol: For example CSS Grid etc. assume min-content is smaller than max-content <fantasai> oriol: but I wrote a testcase where min-content contribution is 100px and max-content contribution is 50px <fantasai> oriol: you could get a smaller sized [missed] <fantasai> oriol: which seems weird <fantasai> emilio: unfortunate... maybe ok if it already happens <fantasai> iank_: It's possible, so we have to clamp them all the time. E.g. happens with negative margins. <fantasai> iank_: we have to clamp max-content by min-content already <fantasai> astearns: I think I'm hearing we're not that interested in speccing reality in this case, prefer trying to get implementations to match the spec. Anyone willing to volunteer to experiment with this? <fantasai> emilio: I do have a slight preference to spec reality, but not opposed to trying this out <fantasai> emilio: also don't think I'll have time in the short term <fantasai> iank_: I would also prefer to spec reality, but we could try to do it. Not that difficult for us to do this change. <fantasai> iank_: could see what fallout there is <TabAtkins> fantasai: My feeling from authoring perspective is it makes a bit more sense if we can do it as specced <TabAtkins> fantasai: so that's where i'm at <fantasai> astearns: That's where I'm at, too. <fantasai> astearns: we could leave this issue open, invite experimentation, and come back to it in some number of months and see if anyone had a chance to try implementing the spec <fantasai> fantasai: that seems reasonable <fantasai> astearns: Does that work for you oriol? <fantasai> oriol: That's fine, just having a spec that doesn't reflect reality... <fantasai> oriol: especially following one, we in servo implemented the spec, and then realized we're not doing the same as other browsers <fantasai> oriol: not great for new browsers <fantasai> astearns: so you had done some experiments! Did you notice the difference? Inform compat? <fantasai> oriol: Maybe I should have merged the two issues... <fantasai> oriol: This one is for replaced elements, we did what other browsers do <fantasai> oriol: The next issue is about min size property for all elements <fantasai> oriol: we implemented the spec, and we are failing some WPT tests because these tests are expecting the browsers behavior and not the spec <fantasai> astearns: test failures are one thing, because tests can have mistakes <fantasai> astearns: those test failures, have you seen what difference it would make from authoring perspective? <fantasai> oriol: I don't recall much <fantasai> oriol: not many tests, maybe 2 tests <fantasai> oriol: I think it wasn't very important <fantasai> oriol: but Servo is very experimental, can't use to browse real websites, so can't inform about web-compat <fantasai> oriol: In the other issue I linked some tests <fantasai> astearns: Let's table this issue for now see if we can have implementations follow the spec <fantasai> astearns: because I do agree from author perspective it is better to preserve at least some of the intent <fantasai> astearns: Should we do the same for the next issue? <fantasai> oriol: yes, it can be the same <fantasai> astearns: OK, for these we will see if we can get implementations to match and revisit <fantasai> RESOLVED: See if implementations can match the spec and revisit issue later. |
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Mar 17, 2025
Attempt to ship: w3c/csswg-drafts#11452 Basically for min-lengths, coerce the %-size to zero when indefinite. Behind the flag: LayoutMinSizeIndefinite Bug: 397674426 Change-Id: I1806f2e3f47ba5759e930b734278f1c1a7360295 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6318731 Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: David Grogan <dgrogan@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1433719}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://drafts.csswg.org/css-sizing-3/#replaced-percentage-min-contribution
For starters, this needs to then floor the max-content contribution by that amount, otherwise the min-content contribution could be larger:
100px + 0px = 100px50pxBut browsers don't have this problem, because they do not resolve percentages against zero. Instead, they treat the min-content contribution as zero:
This is in fact analogous to #10969
The text was updated successfully, but these errors were encountered: