- 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
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> <dael> Topic: [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2085<br> <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> <dael> Rossen_: I want to recapture the topic and i'm speaking as an edge impl on this.<br> <dael> Rossen_: Base of the problem is that we have a spec that defines 2 diff models of resolving % values for margin & padding top/bottom<br> <dael> Rossen_: They are spec for flexbox and grid to either resolve % against inline direction and that matches with block behavior.<br> <dael> Rossen_: Other proposed/defined behavior is keep everything symmertic and resolve top & bottom in the same axis as the height and width and those resolve in the respective block direction.<br> <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> <dael> Rossen_: In the veritical case that's a lot closer to block layout.<br> <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> <dael> Rossen_: This has been our behavior since the original grid. Later Gecko & 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> <dael> Rossen_: And here we are today.<br> <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> <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> <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> <dael> Rossen_: I'll give you an example of this where content looks broken on seemingly normal wordpress sites.<br> <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> <dael> Rossen_: I'd like L1 of grid and flexbox with jsut one behavior so that we're not introducing more breakage.<br> <dael> Rossen_: That's everything I want to say.<br> <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> <dael> Rossen_: I'd like to hear from Chrome folks if there are additional opinions or data.<br> <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> <tantek> FWIW "consistent with block" on one hand, "consistent with positioned elements" is the other.<br> <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> <Rossen_> http://www.gpkafunda.com<br> <rachelandrew> I'm having trouble with audio (on hotel wifi) but I noted in the issue my thoughts previously<br> <Rossen_> q?<br> <dael> Rossen_: URL that's an example where in FF or Edge you'll see breakage.<br> <dael> Rossen_: WOuld FF or Gecko be willing to change to match Chrome?<br> <dael> dbaron: I don't know off the top of my head.<br> <dael> dbaron: I'd need to look into history.<br> <dael> Rossen_: Our position is we want interop. We're more willing to change now that grid is impl everywhere (which is awesome).<br> <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> <dael> Rossen_: It took me a couple of days to make a prototype and make it work. That's another potential way forward.<br> <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> <tantek> q?<br> <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> <fantasai> +!<br> <fantasai> +1<br> <rachelandrew> I'll write up something in the next couple of days once I'm back in the UK<br> <dael> Rossen_: To close the topic, does anyone else want to say anything?<br> <tantek> q?<br> <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> <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> <dael> fantasai: TabAtkins and I are planning to spec it for sizing L4 once L3 goes to CR<br> <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> <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> <dael> tantek: +1 to gregwhitworth<br> <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