Brief   Full   Jump  


High contrast


[CSSWG] Minutes Telecon 2017-12-13 [css-values] [selectors-4] [css-flexbox] [css-grid] [css-sizing]

1 message.

[CSSWG] Minutes Telecon 2017-12-13 [css-values] [selectors-4] [css-flexbox] [css-grid] [css-sizing]
Dael Jackson   Wed, 13 Dec 2017 20:19:23 -0500

www-style > December 2017 > 0018.html

Received on Thursday, 14 December 2017 01:20:23 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. ========================================= Meetings for the rest of 2017 ----------------------------- - Rossen will send out the proposed agenda for 20 December to garner regrets and determine if there are enough people for a call. - There will be no call on 27 December. CSS Values ---------- - RESOLVED: Resolve to clamp negative calc unit values in context and simplify as early as possible and then return the clamped calc as a result of the computed style. Selectors --------- - RESOLVED: Change the name :focus-ring to :focus-visible. Flexbox & Grid -------------- - Rossen brought issue #2085 ( | Choose a single option for resolving padding and margin percent values of grid/flex items) to the call in order to get more visibility and movement toward a solution. - There wasn't a decision reached on the call, but rachelandrew will make a blog post to garner from the community which behavior is preferable. - Most people expressed a desire to make sure that the same decision is applied to Grid & Flexbox to keep them inline. - As a part of this discussion several people have expressed an interest in a permanent solution to the aspect ratio hack and fantasai, TabAtkins, and gregwhitworth have all been looking into writing some spec text. Sizing ------ - There were many concerns that the proposal in issue #1865 ( | Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing) would cause severe breakage. - fantasai will go out and research if it will cause breakage and, if the result is that there is no compat risk, there was agreement that the proposal would be worthwhile to implement for Flex, Grid, and Block. ===== FULL MINUTES BELOW ====== Agenda: Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Tantek Çelik Dave Cramer Elika Etemad Daniel Glazman Tony Graham Dael Jackson Brian Kardell Brad Kemper Chris Lilley Peter Linss Myles Maxfield Michael Miller Anton Prowse Manuel Rego Melanie Richards Alan Stearns Lea Verou Greg Whitworth Regrets: Benjamin De Cock François Remy Florian Rivoal Scribe: dael Agenda & Process ================ Rossen: We should be good to get going. Rossen: As usual, are there any extra agenda items or changes? glazou: Is the discussion about short hands the deferred? Rossen: I was asking which you were referring to. glazou: The one about the shorthand impacting border image and that it cannot set it. Rossen: Do you have a GH? glazou: I'm not sure I did. I mentioned it probably 10 days ago. Last week because the different time astearns said it was this week. No problem if it's not. Rossen: I was hoping to see a GH or email that I can point to. It would be good to give people a chance to get familiar. Can we start with opening an issue in GH and then I don't mind adding it to any call. Including this one if you insist. <rego> it's on the mailing list glazou: No, not this call, but I wanted it sorted b/c it's very painful for web authors. Rossen: Thank you. Any other extra items? <glazou> Rossen Rossen: Should we have a call next week, 20 Dec? Rossen: I'm asking because I believe we settled on no call 27 Dec and I'm not sure the outlook for 3 Jan Rossen: So 27 and 3 most likely not. So instead of discussing in or out on the 20th I'll shoot a proposed email very early for next week and it would be great to see the number of regrets. Based on that we'll decide on if we should have a call. CSS Values ========== Computed value of a negative calc unit that doesn't allow negative lengths ------------------------------------------------------------------ github: Rossen: This was intro last week. We resolved to clamp as early as possible, but not how to return computed values based on this clamping. We wanted to hear about it from a few people, one of them was glazou. Rossen: That's the first topic. Rossen: Is TabAtkins or fantasai on? <TabAtkins> in. fantasai: I'm on, but no computer. TabAtkins: glazou didn't respond and I haven't had time to go through and dig up previous issues. I'm fine resolving now and waiting for complaints later if there are any. Rossen: Let me get us on the resolve. Previously we said clamp negative clamp as soon as possible. astearns: We didn't actually resolve. Rossen: Ah, thank you. So we didn't resolve. But there was consensus on clamping as early as possible, right? TabAtkins: I believe so. <glazou> apologies I completely missed the RFI on that issue Rossen: Proposal is negative calc units are clamped as early as possible fantasai: per value or per prop? Rossen: I believe per value. fantasai: That was key question, per property or per value. Rossen: I assumed it was per value and if it was given to the property it inherits. astearns: Yes, it was definitely per value. TabAtkins: mmhmm Rossen: Right. Rossen: So the consensus was to try and clamp those as early as possible. There was not consensus on how to return computed values. as calc with negative value inside or return the clamped value. Rossen: So we could resolve on clamping and leave serialization out. TabAtkins or fantasai preference? TabAtkins: That's fine with me. The question was if you have a calc that's 50px-2em and that's negative at calc time do we simplify to calc(0px) rather then keeping the original. I'm fine simplifying the internal of the calc to the clamped value. I think that's what dbaron wanted. <gregwhitworth> so calc(0) rather than 0 or calc(<N> - 2em) dbaron: I think clamping and simplification should go together. If we're clamp we should also simplify. TabAtkins: That happens already, we collapse units together. But if we have units that we know will be clamped is the topic. dbaron: When you can resolve between px and em and know it's negative I think you also simplify to px. TabAtkins: I'm fine with that. Rossen: And the serialized value is whatever the clamped value? TabAtkins: With a calc around it. Rossen: Other opinions? * glazou is fine with resolution Rossen: Objections on resolving to clamp negative calc unit values in context as early as possible and then return the clamped calc as a result of the computed style. RESOLVED: resolve to clamp negative calc unit values in context as early as possible and then return the clamped calc as a result of the computed style. dbaron: We're saying clamp and simplify. TabAtkins: Some simplification is speced. This is collapse all units together that can be figured out. So we'd collapse em with px etc. fantasai: You have to do that for inheritence to work. TabAtkins: Yeah. <TabAtkins> Right now we already simplify calc(1px + 2px). Resolution is to also simplify calc(1px + 1in) at computed/used value, and things like calc(1px + 1em) at the point where that's possible. RESOLVED: Resolve to clamp negative calc unit values in context and simplify as early as possible and then return the clamped calc as a result of the computed style. Selectors ========= Rename :focus-ring to :focus-indicator -------------------------------------- github: bkardell: :focus-ring is what the mozilla folks used on early prefixed impl. When we said we'd adopt we carried the name, but most documentation use a different name and it's frequently not a name. In practice the name was confusing. We proposed focus-indicator which matches most doc, but there were worried that sounded more like a pseudo element TabAtkins: One of the obj from Alice to focus-ring is people think it's a pseudo element styling the ring and if that's the confusion then focus-indicator just genericized the noun since we name the thing shown not the quality of the element. bkardell: That's a fair other observation. I think focus-visible is what people on GH seem to have gathered around and there's a standing pull request with that. Rossen: So I guess the current runner is focus-visible <tantek> I reviewed and :focus-visible makes sense to me per Tab's arguments about noun/thing vs. state of thing bkardell: Yes and there's an outstanding PR so we can just accept that. Rossen: I'm sad focus-pocus isn't it, but focus-visible is good. <fantasai> wfm TabAtkins: I'm fine with focus-visible Rossen: Other opinions? RESOLVED: Change the name to :focus-visible. Flexbox & Grid ============== Choose a single option for resolving padding and margin percent values of grid/flex items --------------------------------------------------------------- github: 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. Rossen: I want to recapture the topic and I'm speaking as an Edge implementor on this. Rossen: Base of the problem is that we have a spec that defines 2 different models of resolving percentage values for margin & padding top/bottom. Rossen: They are spec for flexbox and grid to either resolve percentage against inline direction and that matches with block behavior. Rossen: Other proposed/defined behavior is keep everything symmetric and resolve top & bottom in the same axis as the height and width and those resolve in the respective block direction. 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 dimensional layout where we distribute empty space in block or inline direction. Rossen: In the vertical case that's a lot closer to block layout. 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 principle. Everything is resolvable and symmetric to the extent where things are computable. 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 caught 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. Rossen: And here we are today. * fantasai is very strongly opposed to making Grid and Flex differ on this point. Otherwise defer to Jen & Rachel. <astearns> my understanding (I might be wrong) is that people are only complaining about this for Grid, not Flexbox. If that's the case I'm less concerned with keeping Grid and Flex the same <TabAtkins> astearns I would hard-object to having Grid and Flexbox act differently, unless there's *strong* web-compat reasoning for it. Rossen: Thanks to people from Igalia we have data that suggests current usage of those properties as % has increased after we had a wider release of grid. That, looking a the numbers, is at least 2-4x higher. <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 <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. Rossen: The reason I'm bringing this up is we're starting to see non-interop content. There are broken webpages due to this. Rossen: I'll give you an example of this where content looks broken on seemingly normal wordpress sites. <Rossen> Rossen: I'd like L1 of grid and flexbox with just one behavior so that we're not introducing more breakage. Rossen: That's everything I want to say. Rossen: At this point the higher order importance is that we have interop on those basic layouts that will be adopted more and more. Rossen: I'd like to hear from Chrome folks if there are additional opinions or data. TabAtkins: Nothing 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 consistent with block seems easier for authors. <tantek> FWIW "consistent with block" on one hand, "consistent with positioned elements" is the other. TabAtkins: Ultimately I don't care, I want consistency. 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. <rachelandrew> I'm having trouble with audio (on hotel wifi) but I noted in the issue my thoughts previously Rossen: Would FF or Gecko be willing to change to match Chrome? dbaron: I don't know off the top of my head. dbaron: I'd need to look into history. Rossen: Our position is we want interop. We're more willing to change now that grid is impl everywhere (which is awesome). Rossen: One thing I want to throw out is there was another possible 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. Rossen: It took me a couple of days to make a prototype and make it work. That's another potential way forward. 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. Rossen: Also, I know rachelandrew is having audio issues, but she offered to write a blog post. It would be great to hear what the community has to say. <fantasai> +1 to blog <rachelandrew> I'll write up something in the next couple of days once I'm back in the UK Rossen: To close the topic, does anyone else want to say anything? 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. 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 separate issue. fantasai: TabAtkins and I are planning to spec it for sizing L4 once L3 goes to CR. tantek: That would be great to see. I just wanted to call that out. I don't know if there's other new information. Rossen: That's great. gregwhitworth has been working on that from our end too so you might want to loop him into that discussion. tantek: +1 to gregwhitworth <TabAtkins> +1 for developing a non-hacky aspect ratio thing Rossen: Anything else? If not we can continue after rachelandrew blogpost. Sizing ====== Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing -------------------------------------------------------- github: Rossen: fantasai can you take this? fantasai: This was the issue about when you have a flex or grid item and inside it there's really wide content that has scrollbars. fantasai: When you put this inside a flex item it triggers the impl min size which looks at min-content size. Usually it's on the smaller size, but for something like this it could be really really big. Bigger then you expect, esp if you have scrollbars in there. fantasai: But you don't get scrollbars because the ancestor asked for the min size. fantasai: This is causing a lot of author confusion because some ancestor is making it blow up. The work arounds are not super obvious. fantasai: Suggestion when there is an overflow scroll the min-content contribution should be 0. fantasai: That would prevent this from happening. fantasai: There are some compat restrictions. For now proposal is: a) don't do this to a block in the block axis and b) don't do it for blocks that have overflow: hidden b/c that's often used to create a flex-root fantasai: If a box has overflow not visible and not hidden and it's a block in the inline axis its min-content contribution assumes 0. If it's a flex or gird item we do that for any value of overflow that's not visible in both axis. fantasai: We believe this would solve most cases. The fix if it's too small is to apply a min-width which is a fairly understandable fix. Rossen: Thanks fantasai. dbaron: This sounds like a substantial change to existing behavior. fantasai: Yes. fantasai: On flex items and grid items probably won't be too surprising. Applying to blocks...if you have a scrollable block and you're expecting inline size of that block to control the size of its ancestor by sizing so it won't scroll, then your layout would change. fantasai: We can split into two parts, do for grid and flex and can we do for block. dbaron: If you do it for one but not the other you're changing from one concept of min-content size to 2. fantasai: Min-content contribution. We already have special behavior for flex and grid when overflow is visible. This is implying the same thing where we don't consider the content for min-content contribution. dbaron: Isn't this non-local? It's arbitrarily deep descendants. fantasai: No. This is if a particular element is flex or grid and has overflow not visible we don't look at its content when looking at its own min-content contribution. fantasai: We're assuming 0 for the purpose of calc the min-content contribution of that item and this will fix the ancestor issue. dbaron: Only if the descendant is flex or grid. fantasai: Yes. That's part 1. Part 2 without would apply to regular block would fix it for block. But it's a local effect, to fix the action-at-a-distance problem. dbaron: Seems like you're saying the compat thing only solves half the problem. Given how widely flex and grid are used I'm not sure part 1 is even web compat. Rossen: Certainly not for flexbox. I'd be more concerned about that then grid at the moment, but definitely concerned about flexbox. dbaron: Any sign that impl are not interop? Rossen: I don't believe so. fantasai ? fantasai: I don't believe so either. fantasai: I think the behavior is more in line with what authors expect. When then set it to be scrollable you don't expect it to force the ancestor to give enough space for you not to scroll. I think this would make flex and grid more intuitive to authors. dbaron: I don't think we can change without more evidence it's safe. fantasai: Fair. I guess we can discuss if we want to change if possible, then we can look and see if it's possible. Not make the change until there's more data. dbaron: My gut is it's not safe and therefore not worth exploring. Particularly the half change doesn't seem sensible. fantasai: The thing is the only case...for a block element by itself inside a container you can size it with %. For block elements they're in a flow and they'll take their auto size. The effect in that axis...we don't distinguish between max and min content in the block axis. If we try and apply to a block in a block axis we have to introduce this concept and then have the min and max calc differently. fantasai: You have a set of blocks and they have a min and a max size and you have to calc layout twice to get the min size. dbaron: I'm not worried about block axis part. I don't agree with these concepts existing in the block axis. It's the not doing it for block, just for flex and grid, that's the half change. fantasai: Ideally I'd like to do both, yes. Rossen: And the second part is a lot scarier meaning doing both would be a lot harder. Rossen: This is going to sizing right or flex and grid? fantasai: Sizing fantasai: In terms of collecting data, that's a project but I'm willing to try and work on it b/c this issue is causing a lot of problems for authors. Rossen: Can you point to some of the confusion? fantasai: There's a bunch of websites trying to explain the fix and the fix isn't obvious. fantasai: There's a pre several items deep that's causing this and it's not obvious and it's getting exploded. And the explosion is a min-width so even setting a flex-basis it won't flex the way you expect. Rossen: Do you want a resolution? Rossen: More support to work on it? Sample interest? fantasai: What I've gotten is we want more data on if it's compatible. I'd like to know if the web compat comes back as no problem, would people want to make this change? If the answer is no there's no point in getting data. Rossen: As an Edge impl, the impl itself won't be that difficult so if you're probing to see how impl this it, it is fairly doable. But I'm fairly concerned with breakage, I'm sympathetic to dbaron's case. fantasai: And the point is collect data. But if we get data that says it's okay, would you accept the change? If you still don't like the change we've wasted the time to get data. Is it worth it to collect the data? Rossen: Okay. If anyone wants to push back on any reason other then interop concerns, this is your chance. gregwhitworth: While people think, I want to loop back and say we solved a similar problem for tables. I'll link to the minutes. We hit a similar problem where we have this very scenario. <gregwhitworth> gregwhitworth: I personally feel there is enough there. I'm not sure if it's worth gathering data. We have compat issues with the inverse. fantasai: What you're saying is we had an issue with a direct descendants of the table which has scroll does not contribute it's min-content. It was 0. gregwhitworth: Yeah, it's floored out. The layout is done and then Chrome fills out. In Edge we give it the 100% and then the accept term of service ends up offscreen. fantasai: That's an example of us having to make for compat reasons the fix being proposed. This proposal is doing that same kind of fix more generally. fantasai: Same use cases. fantasai: Concern for data wasn't if we needed use cases to see if there's author want, this was to see if we can do it without breaking the web. gregwhitworth: To answer the question better, if there's positive use cases showing people want this and you bring back data saying it wouldn't be a problem, I would be shocked if people pushed back. Rossen: I also said that impl % resolution for padding was easy for us and it wasn't for others. I'm only speaking for Edge. fantasai: My understanding is because it's a local effect it's just a switch on when computing the min-content not to do some extra work. I don't think it's generally difficult to impl. Rossen: We're pretty much top of hour. For fantasai to proceed we need to hear there are not strong objections. Most people are worried about interop. gregwhitworth pointed out some issues where people need the opposite for tables which would bring more arguments against making it for blocks. fantasai: gregwhitworth's argument pointed out people are having this behavior for specific tables. It's a point in favor of people expecting the proposed. Rossen: Okay. Rossen: I'm not hearing any objections. fwiw continue with this. fantasai: So the conclusion is we expect to accept the proposal if fantasai can get data that's it's webcompat. Rossen: Yes. I think going to the step of data is worthwhile. dbaron: I would hesitate to accept the half proposal, though. Rossen: +1 to dbaron fantasai: We expect to accept the full proposal if fantasai can get data it's web compat. Rossen: I'll send the rest of the agenda to get how many regrets for next week. <dbaron> I think we'd want to know who would the first implementor of the change would be, though. Rossen: Thanks everyone. Rossen: If we don't have a call, I wish everyone an early happy holiday, safe travels, and we'll talk next week or next year.