- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 May 2018 23:30:52 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Percentages gaps and intrinsic size`, and agreed to the following resolutions: * `RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Percentages gaps and intrinsic size<br> <fantasai> s/contribute to fr resolution/contribute to fr track minimums/<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/509<br> <rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-381759138<br> <dael> Rossen_: Let me paste the time stamp instead of the whole issue<br> <dael> Rossen_: rego has it<br> <dael> rego: I reopened it.<br> <dael> rego: All browsers now support % in column gap in multi column<br> <dael> rego: All of them are interop. But they're not following new text in spec. Chrome and webkit we don't see an easy way to follow for width so I suggest we change the text to says something like % resolves to 0 when resolved against the base size. Something like the indefinite size is what we should say because the logical width is not indefinite.<br> <dael> rego: That causes overflow in some cases but I don't think there's a way to do it better and changing spec text would make it match impl.<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-356256873<br> <dael> fantasai: If we go back to the options before there was option b which was contribute 0 resolve as 0. Igalia is saying we don't know when to resolve if it's at 0 or not because that info isn't part of what's given to grid when it's doing layout.<br> <dael> fantasai: It's easier for impl if they just continue tracking or continue tracking into the container and therefore the percent resolves.<br> <fantasai> s/or continue tracking into the container/continue tracking just the information they have already, i.e. the size of the container/<br> <dael> Rossen_: I can't speak to other impl, in our grid impl we know if we're doing layout for sizing and measuing the content vs sizing when we're not shrink to fit. From that PoV I don't think we have anything in the spec that prevents a impl from passing this info<br> <dael> Rossen_: Looking at current interop around this....based on the codepen from the issue seemed like we all agree on behavior of grid.<br> <fantasai> s/that info/information on whether the current size of the container was a content-based size/<br> <dael> Rossen_: rego what I hear is once we go down...if we change resolution from b to d, contribute 0 resolve as 0, we minimize amount of potential overflow, but also drop ability to have % column gaps. Last time we discussed the one constant feedback from webdev was they don't want to drop the gap. It's more intutive if you see overflow and go and fix it rather then add values and have no effect.<br> <dael> Rossen_: I'm not sure we're driving toward an ergonomic.<br> <dael> fantasai: Previous resolution was b and we're proposing switch to d.<br> <dael> Rossen_: In that case I agree and misunderstood the proposal.<br> <fantasai> s/ergonomic/ergonomic solution/<br> <dael> rego: It would be more like f.<br> <dael> rego: It would be like when grid resolves % for width and height in regular blocks they're different so same here.<br> <dael> Rossen_: Okay, I'm with you.<br> <dael> Rossen_: Other opinions on this?<br> <dael> fantasai: Proposal is to resolved the % in column gaps but not row gaps?<br> <dael> s/resolved/resolve<br> <dael> rego: Yes. To resolve the % when the size is definite, but not when indefinite. width is only indefinite for intrinsic sizes.<br> <dael> fantasai: That gets to the point where we wanted symmetry and we don't have that.<br> <dael> Rossen_: Same concern. Only thing that is symmetric is we're talking definite vs indefinite instead of width and height. I wasn't going to object hard, but I'm with fantasai that we want to keep as symmetric as possible. Just because of how flow layout works today more often then not width wiill be definite and height indefinite or vice versa.<br> <dael> rego: There is the other issue about how % tracks work where they should be symmetric and resolve always. So maybe that's an option here. But no one is supporting the heights for % rows yet. Maybe that's the way to go.<br> <dael> Rossen_: This is option f?<br> <dael> rego: Option b I guess.<br> <rego> https://github.com/w3c/csswg-drafts/issues/1921<br> <dael> rego: Following what we resolved in issue #1921. It's not impl, but we resolved that way in the past.<br> <dael> Rossen_: Going through 1921 resolution it makes sense, but impl have to catch up. Once we do we'll have symmetric behavior. Then we need to do same thing for gaps. That would be behavior b.<br> <dael> rego: For multi column it's what we're doing right now. We're always resolving the % because multi col only has column gap.<br> <dael> Rossen_: Right but for grid it's both column and row.<br> <dael> dbaron: I'm not an expert on grid, but I felt like I liked the original proposal from rego a bit more. There's a lot of stuff where width and height just doesn't work the same way. Things that happen in intrinsic width pass shouldn't effect layout pass.<br> <dael> Rossen_: I wouldn't disagree in general, but I would slightly disagree in teh case of grid because we've been trying for as symmetric as possible. We had a fully symmetric implementation and that fell through. It will require more passes to make symmetry stable, but it's possible.<br> <dael> Rossen_: Let's try and move forward.<br> <dael> Rossen_: Proposal in the issue was we resolve to have a contribute 0 and resolve as percentage<br> <dael> Rossen_: Correct?<br> <dael> rego: That's not what's in the issue, but yeah. That's the new proposal to keep symmetric behavior following the tracks resolution.<br> <dael> Rossen_: Which is option B.<br> <dael> Rossen_: Any opinions or objections?<br> <dael> RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/509#issuecomment-386152310 using your GitHub account
Received on Wednesday, 2 May 2018 23:30:56 UTC