W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2017

Re: [csswg-drafts] [css-grid] Percentages and intrinsic size

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Oct 2017 16:57:12 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-337657112-1508345831-sysbot+gh@w3.org>
The Working Group just discussed `Percentages and intrinsic size`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Percentages and intrinsic size<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/509<br>
&lt;tantek> ready for CSS3-UI PR?<br>
&lt;dael> florian: Briefly on previous, but that prob takes us to a passing test suite and we can begin to move toward rec<br>
&lt;tantek> SGTM<br>
&lt;dael> Rossen: fantasai summary?<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551<br>
&lt;dael> fantasai: There is...the never ending topic keeps branching into variations. The current variation has 2 issues. First is that the resolution we took on % sizing, we made edits that are symmetrical for block and inline axis. Igalia guys said we impl asymmetric. So that's an issue of do we want to change for symmetric.<br>
&lt;dael> fantasai: Summary comment ^<br>
&lt;dael> fantasai: Basically, I think we resolved this is correc tbehavior, but if someone thinks different we should discuss.<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096<br>
&lt;dael> fantasai: Second is what do we do with % gaps. All options ^<br>
&lt;rego> related to first issue, this comment is also important: https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334437618<br>
&lt;dael> fantasai: C and E are terrible. F is impl by chrome. B and D are the ones we're combining. Gecko does A.<br>
&lt;dael> fantasai: I don't have a strong opinion, but we should think carefully. We havea  mix of impl and we need impl, spec, and authors to agree on best option.<br>
&lt;fantasai> s/we're/they're/<br>
&lt;dael> rego: Regarding first issue, I think the change to make symmetric for columns and rows is contrary to rest of impl. We've been checking options and if we do it we have to do extra passes. We'd like to check if other impl will do that or if we should revert status.<br>
&lt;dael> fantasai: Another pass for track sizing algo, or jsut through the items?<br>
&lt;dael> rego: We believe it needs another pass of the algo.  We were finding some strange issues to resolve that.<br>
&lt;dael> Rossen: Are you talking about the % resolution of gaps?<br>
&lt;dael> rego: Tracks<br>
&lt;dael> Rossen: Okay.<br>
&lt;dael> Rossen: And there's no interop?<br>
&lt;dael> rego: There is interop, but it's contrary to what the resolution says.<br>
&lt;dael> fantasai: It's an intrinisically sized grid with a % size grid track. Does that % resolve. It does with columns, not with rows. Spec says resolve in both axises.<br>
&lt;dael> TabAtkins: Current is similar to how block works.<br>
&lt;rego> the spec text is:<br>
&lt;rego> > then the must be treated as auto, for the purpose of calculating the intrinsic sizes of the grid container and then resolve against that resulting grid container size for the purpose of laying out the grid and its items.<br>
&lt;dael> Rossen: But block has  nothing to do with grid. We shouldn't define one layout system with a completely different. The original desire to keep things symmetric in grid was based on how a good system should work. it's up to us to decline from that model, that's fine if this is what everyone agrees we should do. but let's not justify current with what we internded.<br>
&lt;dael> TabAtkins: Sure. We're just saying block behavior wasn't an accident. It was reasonable to avoid extra layout in common cases. Might not be right for grid, but there was good reason behind our choice to copy it over.<br>
&lt;dael> Rossen: Trying for progress. Current proposal is to back out on our original resolution from Seattle and go with the asymmetric one.<br>
&lt;dael> TabAtkins: Intention isn't to get a resolution this week, it's to bring it up for talk later.<br>
&lt;dael> Rossen: If you're not asking for a resolution, let's keep working on it. We should resolve on this during F2F at the latest.<br>
&lt;dael> fantasai: agree<br>
&lt;rego> this was the change from the resolution: https://github.com/w3c/csswg-drafts/commit/15cf0c6d56efdbb44383134ebe19dff672b01546<br>
&lt;dael> Rossen: We should put a time limit on this. We'll have to get consensus.<br>
&lt;tantek> It does feel like an issue that would benefit from seeing / discussing diagrams in person at the f2f<br>
&lt;tantek> Have we made progress on this at previous f2fs?<br>
&lt;dael> fantasai: It would be useful for people to think and comment on the GH. Understanding the ramifications of this is most useful if people t hink through use cases and behavior and we're not going to get that around the  table.<br>
&lt;dael> Rossen: Agree.<br>
&lt;dael> Rossen: Did you want to discuss gap % resolution or should we let that go?<br>
&lt;dael> TabAtkins: I don't think we'd get that in 4 minutes<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/509#issuecomment-337657112 using your GitHub account
Received on Wednesday, 18 October 2017 16:57:14 UTC

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