- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Aug 2017 16:04:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Intrinsic Sizing of No Intrinsic Size Images`, and agreed to the following resolutions: * `RESOLVED: Replaced elements with only an intrinsic aspect ratio has a min-content size of 0 and a max-content size of 300px wide and 300*aspect-ratio height.` * `RESOLVED: In vertical WM, replaced elements with only an intrinsic aspect ratio use a 150px height and 150*aspect ratio width, instead.` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Intrinsic Sizing of No Intrinsic Size Images<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/951#issuecomment-316535854<br> <fantasai> GitHub: https://github.com/w3c/csswg-drafts/issues/951#issuecomment-316535854<br> <TabAtkins> ScribeNice: TabAtkins<br> <TabAtkins> fantasai: This issue is about a replaced element with an aspect ratio and no intrinsic size.<br> <TabAtkins> fantasai: No intrinsic width or height, just ratio. What size will it be?<br> <TabAtkins> fantasai: If you're not trying to compute intrinsic size, you use containing block width.<br> <TabAtkins> fantasai: Stretch it to that, then use aspect-ratio to find the height.<br> <TabAtkins> fantasai: But if you're shrinkwrapping around it, that's not usable.<br> <TabAtkins> fantasai: So we need some kind of size to fall back to for this case.<br> <TabAtkins> [pausing to talk to Amelia]<br> <Rossen> AmeliaBR, we'll try and connect you<br> <dbaron> AmeliaBR: message me an email address to email you the instructions<br> <Rossen> [a number of people dragging all kids of equipment around - exiting!]<br> <Rossen> AmeliaBR, we're now waiting for you<br> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> fantasai: There's a number of solution we could use, some aren't good, some are better.<br> <TabAtkins> fantasai: The ones you were listing were: first, use 0, I agree it's bad.<br> <TabAtkins> fantasai: Second is to inflate to the nearest container, but that requires doing layout, and dbaron said it's apparently insane and should not be followed.<br> <TabAtkins> fantasai: Third you listed is to use 300px as width and calculate height from the aspect ratio. I think that's the first possible option.<br> <TabAtkins> fantasai: Another option is to use the height or width of the ICB.<br> <TabAtkins> fantasai: Another is to use the nearest container with any fixed size.<br> <TabAtkins> fantasai: Another is nearest scroll container with a fixed size.<br> <TabAtkins> fantasai: We have a similar problem for writing modes, where we need to find a default size when we have an orthogonal flow.<br> <TabAtkins> fantasai: So it doesn't have an infinite inline size.<br> <TabAtkins> fantasai: We originally specified using ICB height, but it was pointed out that's not the most useful thing if you're in a smaller scrolling container.<br> <TabAtkins> fantasai: And so maybe we should use the height of the nearest scrolling container with a fixed height.<br> <TabAtkins> fantasai: We could use that same solution here.<br> <fantasai> TabAtkins: Find the nearest container options are similar to height: stretch problems<br> <fantasai> TabAtkins: So might be as bad as that, not sure<br> <fantasai> Myles_: Why not zero?<br> <fantasai> fantasai: We try to avoid dataloss by default<br> <fantasai> TabAtkins: Seems like 300px would be the easiest<br> <TabAtkins> fantasai: Scrollport seems more useful.<br> <TabAtkins> TabAtkins: WEll, minus intervening mbp, right?<br> <TabAtkins> fantasai: No, just the width/height itself.<br> <TabAtkins> TabAtkins: That'll often overflow then.<br> <TabAtkins> fantasai: Yes, but you can scroll to it.<br> <TabAtkins> Rossen: Usually.<br> <fantasai> fantasai: But you can fit the image within the viewport at least if you scroll it into place<br> <fantasai> s/viewport/scrollport/<br> <TabAtkins> AmeliaBR: Even though 300/150 is totally arbitrary, it is already being used in other cases where you don't have an aspect ratio at all.<br> <tantek> like iframes<br> <TabAtkins> fantasai: It's there because there had to be something, not because it's in any way useful.<br> <TabAtkins> AmeliaBR: Yeah, but creating different rules means increasing the number of behavior differences, where you change one thing and the result dramatically changes.<br> <Rossen> Rossen: but is going to be obstructed by scrollbars in cases of auto scrollbars depending on when the size is resolved.<br> <TabAtkins> AmeliaBR: So "stick with what we already have" has some predictability to it.<br> <TabAtkins> TabAtkins: Agree.<br> <TabAtkins> dbaron: Other thing about 300/150 means it'll show up, and if it's not what you wanted, you can change it to something else.<br> <TabAtkins> TabAtkins: As opposed to shrinking it to 0.<br> <Rossen> and this is also a very new and random behavior that is even different than height/width: stretch<br> <TabAtkins> dbaron: Yes.<br> <TabAtkins> fantasai: Yeah, 0 is the worst option.<br> <TabAtkins> Rossen: Yup, the 300px isn't great, but it's reliable and common, and if people don't like it, they can set the values explicitly.<br> <TabAtkins> Florian: And while it's not useful, it's not dangerous; it won't usually cause overflow.<br> <TabAtkins> fantasai: One thing for sure is that 0 should be min-content size.<br> <TabAtkins> fantasai: Choosing an arbitrary min-content size prevents it from shrinking below that size, but the whole point of an image without intrinsic dimesnions is that it can shrink.<br> <TabAtkins> TabAtkins: I agree with that.<br> <TabAtkins> fremy: So a float would shrink it to 0?<br> <TabAtkins> TabAtkins: Opposite - it'll be as large as possible there. Floats are *limited* to min-content below, but they try to be max-content size.<br> <TabAtkins> RESOLVED: Replaced elements with only an intrinsic aspect ratio has a min-content size of 0 and a max-content size of 300px wide and 300*aspect-ratio height.<br> <TabAtkins> AmeliaBR: Qualification is that it should be defined as inline size, not width.<br> <TabAtkins> fantasai: Images actually are always upright, they dont' respond to writing mode.<br> <TabAtkins> AmeliaBR: Like in vertical text, use 150px height, then 150*aspect ratio for width.<br> <TabAtkins> fantasai: Not sure we want to have the sizing behavior change between horizontal and vertical WM.<br> <dbaron> dbaron: Does css-writing-modes say how it revises CSS2 10.3.2 and 10.6.2? Should it?<br> <TabAtkins> astearns: I think we should keep the resolution as-is, and have test-cases for it in WM to see what the behavior actually is, if we're interoperable.<br> <TabAtkins> fantasai: WM does say how it revises those sections.<br> <TabAtkins> fantasai: Currently this case is undefined in CSS2, so that's fine.<br> <TabAtkins> fantasai: What it says about the case that is defined, is that it's analogous - you treat widths as the inline axis, etc, and translate the chapter 10 algos accordingly.<br> <TabAtkins> fantasai: But it does say that images don't rotate and their intrinsic dimensions don't rotate.<br> <TabAtkins> fremy: I checked in Edge, if you're using vertical text, we do use 150px height and 150*AR width.<br> <TabAtkins> Florian: Is it annoying to have the intrinsic dimensions depend on something like WM?<br> <TabAtkins> RESOLVED: In vertical WM, replaced elements with only an intrinsic aspect ratio use a 150px height and 150*aspect ratio width, instead.<br> <TabAtkins> Florian: I ran into these sorts of bugs with testing box-sizing/svg/aspect ratio, and browsers behave different for aspect-ratio+height vs width+height.<br> <TabAtkins> TabAtkins: Oh, that's bad. Having any 2 should be equivalent to having all 3.<br> <TabAtkins> dbaron: Did you file bugs?<br> <TabAtkins> Florian: I think I did where we had less than 2 correct cases.<br> <TabAtkins> dbaron: Is there a test suite in WPT for this?<br> <TabAtkins> Florian: Yes.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/951#issuecomment-319718680 using your GitHub account
Received on Wednesday, 2 August 2017 16:04:24 UTC