Brief   Full   Jump  


High contrast


[CSSWG] Minutes Seattle F2F 2017-01-13 Part I: Grid [css-grid]

1 message.

[CSSWG] Minutes Seattle F2F 2017-01-13 Part I: Grid [css-grid]
Dael Jackson   Mon, 13 Feb 2017 21:32:04 -0500

www-style > February 2017 > 0061.html

Received on Tuesday, 14 February 2017 02:33:40 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to:

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Grid ---- - RESOLVED: Automatic minimum is clamped by max track size not final track size. - RESOLVED: Specify that min-width: auto only resolves to the automatic minimum size if the item spans at least one track whose min track size is auto. It is otherwise zero. - Discussion on how percentages should be resolved during intrinsic size computation: - Originally there were two options listed; treating percentage track sizes as auto or resolve to 0. - Neither of these options seemed to work well/expectedly for all use cases. - The group developed six choices to select from: a. Ignore percentage and treat as auto (like block % heights) b. Back compute percentages (like tables) c. Percentages contribute zero, but resolve afterward d. Percentages contribute intrinsic size, resolve afterward during layout e. Option c unless all siblings are percentage, else option a f: Percentages contribute their minimum size (min-width), but resolve afterward - Several people thought option b would be interesting, but would take a bunch of time to solve. - Option d was generally agreed to be easiest, but may not solve all use cases and results in overflow when shrink-to-fit sizing is invoked. - In order to take a straw poll, the list was narrowed down to: 1. Ignore percentages 2. Backcompute percentages 3. Percentages contribute intrinsic size, but resolve afterward 4. #3 with a switch based on min-width - RESOLVED: Percentages contribute intrinsic size and they resolve after layout. - During the conversation dbaron raised an idea he had been thinking through: to have properties that let you assign the intrinsic sizes. This was interesting to several people and he was encouraged to write it up, but it wasn't the right solution for this specific problem. - Mats's alternate proposal for stretching images in a ratio-preserving way as well as the original options were discussed. - Options: 1) Make default sizing intrinsic (could opt into contain with keywords) 2) Make default sizing contain (could opt into intrinsic with keywords) 3) Add sizing options to alignment (Mats's proposal: - RESOLVED: We're keeping the current specified behavior as it is (no change to the default sizing, non replace get stretched, replaced gets start and add new sizing keywords to address the issues) - There was also an expressed interest in adding contain to sizing, but people needed more time to understand how it would work. ===== FULL MINUTES BELOW ====== Agenda: Present: Rachel Andrew, Invited Expert Rossen Atanassov, Microsoft David Baron, Mozilla Bert Bos (W3C) Dave Cramer, Hachette Livre Emil A Eklund, Google Elika Etemad, Invited Expert Simon Fraser, Apple David Grogan, Google Koji Ishii, Google Peter Linss, Invited Expert Myles C. Maxfield, Apple Simon Pieters, Opera Software Naina Raisinghani, Google Melanie Richards, Microsoft Hiroshi Sakakibara (BPS, Beyond Perspective Solutions) Jen Simmons, Mozilla Geoffrey Sneddon, Invited Expert Alan Stearns, Adobe Surma, Google Jet Villegas, Mozilla Greg Whitworth, Microsoft Steve Zilles, Adobe Scribe: Myles Grid ==== Implied Minimum Size of Grid Items ---------------------------------- issue: fantasai: We were waiting for approval from Rossen and Igalia. Rossen: It's a never-ending issue. fantasai: Tab and I reviewed the issue. fantasai: Percentages and intrinsic sizes deferred from last TPAC. Rossen: I'm okay with intrinsic sizes. fantasai: Resolved? Rossen: Any objections? Rossen: [reads final resolution] Rossen: Clamping of fixed track size based on max size for implied minimum (is the proposal). RESOLVED: Automatic minimum is clamped by max track size not final track size. <fantasai> Specify that min-width: auto only resolves to the automatic minimum size if the item spans at least one track whose min track size is auto. It is otherwise zero. Rossen: any objections to ^^^? RESOLVED: Specify that min-width: auto only resolves to the automatic minimum size if the item spans at least one track whose min track size is auto. It is otherwise zero. Rossen: Let's close it. fantasai: Yeah once edits are in. Percentages and intrinsic size ------------------------------ <fantasai> Rossen: In TPAC we resolved to keep percentages the same between flex and grid, however they resolved Rossen: and during intrinsic size computation. Rossen: What was left was to decide if we try to reverse the actual percentages, or do they compute to 0 (as we do for most other things). Rossen: Our position since TPAC is that they should be resolved to 0. Rossen: Talking to manuel from igalia, he agrees. Rossen: We need to reach consensus! Rossen: Any opinions? iank: Let's resolve to 0. fantasai: I thought the other option was treating percentage track sizes as auto fantasai: not resolving to 0. fantasai: I don't want to see that people will say 100% and it will overflow. Rossen: That won't be a problem. fantasai: Is it resolving to 0 always or just for intrinsic sizing? fantasai: the grid gaps definitely resolve to 0, but what about grids that have content? why should that resolve to 0? Rossen: 2 issues: percentage resolution for width of grid items, and percentage resolution for margins and paddings. Rossen: We'd compute width and height for auto always during intrinsic sized calculations for everything else in order to let the content inside measure itself. And the result is whatever the content decides so it's not 0 for width and height but for margins and paddings its 0. fantasai: That's for intrinsic sizing, but not for real layout. fantasai: Nobody wants overflow for intrinsically sized things. fantasai: It should honor the percentage always or never. fantasai: Honoring for layout but not intrinsic contribution is not author friendly but it is engine friendly. gregwhitworth: igalia says whatever we do for gaps should also be done for tracks. fantasai: Already resolved. Rossen: Let's keep them consistent. fantasai: Gaps have no content, so their intrinsic size is always 0 fantasai: For a track that has 0 content, it will work the same way. If it has content it might not be 0. fantasai: Gaps can't have content. rachelandrew: The issue is if we are using a track as a gap for some reason. fantasai: I object to a solution which results in overflow. Rossen: OK. fantasai: There are cases where we might need to deal with it for compat reasons like floats, but not here. Rossen: Inline blocks need it Rossen: as well as flexbox currently. Rossen: We have implementers who want 0, fantasai wants an objection. fantasai: Computing to 0 doesn't make any sense. fantasai: Please make a proposal. fantasai: Resolving to 0 only works for gaps. fantasai: Can we describe this option that is actually reflected in what we're talking about. jensimmons: 3 options, none compute to 0. Rossen: Preferably the spec needs to be updated. First: the percentage resolution should be done like how it was done before like in grid blocks, Second: explicitly say percentage gaps are resolved to 0 pixels when the height is undefined. Rossen: That is the last proposed behavior by manuel. dbaron: Generally I would want to do better than 0 but historically (outside of tables) Gecko is the only engine that tries to do so. fantasai: What does 0 mean? Rossen: 1. The way we compute percentages for grid items inside grid tracks, 2 the way we handle percentages for tracks, and the way we percentage for gaps. These are separate. fantasai: Gaps is easy: they are treated as empty tracks. fantasai: So solution just falls out of that. Rossen: Yes. Rossen: For tracks, if we say that percentage resolves to auto, meaning that you compute the intrinsic size, the size of the track becomes that of the collection of grid items inside of the track, then it becomes auto. Rossen: the size of the track is computed based on the grid items inside, and this is consistent with gaps, (because gaps with auto will be 0), so our previous resolution stands, and everything is ok. Rossen: I would be okay resolving that tracks and gaps will be computed as auto for these purposes. fantasai: I'm okay with it too. Rossen: Let's resolve! fantasai: I want to make sure that we aren't self-inconsistent because... Rossen: We aren't. Rossen: We were miscommunicating. fantasai: No I was talking about items. Rossen: We are in agreement about how tracks and gaps should work. Rossen: We didn't resolve on gaps and tracks resolving to auto. We resolved that they do the same thing but not about auto. jensimmons: Before we resolve about auto, can we talk though the rest of what's hard? We need to state implications. Rossen: Let's assume we have 1 track with 1 item inside- Rossen: item is 100% width and auto everywhere. Inside the item it says "hello". fantasai: That's about percentage on the item, not percentage on the track. Rossen: I'm explaining the scenario in its entirety. fantasai: We have many differet scenarios. fantasai: We need to think through use cases. fantasai: What you were just proposing to resolve is not that case. fantasai: You were talking about percentages on tracks being treated as if they are auto, which is not this case. Rossen: I was getting there. Rossen: The track has 100% as well. Rossen: The grid itself is float left. Rossen: Sooooooo, Rossen: the track is percentage, the 1 item inside is 100% width, inside the item says hello. fantasai: How about we start with the grid item doesn't have a percentage based width. Rossen: Let's say the grid item is fixed width: 100px Rossen: In this case, the track (since it's percentage, but it is asked the question how large can you be and how small you can be without breaking your content) Rossen: the track needs to answer that question. It will need to ask its content inside. = 1 item, which is 100 pixels. So the track can answer the question (100px). It doesn't have a reason to be wider than that, so the result is a track = 100px with 1 grid item which has width=100px and stuff inside. fantasai: Now! If that track was instead 50%, what happens? Rossen: So then, we would have the track would still report 100% during intrinsic size, then when layout starts (real layout) the parent, if it has 100px available, will give it 100px of space. The track will then compute its percentage, and will come out to be 50px. Then the internal item will still be 100px and it will overflow. fantasai: What is the use case for this behavior? Rossen: I don't understand the question. fantasai: Why does an author want this? jensimmons: How about when the track is 50% then it still gets 100px. Rossen: That means the grid gets 100px whitespace. fantasai: Disadvantage is that as the percentage gets smaller, its impact on the size of the container explodes. This isn't great. fantasai: Any cases that are close to 0 don't get overflow, what is what you want. fantasai: Another possible behavior: do all this stuff during layout. We say "no, your percentage is invalid so you get auto" so it lays out as 100 px because it forgot about percentage. fantasai: You say that if we ask for shrink wrapping, it overflows, which is against the idea of shrink wrapping. What is the use case for overflow here? Rossen: I don't have any use cases. fantasai: When an author gives a percentage, they want it to be honored. When they say shrink wrap they don't want overflow. fantasai: You are trying to honor the percentage by overflowing. fantasai: That isn't great. Rossen: Can ::you:: propose a way to resolve this? Rossen: It has to work with multiple percentage tracks with percentage grid items. Something that won't explode in the opposite way (b/c of used space). Rossen: If you have this, I'd be happy to review it. fantasai: I don't have an answer. but I object to always choosing overflow. Nobody has a use case for overflow. Rossen: They shouldn't have backward dependency. fantasai: But it will happen. fantasai: We should be thinking about use cases and not just what is easy for an engine. fantasai: use case = if you have an item in a track and if you have a bunch of images, each has width = 100%, and you have other content, and you want the width = 100% to take that. you won't get the good result out of your algorithm. fantasai: A different algorithm would solve that. maybe that algorithm is bad, but this one is definitely bad. fantasai: Your solution has ::no:: use cases. Rossen: I'm stating what's in the issue and what the web does today. jensimmons: fantasai, can you explain if you have a preference for how you think this should work, what it is? or what are the options that would work well? fantasai: I don't have a clear idea other than overflow is always bad. jensimmons: What is left then? fantasai: 3 options: 1) what we do with heights for blocks: if a percentage height depends on its size of its container and its container depends on the height of the items, then we use auto. And this applies to intrinsic sizing and layout. Rossen: That would work if the rule gets applied everywhere in the subtree. Rossen: This case doesn't honor percentages. fantasai: 2) my #1 priority is avoiding overflow. Honoring percentages is next. Option 2 is backcomputing percentages which has weirdness as you get close to 0. fantasai: If the author does something that makes sense that it works, but otherwise we get weirdness. fantasai: We do this for tables fantasai: but its legacy. fantasai: 3) If you are percentage size, your intrinsic size contribution is 0 (and your percentage is not resolvable). fantasai: So other children in the parent take the whole space. fantasai: Then during layout the percentage gets resolved against whatever the parent chooses. fantasai: That works for your image use case, jensimmons; but if all the items in the container are percentage-sized, it collapses to zero. jensimmons: That would freak me out. fantasai: None is ideal. fantasai: 4) we overflow. this is bad TabAtkins: Dropping to auto is best. it matches with other places, doesn't overflow, easy to explain. When I think about this stuff: the less magic that can appear, the better. I teach, so magic means difficulty. Easy to explain is good. That's what I'd like jensimmons: Things becoming 0 is mystical. jensimmons: Outer container = size unknown, inner container = percent which is unknown, I don't see a practical use case. I see it happening a lot but I don't see it as a useful that is intentional. People just find themselves in this situation. fantasai: What are examples of when people find themselves in this situation? jensimmons: If you have a container w/ percentage because you're not using grid yet jensimmons: then if you put stuff inside with grid, ....... but wait this isn't a problem. fantasai: One of the advantages of collapsing to 0 - the whole thing turns into 0 if everything is percentage sized. fantasai: Maybe we should look at other situations. fantasai: ::draws on board:: a container, with an item inside, and you want the inside item to be the size or the container, but the container is sized by another child with text inside. jensimmons: Which option makes this works? fantasai: The one where intrinsic size computation disagrees with layout calculations. iank: ::explains:: Florian: What's the downside? fantasai: ::explains:: fantasai: Another way to solve this use case, I'm happy to go with "just make everything auto" jensimmons: What happens if we take that solution? fantasai: Then you would get the container sized to the intrinsic size of the image. jensimmons: In this situation people would probably just add more percentages everywhere. fantasai: Is there a way to solve this use case anywhere else? <dbaron> I think I do have another way to solve that case... <tantek> jensimmons do you have a link to an example how people are trying to do this today without grid? Rossen: Another way is to make a hybrid: resolve to 0 always in the presence of at least one grid item with non-percent. Florian: That does not sound crazy. Rossen: So you detect when to use which algorithm. Rossen: This is an option but I don't like it. fantasai: That would be confusing in terms of the layout architecture. fantasai: We don't have the case where the intrinsic size contribution of a box is dependent on the size of its siblings. iank: Yes. Rossen: That's computable easily myles: If you add a child in script that triggers the other codepath you get wildly different results. iank: I also don't like the solution. dbaron: Another solution that would let people do various things that I've had in my head for a while that I was discussing at dinner last night is that we should probably have properties that let you assign the intrinsic sizes. dbaron: That are different than width and min-width and max-width. dbaron: These properties don't affect layout calculation, just intrinsic sizes. <dbaron> min-content-width, max-content-width, min-content-inline-size, max-content-inline-size, etc. <dbaron> (also -height, -block-size) fantasai: ::writes all the options on the board:: 1. Ignore percentage and treat as auto 2. Back compute percentages 3. Percentages contribute zero, but resolve afterward 4. Percentages contribute intrinsic size, resolve afterward during layout 5. #3 unless all siblings are percentage, else #1 dbaron: I'll probably write a proposal for my idea independently because they are valuable in their own right. Rossen: Those don't actually help here. dbaron: Actually it does work. dbaron: ::explains:: jensimmons: You need very advance authorship to get this right. Rossen: min-width and max-width can conflict Rossen: but it would be fun. Rossen: This is a powerful feature on its own. Rossen: We'll have to work out its interaction with other sizing properties. Florian: If you use these properties to make the intrinsic size of something depend on the rest of layout, that is scary. zcorpan: What if you use percentages here? dbaron: They wouldn't take percentage values. dbaron: I did think about that. Rossen: #2 "back-compute percentages" isn't numerically stable if you have multiple tracks Rossen: but if there is a proposed discrete algorithm, I'd be interested. iank: Would also change it for all layout modes. Rossen: The web currently runs on #4 (percentages contribute intrinsic size, resolve afterward). fantasai: Except for some smaller cases that do #2. jensimmons: Maybe we are leaning toward #3 (percentages contribute zero, but resolve afterward). Rossen: Why is 3 better than 4? ::general confusion:: jensimmons: This use cause will happen a lot. Rossen: Authors will always shoot themselves in the foot. dbaron: What's the difference between 1 and 4? dbaron: #1 is the only one that affects layout. Rossen: #1 is invasive and weird. fantasai: #3 overflows the same way as 4. Rossen: And is less useful than 4. Rossen: If you have something that isn't an image, it will contribute its size up to the track. So if everything happens to be 100% in your track, you have a good looking layout. Rossen: If it's 50%, you have overflowing layout which is somewhat consistent. Rossen: In #3, you end up with 0 which is bad. Rossen: I'm not proposing 3. I am proposing 4. fantasai: #5 is bad. Rossen: #5 is bad. zcorpan: Floats use which? <zcorpan> float <zcorpan> table fantasai: Mostly 4, sometimes 2. Rossen: Every implementation except for some parts of gecko give you 4. Rossen: We spent exactly 7 days in a room trying to come up with something clever with #2 but we gave up Rossen: because it's easy to break Rossen: trivially. dbaron: #2 is done reasonably interoperable for tables, and is done by gecko for margins and padding on inlines, although in a slightly odd but not-that-bad way. dbaron: If you have a float with percentage margins inside it, gecko does it. dbaron: Percentages on table cells or columns which causes back-computation. <dbaron> (that's responding to zcorpan's link) iank: But only 1 level which makes it sane. jensimmons: should we discuss examples and results? <tantek> jensimmons: yes <Rossen>,css,output <fantasai>!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20orange%3B%20width%3A%2040px%3B%20margin%3A%2025%25%22%3E <zcorpan> % padding on td Florian: Rossen, you want #4 right? Rossen: Discussing this with igalia, they want #4. I just heard iank also say he wants #4 (iank: mhm). We are also in favor of #4? Rossen: We want to move grid forward Rossen: on the rec track. Rossen: This is one of only a few issues which are left. Rossen: (pun not intended) Florian: If we do #4, how do we do jen's use case? Rossen: It works. Rossen: Nevermind. Rossen: In order to make jen's work, we need #3. Rossen: Which is a change of behavior for web compat. Florian: Can we make it work if we use dbaron's properties? zcorpan: Yes. Rossen: Yes. Rossen: intrinsic-size: 0% and you are done. zcorpan: you mean "0". Rossen: yes. Florian: Which opts you into #3. jensimmons: This requires authors to use it, but authors would bail. jensimmons: People would just put a size on the grid container instead of doing this. rachelandrew: I don't like this idea of collapsing to 0, because it's easy to accidentally do this. jensimmons: It only collapses to 0 in the browser's mind, but then the browser changes its mind. Rossen: If there's nothing in the track, it goes to 0. Florian: But if only percents in the track, 3 collapses to 0. tantek: Yep. rachelandrew: I prefer #4. Rossen: Yes. Rossen: What if we resolved??????????? Rossen: Call to action to see if people can make #2 work. But in the absence, #4 seems safest. iank: It would be a lot of fun iank: ... to try to get #2 to work, but we would have to spend a long time staring at it. In the absence of that, #4 please gregwhitworth: "call to action" = time commitment? <tantek> I think I prefer #2 for authors, and if that's not implementable (or costly), then #4 seems like a reasonably predictable alternative. fantasai: ::writing on board:: #6: percentages contribute their minimum size (min-width), but resolve afterward fantasai: and we have an "auto" keyword to min-width. fantasai: this is #4 with an opt-in to #3 fantasai: w/o adding a new property. fremy: You can't change this behavior for existing layout models. fremy: We can't change how "block" works. Rossen: And you don't solve jen's case. fantasai: You solve jensimmons case by writing img { width: 100%; min-width: 0 } Florian: You're not controlling the intrinsic size through min-width. Instead, you are choosing not to use the intrinsic size. fremy: Grid items don't stack. They are drawn on top of each other. fremy: Oh that's a column (to fantasai). zcorpan: It's confusing to have different behavior in different contexts. We should pick something that is consistent with what we already have (like 4). zcorpan: We can give tools to opt-in to other behavior (like dbaron's stuff). zcorpan: It becomes much more predictable zcorpan: ... what the behavior is. Rossen: OK. <gregwhitworth> +1 zcorpan Rossen: Let's try to resolve. iank: I agree with zcorpan. astearns: straw poll? Rossen: Let's eliminate some stuff. #1? fantasai: Yes. Rossen: #2? Florian: Is #2 possible to implement? iank: It requires research. tantek: #2 is like tables. ::general murmuring:: <dbaron> An example where Gecko back-computes percentages is: <dbaron>!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Adiv%20%7B%20background%3A%20aqua%3B%20float%3A%20left%3B%20border%3A%202px%20solid%20blue%3B%20%7D%0Aspan%20%7B%20margin-left%3A%2050%25%3B%20background%3A%20yellow%3B%20display%3Ainline-block%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%3Cspan%3EHello%3C%2Fspan%3E%3C%2Fdiv%3E <tantek> that seems to support #2 being implementable <fantasai>!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20orange%3B%20width%3A%2040px%3B%20margin%3A%2025%25%22%3E fantasai: This shows #2 behavior in block-level layout in gecko ( and nowhere else). Rossen: Authors use percentages. Rossen: If you argue for one side of percentages, i'll argue for the other side. dbaron: If your percentages add to > 100, you get strange results. <iank>!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20orange%3B%20width%3A%2040px%3B%20margin%3A%2075%25%22%3E <iank> ^explody example. Rossen: Goes through items on board, to recap. fantasai: #3 is useful for images or empty boxes, but not for things with content. Rossen: Kills #3 Rossen: 4? (gets some votes) Rossen: Kills #5 Rossen: #6? fantasai: #6 is #4 by default, but you can use min-width to opt-out toward #3. fantasai: This is useful for images. Florian: #4 and #6 are good. <dbaron> I don't like adding even more behavior to min-width (#6). Options: 1. Ignore percentages 2. Backcompute percentages 3. Percentages contribute intrinsic size, but resolve afterward 4. #3 with a switch based on min-width <dbaron> #4 renumbered to #3, #6 renumbered to #4 Florian: How realistic is dbaron's proposal? dbaron: Pretty realistic because implementations already have the concept. dbaron: My thing makes #4 kind of silly because I don't want to add yet-more behavior to min-width dbaron: if you set min-width, you get all of these different things with #4. rachelandrew: I'd rather have a new property than doe something new with min-width. <tantek> agree with rachelandrew, rather not overload min-width zcorpan: I want to be consistent with floats. Floats do different things in different implementations. Spec is not clear. fantasai: It's undefined. Rossen: Almost everywhere floats do new #3. fantasai: There is no spec. Rossen: At some point we tried to agree but dbaron said he would try to find the algorithm and define it and we didn't finish. dbaron: When you say "floats are different" do you mean stuff inside floats or anything else that uses intrinsic sizing? zcorpan: I mean the last 2 cases that were in IRC. Florian: Those are just for shrink-wrapping. dbaron: There was nothing specific to shrink-wrapping in those example. I just wanted shrink-wrapping. zcorpan: We should use the same behavior as shrink wrapping today. dbaron: Grids have more complicated structure. fantasai: If you do this with margins and paddings, and put the percentage on the width, then it would overflow, because the contents of floats that are percentage sized need to not .... [trails off] fantasai: Gecko was able to get things to not overflow for compat for margins and padding, but not for width. fantasai: We are looking at 3 different things, track, the grid item itself, and the grid. Rossen: Nobody ever said that tracks should follow #1 fantasai: But that was your first proposal!!! fantasai: Flexbox does it too. Rossen: Not quite. fantasai: The difference between Flexbox and #2 is you can't go over 100% because it's impossible. but! The flexing in flexbox and the flexing in grid does #2. fantasai: We use the ratios, and then backcompute how big the thing has to be. Rossen: Not overflowing is nice. iank: Can we rule-out 2 iank: because implementors aren't sure it's possible. iank: Rossen stared at it for 7 days trying to get it to work, we aren't sure if it would work Florian: It would be bad if we ended up in the same situation as today with some browsers doing it one way and other browsers doing it another way Florian: unless everyone says they can do #2, we shouldn't consider it. Rossen: Let's straw poll Rossen: Does everyone understand the issue enough? <dbaron> Honestly, I don't think I understand the issue enough... Straw Poll: <Florian> 3, 4 <iank> 3 <TabAtkins> 1,3 <philipwalton> 3 <gregwhitworth> 3 <astearns> abstain <zcorpan> 3,2 <surma> 3 <rachelandrew> 3 <myles> abstain <jensimmons> abstain <dauwhe> abstain <Bert> abstain (I understand what they do, but can't say which is better...) <fremy> 3,2,1 <Rossen> 3 <gsnedders> 3, 2, 4, 1 <fantasai> copy Bert <dbaron> I'm definitely against 1 and 4, but I don't actually understand what we're talking about well enough to choose between 2 and 3. <melanierichards> ^ same <tantek> mild pref for 2 (like tables), but similar to dbaron, insufficient evidence to be sure 3 is not better <jensimmons> (I'd need to go through common use cases to understand how it impacts authors to be able to vote) dbaron: I understand the behaviors, but not what we're applying them to. Rossen: We are applying them to grid items Rossen: and also grid tracks. (laughter) fantasai: Actually let's do everything fantasai: for consistency. Rossen: We agree gaps and tracks behave the same. Rossen: Consensus is #3. RESOLVED: "Percentages contribute intrinsic size and they resolve after layout" Stretching images in a ratio-preserving way ------------------------------------------- Rossen: 1 more issue: <Rossen> <fantasai> fantasai: Mats's main objection is we have a solution for how to put (ratio-preserving) an image in a grid area if its bigger than the cell in its intrinsic size but not if its smaller. fantasai: Our previous resolution is good because I don't want to put more sizing behavior in the alignment properties. fantasai: The proposal is to add more keywords to do sizing in alignment, which I definitely don't agree with, fantasai: but the problem is valid fantasai: but the way forward is not to revert the resolution. astearns: Can we keep the resolution and perhaps work on this later? Rossen: Why not now? Rossen: We are here. Rossen: People are waiting for this. jensimmons: I don't think we want to change after we ship. Rossen: We've beaten this issue down so much .... fantasai: I'm happy with our resolution because it preserve the behavior of alignment of limiting its sizing controls to just stretch fantasai: we cut ourself off. Rossen: Agreed. fantasai: As far as the grid spec is concerned, we don't do anything else here fantasai: but we do have an issue against sizing where we need to figure this out. Rossen: Sizing or alignment? fantasai: Sizing. fantasai: Alignment is placement, sizing is ... sizing. fantasai: Question is: how do we take the constraints of the box and find the size of the thing that fits in the box. fremy: So that means that the solution is in dbaron's new proposal. Florian: With dbaron's thing it works. Florian: You say "my intrinsic size is very large". fantasai: You will get unexpected side-effects. Rossen: Let's try to solve the issue with the tools we currently have. dbaron: I'm confused with the issue. dbaron: Sounds like Mats agrees with what we resolved, and fantasai sounds like she agrees with what we resolved, but you're disagreeing. astearns: In his response to the announcement, Mats disagrees with "image grid items should not stretch at all by default" <astearns> Mats's response to the minuted resolution: fantasai: Mats wants contain behavior as the default for images. fantasai: I'm opposed to that because that's a sizing behavior you can't get with alignment. dbaron: He wants contain behavior for images which are grid items. fantasai: Might be reasonable except that alignment changes that behavior, so you can't do both. <jet> [Mats's comment: My counter-proposal is that images should stretch by default (as all grid items do) but in a ratio-preserving way (as is expected for images in general), and that we solve the remaining issue with how to align it in the non-filled axis by adding some minor additions to CSS Align.] Florian: If we solve it in sizing, that doesn't work. Florian: To solve it in sizing, we have to keep the behavior we resolved on, not the one he's asking for. fantasai: Right now if you have several sets of alignment values which have different behaviors.... normal is the initial value, then we have stretch and start, center, end. fantasai: start/center/end trigger shrink-wrap, fantasai: stretch means I'm the same size as my grid item always, fantasai: normal should be the same as stretch or start/center/ end, not a 3rd behavior, fantasai: required to do alignment for alignment and not also do sizing. fantasai: So the default behavior (and start/center/end) gets contain, or we take what we already resolved on. fantasai: I don't have a strong opinion. fantasai: I just don't want sizing keywords in alignment. TabAtkins: Yes. Rossen: Yes. fantasai: 2 options: 1) No change to default grid sizing; fantasai: non-replaced elements map to "stretch" and replaced elements map to "start" and this is intrinsic size. fantasai: and add new keywords to width and height for contain <dbaron> Do you get the contain behavior if you specify a very large width and also max-width: 100%; max-height: 100% ? fantasai: 2) make default sizing contain fantasai: This means non-replaced stretch (we don't want to change this default behavior) and replaced items still map to "start" but "start" isn't the same as intrinsic size, it's equivalent to "contain". and use keywords in "width" to get intrinsic size. fantasai: I'm okay with either of these, but nothing that isn't these. dbaron: So what's the difference between these and the proposal? fantasai: The current working group resolution is #1. fantasai: In the issue, the proposal is to add new capability of alignment to have it control sizing. fantasai: 3) Add sizing options to alignment [Mats's proposal] fantasai: .... and change default behavior to new keyword. tantek: It sounds like we're focusing on new keywords, but Mats's focus is on more author-friendly default behavior. Florian: But the mechanism he achieves that is the thing that fantasai objects to. gregwhitworth: Even if you do that, you end up with a result which isn't that author-friendly. gregwhitworth: ::repeat an existing argument from the issue:: ( Mats's comment on Dec 1) gregwhitworth: #1 is fine, and we can add new sizing keywords if object-fit isn't sufficient. fantasai: object-fit isn't sufficient. (draws picture to show why) fantasai: Because there is a distinction between CSS box vs replaced content boxes. fantasai: I'm okay with #2 and that would make Mats happy. jensimmons: What if we add new keywords to width and height to contain? what does it look like to authors? jensimmons: Like "width: contain;"??? jensimmons: Does this work everywhere? fantasai: yeeeaaahhhhhhh.... fantasai: Probably would do a functional notation. jensimmons: Could be useful. dbaron: Doesn't necessarily apply everywhere. dbaron: Can sort of do it today by "max-width: fill-available, max-height: fill-available, width (or eight but ot both): really-big-number" dbaron: Maybe we should have a value that is "big". Rossen: What if we continue thinking about this over a break. <break> Scribe: fremy fantasai: There are 3 desirable behaviors for images: fantasai: Stretch, shrink to fit, contain. fantasai: Mats would like contain by default for images fantasai: it seems useful to have keywords to control fantasai: but the default is another question. Rossen: Lets decide on default. fantasai: Mats wanted contain by default, but we only do this by constraining to allow smaller size right now. TabAtkins: If we just go with number 1, and don't add anything new, everything works except small images TabAtkins: and even for small upscaled images there are workarounds, if you know roughly your aspect ratio. jensimmons: But by default a big image would overflow. TabAtkins: Yes, but you can specify max-width: 100% like any other place in css. fantasai: But I think the agreement is that we don't need any new alignment. gregwhitworth: (clarification between object-fit cover and contain behaviors) fantasai: Blowing up and pixellating small images isn't great. fantasai: In block layout, if you don't do anything, the image uses its intrinsic size, you also need to specify max-width [in response to jensimmons question which was missed] jensimmons: I think grid is different, we should not care about matching block. Rossen: No, I don't think. zcorpan: And I would agree that anything but option 1 would be unpredictable. Rossen: Agree with option 1 too. fantasai: +1 fantasai: To allow Matt's preferred behavior we would add a "contain" value to width and height in css-sizing. fantasai: It works as existing content filling value for things that have no aspect ratio fantasai: but for things that have one, you would choose the best size to match min(CB width, max-width) x min(CB height, max-height). dbaron: Can't you just drop the max-width/max-height part here and let the normal rules do that? Rossen: And for intrinsic sizing? Rossen: A proposal would be add contain as an optional keyword for width. fantasai: Not clear to me what that means. Rossen: Okay, let's answer the intrinsic sizing question then. fantasai: There are several options: fantasai: 1 use the intrinsic size as we had specified max-content. fantasai: 2 treat as 0. fantasai: 3 use the calculation. dbaron: Then you don't have CB width/height yet. fantasai: Then you fallback. dbaron: Doesn't work. Rossen: Proposal would be to behave as auto. <dbaron> I think 0 is fine fantasai: Or fallback to icb width. Rossen: But then you blow up to viewport size, doesn't seem useful. fantasai: Agree. fantasai: But what does fill-available do? dbaron: It behaves like auto. fantasai: Then I would match. dbaron: I am not sure I'd want it like 'auto' [?]. TabAtkins: I would agree with that "auto" option. Rossen: So I think we have a few questions to answer but a clear way forward Rossen: but we could resolve on getting grid behave like everything else. jensimmons: So if we don't do 2 we have to use workarounds to get the contain behavior on small images. fantasai: Yes (explains workaround). Scribe: gregwhitworth jensimmons: Does it matter if I apply height and width contain? fantasai: Yes you have to apply both to get the effect. fantasai: If you apply both you figure out what they are and assign that to the width property. Rossen: I don't see how this is aspect ratio preserving. fantasai: Contain means aspect ratio preserving. fantasai: You use the contain algorithm from object fit to preserve. Rossen: Oh that's what I was missing. jensimmons: If I'm in grid and that the grid has an explicit height and the items say width contain and height contain does it do anything? jensimmons: So in some situations it will do something others it won't. jensimmons: This is going to be incredibly useful. fantasai: If the whole goal is to preserve aspect ratio maybe we should do it as much as possible. jensimmons: This will be my new favorite property. Rossen: Let's go back to try and resolve this issue. Rossen: Let's ask for 1. jensimmons: I'm the only one asking for 2, and I'm not going to object. Rossen: Okay, any objections to resolve on option number #1: no change to the default sizing, non replace get stretched, replaced gets start and add new sizing keywords to address the issues. jet: I think our feelings on two or one depend on the sizing discussion. fantasai: So do we want to do a resolution fantasai: that says we need to add contain? RESOLVED: We're keeping the current specified behavior as it is. fantasai: If there is consensus to add contain on principle then maybe we should add it. Rossen: In order to do that I need to understand better how contain works Rossen: and that's a discussion that needs to happen on its own.<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 13px;"><a href="" target="_blank"><img src="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="" target="_blank" style="color: #4453ea;"></a> </td> </tr> </table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>