22:55:12 RRSAgent has joined #css 22:55:12 logging to https://www.w3.org/2021/05/05-css-irc 22:55:14 RRSAgent, make logs Public 22:55:15 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 22:56:12 dholbert has joined #css 22:57:55 present+ 22:57:58 ScribeNick: dael 22:58:05 smfr has joined #css 22:58:12 present+ 22:58:46 present+ 22:59:19 bmathwig has joined #css 23:00:28 astearns: Thanks to all present on time. We'll wait the normal couple of minutes for more people to join us 23:01:03 sanketj has joined #css 23:01:10 present+ 23:01:15 present+ 23:01:29 Rossen_ has joined #css 23:01:41 present+ 23:01:42 #present 23:01:48 present+ 23:02:01 present+ 23:02:16 astearns: One more minute. THe list is still pretty short 23:02:23 present+ 23:02:27 astearns: While we wait does anyone have suggested changes to the agenda? 23:02:40 present+ 23:02:53 Rossen_: Do we have any TPAC related things to discuss with the group? 23:03:17 dlibby has joined #css 23:03:24 Rossen_: Joint meeting type. It'll be sooner than later we need to decide. Especially meet before or after TPAC 23:03:53 astearns: Nothing on the books. Suggestion from leaverou about both. One a few weeks before and one a few weeks after so we can prepare for joint meetings and then respond to anything coming out 23:04:02 astearns: That makes sense to me. Other opinions? 23:04:16 present+ 23:04:18 present+ 23:04:36 Rossen_: Sounds good to me as well. Sandwiching TPAC. Hopefully wont touch with other WG meetings, TAG, AC, and other acronyms. 23:04:46 astearns: Do you know TAG? WE have a bunch of people on it 23:05:08 Rossen_: Try to do TPAC directly. One week before? Right around ABE time since want to have joint meeting 23:05:09 dauwhe has joined #css 23:05:26 astearns: WE should get going. I'll put a proposal for TPAC and next long form meeting 23:05:34 astearns: We'll see what people think on the list 23:05:43 present+ 23:05:44 Topic: css-overflow] [css2?] Baseline of an inline-block with overflow:clip. 23:05:51 Github: https://github.com/w3c/csswg-drafts/issues/6212 23:06:13 fantasai: 4 proposal in the issue afaict. 1) same as visiable even if baseline of clipped text 23:06:27 fantasai: 2. treat like overflow hidden and synth baseline regardless of what's inside 23:06:27 present+ 23:06:46 fantasai: 3. use whatever visible text is there. If clipped or below clipping point stop at clipping point 23:07:05 fantasai: 4 is same but instead of clamp to clipping area we clamp to border area b/c that's how hidden behaves 23:07:13 iank_: I think it's margin edge 23:07:39 iank_: Unique thing here is inline box us by default last baseline. Not like first for flex/grid. overflow:hidden if you didn't do end margin you'd get a funny box 23:07:58 iank_: Question is which. We treat like overflow hidden 23:08:05 iank_: [missed] 23:08:10 drousso has joined #css 23:08:13 s/hidden/hidden, Firefox treats as visible/ 23:08:26 present+ 23:09:08 iank_: Basically, chrome went way of overflow:hidden for that reason and adhereing to css 3. FF went for overflow:visible behavior. Merits to both. Slightly prefer ours a little b/c if you have a lot of content and overflow:clip you'd have things way off in linebox 23:09:45 fantasai: So long as there's visible content makes sense to align to that visible content. One of the intentions is to not trigger a bunch of layout. Line of content and extra room for floating stuff which you clipped. Want to keep alignment 23:10:13 fantasai: Clamp to padding edge might make sense b/c else aligning to something can't see. overflow:clip to clip anything outside, if there's content visible want to align to that 23:10:23 iank_: This is also somewhat an issue for last-baseline 23:10:28 fantasai: Also first-baseline 23:10:33 iank_: Yes, rare case, but yes 23:10:52 fantasai: Makes sense for last and first baseline to be consistent. First we want to align to first-baseline when it's visible 23:11:10 astearns: If we clamp to clip area or margin edge...if clip area doesn't that give you layout changes based on clipping? 23:11:35 fantasai: We wanted to avoid it but idea you're aligning to something invisible we also want to avoid. Which to avoid more? clamping to visible makes sense 23:11:50 astearns: Thinking of animated where revealing and aligning to what you can't see if waht you want 23:12:09 fantasai: But in that case usually won't get clipped. Usually overflowing content you want clipped or not overflow 23:12:20 fantasai: Dynamic visibility you probably don't want to reveal content overflow 23:12:34 astearns: So option 4 calc same as visible but clamp to margin edge? 23:13:06 fantasai: Yeah. Margin edge is a little weird. Border edge makes more sense. Had an issue about margin or border earlier. PDF raster and browsers are inconsistent. 23:13:18 fantasai: I would clamp to the clip edge which is padding edge 23:13:30 iank_: Any other opinions? I'm weak on my opinion 23:14:23 florian: A little opinion. If we manage to get behavior that's really author friendly let's do that. If we're kind of author friendly but not really it's not worth another slightly different variant. If we can land exactly what you want you don't have to debug but elsewise concerned about subtlties 23:14:51 iank_: Discovered on FF issue tracker thinking FF was wrong. One data point a webdev expected Chrome behavior. But that's only one data point 23:15:22 fantasai: Pretty strong first baseline we should align to if visible, even if clip. Makes sense for last to follow that logic. If and where we clamp is more debatable 23:15:42 q+ 23:15:43 iank_: Prefer not the clampping behavior. Just pick the baseline, even if not visible or pick an edge 23:16:12 ack smfr 23:16:12 iank_: One thing is people see overflow:clip as a dropin for overflow:hidden. THere's a weak argumenet to align to overflow:hidder 23:16:34 smfr: Prefer a behavior such that baseline alignment is same as if inline block had clippath inset: 000 23:16:37 fantasai: That's FF? 23:16:42 smfr: That's clip to the box 23:16:45 iank_: Why? 23:17:14 smfr: In terms of layout and rendering I consider overflow:clip as similar to clippath. Doesn't have effects, but it's a clip where I don't expect layout implications 23:17:16 fantasai: Fine with that 23:18:06 Rossen_: I wanted to pull back on smfr comment and get clearer picture in terms of behavior he would see in the attached example from emilio. Would that be, smfr , closer to FF or chromium? 23:18:17 smfr: Didn't examine. People said it's more like FF 23:18:24 Rossen_: Which has layout implications 23:18:28 iank_: Which does not 23:18:48 Rossen_: I was on an older FF 23:18:54 GameMaker has joined #css 23:19:02 present+ 23:19:21 astearns: Suggest we resolve to spec option 1, FF behavior, since we have people in favor and iank_ only with weak objection. See if we can take that to the bug reporter and see if it makes sense to them 23:19:40 astearns: Can also talk to PDF reactor about if clampling behavior is required or they could move to non-clamp 23:19:52 astearns: Prop: Specify option 1; match FF current behavior 23:19:56 astearns: Objections? 23:20:04 RESOLVED: Specify option 1; match FF current behavior 23:20:14 Topic: [css-overflow] scrollbar-gutter should not do anything for non-scrollable boxes 23:20:24 github: https://github.com/w3c/csswg-drafts/issues/6028 23:20:41 astearns: Discussed a few weeks ago. Hoping to see more on this issue in GH. Do we think we can get to a resolution? 23:20:47 florian: WE can try 23:20:56 fantasai: I think comments in other issue interrelate 23:20:58 astearns: Do the other first? 23:21:07 florian: I think largely same thing from different angle 23:21:10 fantasai: Is leaverou on? 23:21:20 astearns: I don't think so. nor chrishtr 23:21:30 fantasai: Might make sense to defer until they can attend 23:21:36 astearns: Let's skip 2 and 4 23:21:39 github: none 23:21:49 Topic: [css-box] increase pointer target size independently of element layout 23:21:51 Morgan_ has joined #css 23:21:54 github: https://github.com/w3c/csswg-drafts/issues/4708#issuecomment-588369114 23:22:11 fantasai: Posted a link to the comment with follow-up 23:22:27 fantasai: Last time had a question for the commentor about it being a length or larger/normal/smaller 23:22:31 https://github.com/w3c/csswg-drafts/issues/4708#issuecomment-588451067 23:22:34 fantasai: Commentor responded ^ 23:23:03 fantasai: Example of 2 buttons side by side and explaining author would not be able to know distance. Not spec a length larger. If we made it up to UA maybe there would be overlap 23:23:45 fantasai: That was a concern by the poster. Related, plinss commented explaining what happens with 2 JS elements with extended hit area. Don't want to cover another element. Need more sophisticated logic then extending the hit area 23:24:01 q+ 23:24:03 fantasai: These points were brought up. Figured bring back to the group for discussion on how to move forward 23:24:18 ack smfr 23:24:48 smfr: Question if we need this. Mobile browsers have something we call area hit testing. When you hit test you look in area around target that respond to events. One answer is UA should do it automatically somehow 23:25:32 florian: Tempted to agree b/c how big hit area needs to be is not something author can know. Depends on type of thing used to click, finger or stylus. Ratio between css pixels and layout. It's guesswork 23:25:41 florian: Probably UA is in better position 23:26:05 myles: Similar. If you pinch zoom finger to page changes. Anything that's fixed is not right tool 23:26:29 iank_: Trying to remember if we had this convo. We had people asking for this a while ago. might be on us to circle back with what they were after 23:26:37 astearns: Do you mean automatic for "this" 23:27:00 iank_: Not auto. A fixed length. I think chrishtr was more involved. I'm diging from my memory. But I don't think there's more we can do 23:27:11 florian: Do all browsers to area hit testing or is it apple specific? 23:27:25 smfr: Pretty sure it's mobile browsers. We do it on mobile WK. I think Android has 23:27:29 ack fantasai 23:27:30 https://cloudfour.com/thinks/jagged-little-pill-issues-with-rounded-buttons/ 23:27:34 iank_: I believe we have similar. Not area of expertise 23:28:00 fantasai: Illustration from issue ^ Someone writing about rounded corners on buttons reducing click area and they wanted it fixed. That's another consideration 23:28:30 fantasai: If we're seeing a lot of people doing this with hacks we should build in. If browsers can do it automatically and we don't need hacks that's idea 23:29:04 iank_: Potential for that. I have hear border radius reducing hit test. Argument for authors to opt out, particularly with large rounded corner. Unlikely there will be other elements 23:29:20 iank_: We likely should move on. Not sure how much more we can do on this today 23:29:32 plinss: I'm in favor of leaving to UA. Might be worth spec an algo to get interop 23:29:44 astearns: That would start with defining hit testing 23:30:10 florian: I believe there's an action on me for years ago to put something i spec. I don't think there's a good definition of it, so it's not in spec 23:30:23 astearns: iank_ if you can dig up the request that would be great to add to the issue 23:30:32 Topic: [css-contain] How does @container resolve when no ancestor containers have been defined? 23:30:41 github: https://github.com/w3c/csswg-drafts/issues/6178 23:31:13 miriam: Initial proposal was if not container as explictly defined we'd fall back. Root element or viewport. Some sort of fallback for container queries so they always resolve against something 23:31:58 a fallback to something random seems pretty bad to me.(?) 23:32:00 miriam: Not convinced. When writing a container query assuming it's close to actual size. Fallback to full viewport will be dramatically wrong in a lot of cases. IF authors are using current best MQ best practice for smaller layouts inside they get smaller fallback 23:32:18 miriam: If can have containment on root you can make the choice yourself. Popular to do, but risky fallback 23:32:30 miriam: We should not try and salvage container queries when there is no container 23:32:43 iank_: Agree. Sounds pretty hostile to fallback to something unexpected 23:33:07 astearns: I voted for root in twitter but you have convinced me I was wrong 23:33:19 astearns: Prop is have MQ not do anything if no container to measure against 23:33:23 miriam: Correct 23:33:26 florian: Reasonable 23:33:39 astearns: Obj to have conainer MQ not resolve when there is no ancestor container 23:33:48 RESOLVED: have container MQ not resolve when there is no ancestor container 23:33:56 Topic: [css-contain] :root/body viewport propagation and containment 23:34:05 github: https://github.com/w3c/csswg-drafts/issues/5913 23:34:46 miriam: Not the one that raise this but rune isn't here. Can't speak for browser engineers. Seems like users that would want to do containment at root. Would not like to disallow, but he has a few other proposals 23:35:04 miriam: No strong feelings 23:35:20 iank_: There's 3 solutions from prop direction writing modes. 23:35:35 iank_: The first is the giant hammer no one wants which is disallow on body 23:35:53 iank_: Second is when container quereis apply we stop body prop up to viewport 23:36:13 iank_: Third option is to do prop but don't let it change after that. Stuck at initial value 23:36:14 dauwhe has joined #css 23:36:33 iank_: Means if you have container query on html element and spec body under 500px changes writing mode wouldn't work 23:36:55 iank_: I think I prefer the 2nd option. When we have containment applied we don't form propagation. However, 2 valid solutions 23:37:39 florian: Agree with iank_. Prop from body is for compat reasons. In general containment is not an operation that changes nothing. It changes layout b/c contains things. Saying it contains prop it's fine. If you need it on the root, set it there 23:38:13 iank_: Not allowing you to dynamically change those properties inside container queries seems bad to 2nd 23:38:28 fantasai: 2nd is if you apply containment to root or body we don't do body prop but do from html root element 23:38:41 florian: If you do on body doesn't prop to root but can't contain root 23:38:55 florian: No cotnainment on root. On body is possible, but stops prop from body 23:39:02 fantasai: Does contain apply to root general? 23:39:04 florian: Not defined 23:39:17 fantasai: If it does it would make sense that would aslo block prop. 23:39:42 iank_: Problematic case is html element then body. Put a container query and the body can change style and prop to root 23:39:54 fantasai: Yes, not allowed. Containment on root or body shoudl block body from prop. 23:40:02 fantasai: Nothing shoudl block root from prop 23:40:23 fantasai: Assuming containment on root can be done. If it does not apply if it blocks body no strong opinion 23:40:33 florian: Don't recall talking about cotnainment on root. 23:40:53 miriam: It is a use case people want. Might be able to get close with body containment. People are wanting the ability 23:41:00 florian: Can you explain why root? 23:41:46 miriam: I don't know people have thought through body or root. Main is you could adjust body based on root query. There is a case to use a cotnainer query isntead of MQ for viewport b/c cotnainer lets you respond to actual font size and dimensions rather than browser or user font size. 23:42:20 iank_: Once people get their hands on container queries they won't think about viewport MQs much anymore. They'll attach container query to root to adjust viewport 23:42:46 fantasai: Givenw e're expecting containment to apply to root with an effect of some kind it should also block body from propagating 23:43:00 fantasai: Prop: containment does nto block root from propagating, but it does block body 23:43:12 florian: Containment to the body makes sense. Still confused on root 23:43:27 fantasai: If containing the body and prevents prop, why wouldn't containing and ancestor block? 23:43:53 florian: Doing it outer edge of thing being container. Means root doesn't effect parent. Doesn't change how things inside are effected. Might be useful 23:44:05 fantasai: Containment means child doesn't interact with ancestors, right? 23:44:12 florian: Yeah, okay. I can see it 23:44:14 +1 fantasai 23:44:30 fantasai: Interface of container some things applya nd some don't, but child shouldn't interact with grandparent 23:44:43 florian: Body to root maybe should be blocked. 23:44:51 fantasai: Body to root? Does that happen? 23:44:59 iank_: Root is HTML element? 23:45:01 florian: Yes 23:45:11 iank_: Containment applies to html element fine. 23:45:27 astearns: Prop: If there is containment on body it stops prop from body to root? 23:45:31 florian: On body or root 23:45:52 astearns: Prop: If there is cotnainment on body or root it stops prop from body to root 23:46:06 RESOLVED: If there is containment on body or root it stops propagation from body to root 23:46:18 Topic: [css-contain-3] Need style containment for container queries 23:46:25 github: https://github.com/w3c/csswg-drafts/issues/6213 23:46:49 iank_: Rune constructed some cases, linked in issue, with counters which would cause circularity 23:47:27 iank_: Way counters work is they walk all over dom tree. With this example constructed a circularity. We think style containment is required for container queries to work 23:47:50 iank_: Didn't read example in depth to explain how it's circular. If people are happy with Rune expertise. 23:47:54 astearns: We can believe him 23:48:17 florian: No problem believing him. But I think we had said style cotnainment was odd and need to get back to it 23:48:28 iank_: I think style containment main is scoping counters 23:48:33 florian: Yes, and quotations 23:48:54 iank_: I think, even that statment that counters can prop outside the subtree it's clear you get circularities 23:49:04 astearns: Is style cotnainment impl? 23:49:06 florian: Yes in Chrome 23:49:13 florian: Can't remember if FF impl 23:49:52 dholbert: Not in FF. Work in progress patch where emilio had objections about usefulness being debatable. I'd lean to wait until emilio is on. I can point him to the issue 23:50:12 dholbert: I think he has strong opinions. Maybe he wanted a motivating use case. Perhaps this is the one 23:50:32 iank_: Agree with emilio. This is use case that makes it useful. We could tentatively resolve now or wait for emilio on next call 23:50:54 dholbert has joined #css 23:51:03 florian: Either way, not last time we'll talk. Given obj from emilio we stopped on style cotnainment and kept going on the rest. If we start requiring it we'll look closer and find other things to change 23:51:59 https://github.com/w3c/csswg-drafts/issues/6174 23:51:59 astearns: Understand complexity to impl. Seems like one of the objections to style containment is why would anyone use it. Wonder if it makes sense to fold in effect os style cotnainment to existing contain values b/c gets better containment and avoid circularity. Or a specific value for container queries that has this contained 23:52:05 miriam: That gets to issue 6174 23:52:31 miriam: Not on the agenda, but if we need style containment it's more argument to come up with new syntax. Happy to work with anybody that wants to work on it 23:53:13 iank_: Maybe path is ask emilio if he objects to style containment as a concept given these examples and then separate discussion about what sort of short hand do we want with miriam issue about container query style containment 23:53:20 astearns: Anything else before we kick it back to issue? 23:53:45 Topic: [css-fonts] extend font-size-adjust to take a pair of values: 23:53:50 github: https://github.com/w3c/csswg-drafts/issues/6160 23:54:14 https://github.com/w3c/csswg-drafts/issues/6160 23:54:19 fantasai: I think we can conclude on key parts. Added ability for font-size-adjust to take metric name and then target ratio. Question is what are initial keywords 23:54:29 fantasai: Propose add xcap ic and ch 23:55:12 fantasai: Jonathan Kew ageed. Wanted to discuss ascent and descent. I would suggest for now adopt the initial set and if we want to discuss additional do so in separate issue 23:55:12 s/xcap/ex, cap/ 23:55:20 astearns: Suggesting the short names? 23:55:40 fantasai: Yeah, to match units. And b/c operate in correct axis which may be height or width depending on writing mode 23:55:42 myles has joined #css 23:55:46 present+ myles 23:56:03 fantasai: If we want independwnt of writing mode would need to add variants. We can start with this set 23:56:36 myles: Feel like we should add acsent to the set. Cases where it might give you confusing results. If someone applies more likely to do good. Valuable to have 23:56:43 fantasai: I think cap will be better in most cases 23:57:33 fantasai: ascent and descent metrics are pretty wild when fonts are outside of latin. This applies to fallback and system fonts. You'd get something that works well until it really doesn't. I think that's a serious concern we don't have a way to address. Can keep talking. I think this is a good intial set 23:57:53 astearns: Given that are you okay to start with these 4 myles? 23:58:02 myles: fantasai are you saying you think ascent is harmful? 23:58:24 fantasai: Yes. Someone will use it expecting reasonable and it will fallback to a system font on someone's machine that is very different 23:58:42 florian: Arial and MSUnicode are wildly different, to give an example 23:59:03 fantasai: Slide 23 on the deck in the issue show and example of wildly different 23:59:20 i/fantasai/fantasai: You'll end up with a font that's much too small/ 23:59:51 myles: I think it will be good in more cases then bad. For metrics that don't have units I think we should use longer names. Value of shortnames is porpotional to number of times typed. For the lengths type a lot, but without it's only this one property. Longer names to make it clear is valuable 00:00:30 fantasai: ic and ch they should respond to writing more and text orientation so they could be width or height. WE can't use a longer name for those. If ic and ch have shortnames it makes sense for ex and cap to also match shortnames 00:00:48 myles: Point I was making about metrics that don't have units that match 00:00:53 fantasai: We don't have those yet 00:00:58 myles: With ascent we would 00:01:22 fantasai: Yes. But for ones with a unit; 2 have to match b/c can't add height or width. Others might as well b/c why be different 00:01:39 astearns: Prop: Add these four to start with. After that we can add more 00:01:45 astearns: Obj? 00:02:00 RESOLVED: Start with ex cap ic and ch 00:02:13 astearns: myles can I ask you to add a new issue for ascent and poss decent? 00:02:17 myles: You could 00:02:20 Topic: end 00:02:29 astearns: Thanks everyone for calling in. We'll talk next week 00:07:50 s/Arial and MSUnicode/Arial and Arial Unicode MS/ 01:24:36 castastrophe has joined #css 01:57:15 Zakim has left #css 04:13:58 atrigent has joined #css 04:57:37 jensimmons has joined #css 05:01:25 rego has joined #css