W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-grid] Replaced elements canvas, img, etc should behave as expected when styled with relative sizes in grid, transferred size should not affect them unless specifically asked to (#6278)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Aug 2021 16:49:53 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-896986632-1628700591-sysbot+gh@w3.org>
The CSS Working Group just discussed `replaced elements percentage-sized within rows`, and agreed to the following:

* `RESOLVED: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: replaced elements percentage-sized within rows<br>
&lt;fantasai> s/rows/grid areas/<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6278<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6278<br>
&lt;fantasai> iank_: There's concept of compressible elements, if you put a percentage width in one axis, it will compress to min-size<br>
&lt;fantasai> iank_: Chrome did a bunch of fixes in this area (replaced elements) recently<br>
&lt;fantasai> iank_: that brought our behavior more inline with the spec here<br>
&lt;fantasai> iank_: which applied an automatic minimum size in this case<br>
&lt;fantasai> iank_: web author found this really surprising behavior, filed issue<br>
&lt;fantasai> iank_: Question is do we want to ...?<br>
&lt;Rossen_> q<br>
&lt;fantasai> iank_: Firefox behaves as expected, because there is some behavior around transferred sizes that they still don't do correctly.<br>
&lt;florian> s/.../follow the spec, and if not, how do we match the author's expectation/<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/6278#issuecomment-863439988<br>
&lt;florian> fantasai: tab and I looked over this<br>
&lt;florian> fantasai: our conclusion is summarized in the issue<br>
&lt;florian> fantasai: the author's expectation is reasonable in this case<br>
&lt;florian> fantasai: chrome and firefox used to match that, until chrome fixed to match the spec<br>
&lt;florian> fantasai: [explains example]<br>
&lt;fantasai> [ fantasai insert summary later]<br>
&lt;Rossen_> 1fr has an auto min implied and that's what's causing the breakage.<br>
&lt;Rossen_> fantasai: the auto min size is supposed to be xtronger constraint of specified height... and that's what's happening because the % isn't taking affect<br>
&lt;fantasai> s/xtronger/weaker/<br>
&lt;Rossen_> fantasai: the sln we are interested in is to make % resolve against min definite height. resolving against 0 is to clamp the min size. do it for compatible elements and potentionally all els<br>
&lt;Rossen_> fantasai: does that makes sense?<br>
&lt;Rossen_> iank_: I did :)<br>
&lt;TabAtkins> Summary: During Grid layout, we first lay out to figure out row heights, then lay out given that height to figure out column widths (then maybe do both of those again). A 1fr item size has an automatic minimum; during the first layout both dimensions are unknown so the auto-min doesn't trigger, but in the second layout there is a height so it *does* trigger, and this ends up giving us the bad behavior where the height is frozen as "large"<br>
&lt;fantasai> s/does that makes sense/did everyone follow, or should I explain something again<br>
&lt;fantasai> iank_: I'd be concerned about doing this for all elements<br>
&lt;fantasai> iank_: if we do, should only do for compressible elements<br>
&lt;TabAtkins> But our intention was always that auto-min be a relatively weak constraint - it shouldn't be taken as gospel in the middle of this algo and have this effect.<br>
&lt;fantasai> Rossen_: what's downside to doing it for all elements?<br>
&lt;fantasai> iank_: Currently, if you've got a non-replaced element with width:100%<br>
&lt;fantasai> iank_: that would change behavior pretty drastically<br>
&lt;fantasai> fantasai: what if we only clamp the transferred size<br>
&lt;TabAtkins> (because of the ordering of row vs height resolution, this behavior doesn't have a bad effect when the space is tall; it only makes the element too-large when the space is wide, which is an annoying discontinuity)<br>
&lt;fantasai> iank_: so only things with aspect ratio ...<br>
&lt;fantasai> iank_: would need to think about that a bit more<br>
&lt;fantasai> Rossen_: can add aspect-ratio to anything, now, right?<br>
&lt;fantasai> fantasai: 2 inputs into auto min size: content size in that axis, and for items with aspect ratio (previously only replaced elements), size trasferred<br>
&lt;fantasai> fantasai: suggestion would be to make transferred size weaker than percentage size<br>
&lt;fantasai> iank_: there's a difference between spec and implementations atm with this stuff<br>
&lt;fantasai> iank_: spec says to resolve lengths against zero, whereas implementations will actually ignore that length<br>
&lt;fantasai> iank_: ignoring that difference, your suggestion and mine are effectively equivalent<br>
&lt;fantasai> fantasai: no, yours was to do it to it for compressible elements<br>
&lt;emilio> fantasai: no, because you are saying to do it only for compressible elements and I'm suggesting to do it for all elements with a-r<br>
&lt;emilio> iank_: if I change my suggestion then it agrees right?<br>
&lt;emilio> fantasai: [missed]. It'd be more consitent if we only clamp the transferred size. If we do clamp AMS if you have an aspect-ratio then it changes behavior<br>
&lt;emilio> iank_: if a replaced element has an intrinsic size I don't think that we'll want to respect that in this case<br>
&lt;emilio> ... if you have width 100%<br>
&lt;emilio> ... that'd break the person's initial issue, the intrinsic size was actually quite large<br>
&lt;emilio> fantasai: in that case I wonder if that should depend on whether they're compressible. Clamp transferred size always, clamp content-based size if it's compressible<br>
&lt;emilio> iank_: why not do it for both then?<br>
&lt;emilio> fantasai: mainly because it means that aspect-ratio affects sizing in an axis where it'd otherwise not have any effect<br>
&lt;emilio> ... I don't have an objection but it's a bit weird<br>
&lt;Rossen_> q?<br>
&lt;emilio> ... if you apply an aspect-ratio to a div where we apply the content size, then it'd clamp to zero<br>
&lt;fantasai> s/clamp/suddenly clamp/<br>
&lt;emilio> Rossen_: can we go back to the previous proposal, to make it apply to all elements?<br>
&lt;emilio> ... we can try to constrain later if we have strong reasons to<br>
&lt;emilio> fantasai: I think we may have problems if we try to apply to all elements<br>
&lt;emilio> Rossen_: this is something we should be able to figure out quite quickly<br>
&lt;emilio> iank_: I think we can do the change for compressible and a-r elements quite easily. I need to think about non-replaced elements with a-r inside an auto-sized thing, dunno how to implement that yet<br>
&lt;TabAtkins> ian, let's do a video chat about this soon<br>
&lt;emilio> Rossen_: so, let's start with compressible, would that work?<br>
&lt;iank_> sure<br>
&lt;emilio> fantasai: I think my preferred suggestion would be all elements, but if we can't we should do it for compressible elements, do it for transferred and content size, and for a-r elements just the transferred size<br>
&lt;emilio> Rossen_: not opposed, but it's weird to make special elements more and more special, specially if the behavior is useful for all elements<br>
&lt;emilio> ... so I'd prefer to pursue that if possible<br>
&lt;tantek> +1 agreed with Rossen_<br>
&lt;tantek> and with that methodology in general<br>
&lt;emilio> fantasai: I'm fine with all elements, but if not I prefer the suggestion above, I think it's the closest<br>
&lt;emilio> Rossen_: can we resolve on all elements and if you come back with strong reasons why it doesn't work we can consider the other suggestion<br>
&lt;emilio> iank_: when we say all elements we mean all elements with a-r?<br>
&lt;emilio> fantasai: we meant all elements<br>
&lt;fantasai> s/fantasai/rossen/<br>
&lt;emilio> iank_: That's a very big change, I don't think that'd be ok<br>
&lt;emilio> fantasai: I'm also skeptical about that<br>
&lt;emilio> Rossen_: so should we resolve on compressible elements + a-r?<br>
&lt;emilio> fantasai: [explains her suggestion again]<br>
&lt;emilio> Rossen_: sounds reasonable, other comments / objections?<br>
&lt;Rossen_> s/a-r/aspect-ratio/<br>
&lt;fantasai> proposal: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements<br>
&lt;tantek> sounds reasonable to limit to those elements<br>
&lt;fantasai> RESOLVED: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements<br>
&lt;fantasai> fantasai: Thanks everyone. That was a complicated issue, and I understood it better by talking it through with all of you.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6278#issuecomment-896986632 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 August 2021 16:49:55 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:42 UTC