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

Re: [csswg-drafts] [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Dec 2017 17:34:40 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-351464769-1513186479-sysbot+gh@w3.org>
The Working Group just discussed `[css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2085<br>
&lt;dael> Rossen_: I'll intro this, but I'm also going to timebox this. We've beaten this down in the past quite a bit. We've stated differences already openly. I think the current GH captures a lot of this.<br>
&lt;dael> Rossen_: I want to recapture the topic and i'm speaking as an edge impl on this.<br>
&lt;dael> Rossen_: Base of the problem is that we have a spec that defines 2 diff models of resolving % values for margin &amp; padding top/bottom<br>
&lt;dael> Rossen_: They are spec for flexbox and grid to either resolve % against inline direction and that matches with block behavior.<br>
&lt;dael> Rossen_: Other proposed/defined behavior is keep everything symmertic and resolve top &amp; bottom in the same axis as the height and width and those resolve in the respective block direction.<br>
&lt;dael> Rossen_: I expressed the differences between flex and grid from our PoV. In this case I am a proponent of keeping flexbox and grid as close as possible. I wouldn't push for that principle on this, but I wouldn't be opposed. Flex is mostly a single dimentional layout where we distribute empty space in block or inline direction.<br>
&lt;dael> Rossen_: In the veritical case that's a lot closer to block layout.<br>
&lt;dael> Rossen_: Grid has always been 2d layout and we have attempted to keep everything as symmetric as possible when we worked on this, even internally at MS. That was a key preinciple. Everything is resolvable and symmetric to the extent where things are computable.<br>
&lt;dael> Rossen_: This has been our behavior since the original grid. Later Gecko &amp; FF caught up with grid and flexbox. At this point the blink and WK impl cought up with grid and the opposite for the inline direction % resolution was proposed/accepted b/c of those impl and the strong argument at the time was that people were trying to use % padding aspect ratio hack for grid items.<br>
&lt;dael> Rossen_: And here we are today.<br>
&lt;dael> Rossen_: Thanks to people from Igalia we have data that suggests current usage of those properties as % has incresed after we had a wider release of grid. That, looking a thte numbers, is at least 2-4x higher.<br>
&lt;dael> Rossen_: The reason I'm bringing this up is we're starting to see non-interop content.  There are broken webpages due to this.<br>
&lt;rego> just a clarification, the jump in the metrics is unrelated to grid shipping, it was a change in the way to measure use counters in Chromium<br>
&lt;dael> Rossen_: I'll give you an example of this where content looks broken on seemingly normal wordpress sites.<br>
&lt;rego> > Note: on 2017-10-26 the underlying metrics were switched over to a newer collection system which is more accurate. This is also the reason for the abrupt spike around 2017-10-26.<br>
&lt;dael> Rossen_: I'd like L1 of grid and flexbox with jsut one behavior so that we're not introducing more breakage.<br>
&lt;dael> Rossen_: That's everything I want to say.<br>
&lt;dael> Rossen_: At this point the higher order importance is that we have interop o nthose basic layouts that will be adopted more and more.<br>
&lt;dael> Rossen_: I'd like to hear from Chrome folks if there are additional opinions or data.<br>
&lt;dael> TabAtkins: Nothign that hasn't been said a year ago when we first had to introduce the undefinedness of this. We cannot change behavior of blocks, it should have been symmetric. Only reasonable use of % is the aspect ratio hack. Even though it's weird, being consistant with block seems easier for authors.<br>
&lt;tantek> FWIW "consistent with block" on one hand, "consistent with positioned elements" is the other.<br>
&lt;dael> TabAtkins: Ulimately I don't care, I want consistancy. We're split in half. Once 3 browsers converge we can change the spec to that. I don't want to change until someone bites the bullet and changes behavior.<br>
&lt;Rossen_> http://www.gpkafunda.com<br>
&lt;rachelandrew> I'm having trouble with audio (on hotel wifi) but I noted in the issue my thoughts previously<br>
&lt;Rossen_> q?<br>
&lt;dael> Rossen_: URL that's an example where in FF or Edge you'll see breakage.<br>
&lt;dael> Rossen_: WOuld FF or Gecko be willing to change to match Chrome?<br>
&lt;dael> dbaron: I don't know off the top of my head.<br>
&lt;dael> dbaron: I'd need to look into history.<br>
&lt;dael> Rossen_: Our position is we want interop. We're more willing to change now that grid is impl everywhere (which is awesome).<br>
&lt;dael> Rossen_: Once thing I want to throw out is there was another poss. solution proposed a couple years ago by myself in NY to entertain the idea of a switch to resolve % in one way or the other based on the container itself.<br>
&lt;dael> Rossen_: It took me a couple of days to make a prototype and make it work. That's another potential way forward.<br>
&lt;dael> Rossen_: However I said I'd timebox. I don't want to force a decision on this call. I really want to see grid L1 and flexbox have a single defined behavior on that.<br>
&lt;tantek> q?<br>
&lt;dael> Rossen_: Also, I know rachelandrew is having audio issues, but she offered to write a blog post. It would be grea to hear what the community has to say.<br>
&lt;fantasai> +!<br>
&lt;fantasai> +1<br>
&lt;rachelandrew> I'll write up something in the next couple of days once I'm back in the UK<br>
&lt;dael> Rossen_: To close the topic, does anyone else want to say anything?<br>
&lt;tantek> q?<br>
&lt;dael> tantek: I want to call out what I thought is new is it appears there's consensus on developing an actual solution to the aspect ratio hack. I see more interest on developing that in this issue then I remember previous interest.<br>
&lt;dael> tantek: In the hope of making progress on something with consensus I'd like to see the folks with proposals for that use case to post them in a sep. issue<br>
&lt;dael> fantasai: TabAtkins and I are planning to spec it for sizing L4 once L3 goes to CR<br>
&lt;dael> tantek: That would be great to see. I just wanted to call that out. I don't know if there's other new information.<br>
&lt;dael> Rossen_: That's great. gregwhitworth has been working on that from our end too so you might want to loop him into that discussion.<br>
&lt;dael> tantek: +1 to gregwhitworth<br>
&lt;dael> Rossen_: Anything else?  If not we can continue after rachelandrew blogpost.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-351464769 using your GitHub account
Received on Wednesday, 13 December 2017 17:35:01 UTC

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