22:53:02 RRSAgent has joined #css 22:53:02 logging to https://www.w3.org/2021/08/04-css-irc 22:53:04 RRSAgent, make logs Public 22:53:05 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 22:57:28 GameMaker has joined #css 22:59:23 dholbert has joined #css 22:59:32 present+ 22:59:56 present+ 23:00:00 ScribeNick: dael 23:00:05 present+ 23:00:27 mwoodrow has joined #css 23:00:51 astearns: We'll wait for people to join as usual 23:01:48 present+ 23:01:52 Rossen_ has joined #css 23:01:53 dlibby has joined #css 23:01:55 present+ 23:02:00 astearns: This looks like enough people to start 23:02:04 present+ 23:02:06 present+ 23:02:11 alisonmaher has joined #css 23:02:18 astearns: I did notice fantasai the issue you added the agenda+ to. If we have time we'll get that 23:02:20 present+ 23:02:23 astearns: Any other changes for the agenda? 23:02:26 sanketj has joined #css 23:02:35 fantasai: Wanted to ask about moving the scrollbar to overflow 3 from 4 23:02:41 astearns: We can start with that. Other changes? 23:02:54 present+ 23:02:58 AmyCarney: We discussed maybe meeting with APA at TPAC? 23:02:59 https://drafts.csswg.org/css-overflow-4/ overflow-4 is mostly about exploratory fragmentation ideas 23:03:02 astearns: We'll start with that 23:03:08 smfr has joined #css 23:03:13 present+ 23:03:38 AmyCarney: I don't have a designated time yet. You said it might be flexible on your part. mostly APA wanted to bring up MQ again. Discuss things ?? gave a preso on that could be in MQ5 23:03:40 present+ 23:03:53 astearns: I think APA should propose a time and we will show up. We have no other obligations for TPAC week yet 23:04:04 AmyCarney: I will discuss that with the group next week 23:04:16 present+ 23:04:24 present+ 23:04:26 present+ 23:04:31 astearns: It will be good to have those items on the agenda. Anything else you want to discuss we should probably bring it up before. If anyone else has tpics for APA please add it to the email thread 23:04:36 astearns: Anything more on that? 23:04:42 AmyCarney: That's all 23:04:49 Topic: Moving scrollbar-gutter to overflow 3 23:05:07 fantasai: Currently in overflow-4 but it's mostly super exploratory stuff that we want to work on one day but not a focus. 23:05:12 CSSWG_LogBot has joined #css 23:05:24 fantasai: scrollbar-gutter is looking at being impl at some point. Make sense to shift to overflow 3 23:05:53 fantasai: Had discussed move to scrollbar, but doesn't style scrollbar itself and concept of scrollbar-gutter is a useful layout concept we'll need to reference. 23:05:55 chris has joined #css 23:05:59 fantasai: I figured make sense to leave in overflow 23:06:01 +1, WFM 23:06:05 astearns: Do you know where overflow 3 is? 23:06:08 rrsagent, here 23:06:08 See https://www.w3.org/2021/08/04-css-irc#T23-06-08 23:06:19 fantasai: Not in CR yet but getting close. most things are actively impl or are impl 23:06:23 florian: Low 10s of open issues 23:06:34 astearns: Any concerns with promoting scrollbar-gutter to L3? 23:06:36 astearns: Obj? 23:06:45 amy_c has joined #css 23:06:46 RESOLVED: promote scrollbar-gutter to L3 23:06:54 Topic: Republish masking-1 as CR Draft 23:06:58 present+ 23:07:02 github: https://github.com/w3c/fxtf-drafts/issues/431#issuecomment-891182920 23:07:15 chris: I'd like to publish a new CR draft 23:07:41 chris: It was pub in 2014. Bunch of technical changes since. Then we can start wide review and pub CR snapshot later 23:07:45 astearns: sgtm. Other comments? 23:07:49 astearns: Obj? 23:08:00 RESOLVED: Republish masking-1 as CR Draft 23:08:11 Topic: [css-color-3] Publish updated Recommendation with Candidate Corrections 23:08:19 github: https://github.com/w3c/csswg-drafts/issues/6486 23:08:40 chris: Long bug with hsl colors. Color 3 has ABC program for that. Report that almost 50% of values are wrong. 23:08:54 chris: Fixed in color 4 by running the JS. Having done that made sense to put in L3. 23:09:27 chris: Also a couple of little changes in ED that I also did as candidate corrections. We can pub and get that moving. Doesn't require directors decision, just decision to publish 23:09:30 astearns: Concerns? 23:09:43 florian: Question- we're positive JS ir right? 23:09:44 chris: Yes 23:09:51 florian: Rest is editorial? 23:09:56 chris: Yes 23:10:09 chris: Removed media from propdef is in as candidate 23:10:17 florian: Sure. process def of editorial is narrow 23:10:36 chris: They're prop corrections that allow you to see in place the change. Proposed corrections have normative force 23:10:49 florian: If parts of spec are editorial you can do them immediately. if they grey 23:10:54 chris: I think it's grey zone 23:10:58 astearns: Other comments? 23:11:12 astearns: Obj to Publish Colors 3 as updated Recommendation with Candidate Corrections 23:11:18 RESOLVED: Publish Colors 3 as updated Recommendation with Candidate Corrections 23:11:39 astearns: Other publishing things? 23:11:42 Topic: [css-highlight-api] Specifying behavior for Highlights involving multiple documents 23:11:49 github: https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-884332586 23:12:00 astearns: dandclark can you lead? 23:12:21 dandclark: This is a rerun of an issue I raised a couple weeks ago. Reached resolution but thought of an issue 23:13:02 dandclark: Summary is that if we have a couple of same domain iframes have a couple of registries and can add range from wrong window. Resolved to make impossible by throwing when you attempt to add highlight registry from another window 23:13:42 dandclark: This is trying to establish invarient where they only have ranges from same window. Issue might be is if I add range from same window and I moved to another window I have violated the invarient and it's not clear what to do 23:14:02 dandclark: No straightfoward way to block unless we check when we move 23:14:29 q+ 23:14:30 q? 23:14:34 dandclark: like to revisit if throwing is right. If we can't maintain this invarient re-open allowing and during painting step they're skipped. 23:14:40 ack TabAtkins 23:15:04 TabAtkins: If we can check what window they're from at painting time I'm not sure why it's problematic to check upon assignemnt to registry 23:15:23 dandclark: We can, but if at time assigned to registry it's correct but then I can take and position in a different window and it's too late to stop 23:15:28 q+ 23:15:31 TabAtkins: Oh, didn't realize range could move like that 23:15:36 dandclark: Codesnip in the issue 23:15:39 https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-884332586 23:15:42 ranges are amazing like that. 23:16:22 florian: I haven't followed this closely, but it reminds me of interaction between ranges and css contain where range had one end outside and one within and the possibility that changing violates containment 23:16:38 florian: Had considered having in dictionary and ignoring it. I don't think we resolved there and it's still open 23:16:40 ack florian 23:16:41 q+ 23:16:41 q- 23:16:41 q+ 23:16:45 jensimmons has joined #css 23:16:49 ack smfr 23:17:06 smfr: Do we need to invent a new kind of range that's live but contained in a single document? Cannot move between docs? 23:17:12 TabAtkins: And restrict to only accept that type? 23:17:27 smfr: Range would associate to that document and throw if you call with a node from different doc? 23:17:37 TabAtkins: But we only allow that new type of range with this API? 23:17:39 smfr: Possibly 23:17:51 TabAtkins: If we didn't restrict not sure what we gain with the new range type 23:18:01 smfr: Yeah, only get benefits if you enforce using the new kind of range 23:18:08 ack sanketj 23:18:30 the css-contain issue is : https://github.com/w3c/csswg-drafts/issues/4598 23:18:45 sanketj: I wanted to echo what florian was saying. Similarities with the contain boundary case where it doesn't make sesne for range boundry to check and it's allowed at paint and we decide then to allow 23:19:21 +1 to what sanketj said :) 23:19:21 sanketj: This should work same where we allow authors to place ranges where they want but when we paint we only paint those on same originating doc as the highlight registry. That's my preferred solution here 23:19:29 q? 23:19:41 +1 for sanketj/florian's solution as well 23:19:57 q+ 23:20:04 astearns: I think I prefer that solution as well. I can imagine this being whack a mole where we restrict things being added and someone comes up with a method of getting a range into a registry we hadn't thought of 23:20:07 q+ 23:20:11 astearns: Seems like it's fitting the problem better 23:20:14 ack Rossen_ 23:20:22 Rossen_: I agree with the path forward. 23:20:57 Rossen_: Before we resolve, sanketj or florian can you remind us what the OM or a11y model behind the ranges? How would they be exposed to assistive tech. xpose collection, only active, etc.? 23:21:10 florian: I think unresolved in spec. Maybe sanketj knows what was explored impl-wise 23:21:36 sanketj: I don't think we've reached exploring how to expose. OM-wise the highlight, range objects are OM types we're working with 23:22:01 Rossen_: I think it would be unfortunate if we reach too far into impl without considering those scenarios. I would suggest to start thinking through these 23:22:12 florian: You're right. It's been known for a while but it's about time we look into it 23:22:20 ack heycam 23:22:53 heycam: Just realized I thinkw e have another instance of this which is selection object from getSelection. I don't remember what happens but maybe we can see what that does and perhaps do the same 23:23:01 astearns: Anyone know what happens for selection? 23:23:39 sanketj: I don't know how selection values update, but nothing blocks from being selected in another document. I'm not sure what happens when it does, though. Nothing stops it from being placed in arbitrary locations 23:23:47 astearns: previous resolution was throw on mismatches 23:24:19 astearns: I'm hearing prop is revert previous and allow any ranges to be added to a registry. At paint time we only use ranges that are with the originating document 23:24:25 q+ 23:24:32 astearns: Any discussion on that prop resolution? 23:24:35 ack dlibby 23:24:51 dlibby: We kept mentioning paint time. Is it more about how properties cascade? Or is it really checking when you paint? 23:25:17 TabAtkins: I suspect it will be some ranges are valid when in right document and painting will only paint valid ranges. And that would let you hook to a11y tools where they only get valid ranges 23:25:36 florian: And the cascade is for set of ranges for whole highlight so some invalid range doesn't change cascade 23:25:40 dlibby: that's right, thanks 23:25:43 astearns: Any more commets? 23:25:53 astearns: Obj? 23:26:04 RESOLVED: revert previous resolution and allow any ranges to be added to a registry. At paint time we only use ranges that are with the originating document 23:26:33 astearns: Thanks for bringing this up again dandclark 23:26:38 Topic: [css-nesting-1] Allow conditional nested rules to adopt context 23:26:53 github: https://github.com/w3c/csswg-drafts/pull/6483#issuecomment-891359090 23:27:30 TabAtkins: currently in nesting we have text to let you nest conditional into style. But we don't change the interior of nested media rule. Only accepts more rules. 23:27:53 TabAtkins: If all you wanted to do is set a particular prop when a media matches you have to write a rule with a & as a selector to let you put property 23:28:25 TabAtkins: Prop is extend mixture of properties to also apply to nested conditional rules so if it's directly nested inside a conditional you can put it in 23:28:31 TabAtkins: Example in issue 23:28:33 .foo { 23:28:33 display: grid; 23:28:33 23:28:33 @media (orientation: landscape) { 23:28:33 grid-auto-flow: column; 23:28:34 } 23:28:34 } 23:28:37 q+ 23:28:46 astearns: Adam put current and proposed. Would both work or only proposed? 23:29:03 TabAtkins: Both would work. Putting full rules is allow, but not required when you're only styling element from outside 23:29:09 The proposed syntax is *far* better for Authors. Having both work is a good idea, for those who think that's the only way it will work. 23:29:15 ack heycam 23:29:27 heycam: That proposed one you have @media as direct child. What would happen if you used & in some other rule? 23:29:55 TabAtkins: That's spec already. Contents of nest conditional rules do inherit nesting selector context. Their & resolves to the nearest parent style rule 23:30:06 TabAtkins: The other example shows how you would write it today with an & 23:30:10 .foo { 23:30:10 display: grid; 23:30:10 23:30:10 @media (orientation: landscape) { 23:30:10 & { 23:30:11 grid-auto-flow: column; 23:30:11 } 23:30:11 } 23:30:12 } 23:30:28 TabAtkins: That will continue to work and & inherits content from the outside 23:30:33 astearns: See support from jensimmons 23:30:36 astearns: Other comments? 23:30:48 astearns: Anyone against allowing or concerns about allowing this? 23:31:03 astearns: Prop: Not require the & syntax inside? 23:31:16 TabAtkins: I'll write in IRC 23:31:31 proposed: conditionals nested into style rules have their contents parsed the same as style rules (so raw properties are allowed) 23:31:44 astearns: Any objections? 23:31:51 RESOLVED: conditionals nested into style rules have their contents parsed the same as style rules (so raw properties are allowed) 23:32:21 TabAtkins: That was last major issue before FPWD so we will be publishing very soon (we have the resolution to publish) 23:32:24 Topic: [css-sizing-3] compressible elements with aspect ratio 23:32:35 github: https://github.com/w3c/csswg-drafts/issues/6341 23:32:41 present+ 23:33:30 iank_: The context for this is that when we've got compressible element. example min size we look at min width. If you've got min width 50px that's the min size. What nobody does with a-r is transfer min-height 23:33:57 iank_: Can get weird min width 50x and min height 100 px and a-r of 1:1 you end up with a rectangle. Proposal is allow the transfer 23:34:13 iank_: Interesting is what to do when can resolve min-height of 100%. That's what fantasai and I have been talking about 23:34:38 iank_: I'm on side of resolving % since that matches what we do with height and I think leads to better behavior. I think fantasai has concerns with that 23:34:45 fantasai: I read your reply, but haven't thought through it 23:35:05 q+ 23:35:11 fantasai: My concern is we have weird stuff with grid and flex with cyclic aspect of grid in particular. Don't want to resolve % in a way that causes issues 23:35:22 fantasai: Pretty sure we should transfer fixed sizes. Less sure on % 23:35:53 fantasai: I didn't notice you responding to is your table is assymetric between 2 axis and block size resolves and definite. Why not both definite or both 0? 23:36:02 s/didn't/did 23:36:18 iank_: That's what happens in the min/max size contributions. Resolve if it's definite and that transfers but inline axis is cyclic. 23:36:24 fantasai: I think symmetric is better 23:36:35 iank_: I don't think so. by def it's not symmertirc 23:36:43 fantasai: If height is resolved but not width it's weird 23:36:49 iank_: That's what happens, though 23:36:54 fantasai: % usually resolves in width 23:37:23 iank_: Explicitly for min/max. For inline axis they're cyclic. For block we do resolve when poss. That's how min/max works in all browsers today 23:37:34 astearns: Sounds like on that concern we should have test cases 23:37:54 iank_: Most of the test cases I've written. I can give example of how asymmetric today 23:38:11 fantasai: I think we can agree if it's fixed size it should transfer. Resolve on that and keep discussing %? 23:38:14 ack jensimmons 23:38:40 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9536 23:38:52 jensimmons: Question is about use cases and not %. I have a system where an image is placed and I don't know a-r. I put on it max-wdith 100%. So that would be usually 100% but blow up if it's big. 23:39:11 jensimmons: I also do max height of 100dvh 23:39:47 jensimmons: So they I want it to be no bigger than 100vh if it's quite tall and it could shrink down a bunch becase of it's a-r. 23:39:53 jensimmons: Is that the intention of this? 23:40:51 fantasai: or that case nothing changes. Case is what happens if you have that code and a min-height or a min-width. How does that interact with your max if you put it in a shrink to fix box. What size will it end up being. In a min-content grid column current code allows the image to shrink to 0 even though has an intrinsic size 23:41:25 fantasai: If you set a min-width we won't shrink to 0. If we have a min-height instead do we transfer the min-height across the a-r to prevent collapsing to 0. That's the question here 23:41:38 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9537 23:42:09 fantasai: If you give it a min-height of 50px in a shrink to fix does it transfer across and have a min-width. The question iank_ has is if i set min-height 10% what do we do there 23:42:31 iank_: jensimmons I just put in a link to a case 23:42:57 iank_: fantasai I put in case 9536 to show the asymmetry we have today 23:43:32 astearns: We could resolve for the definite case. Or resolve for both definite and % and leave to fantasai to determine if % is incorrect? 23:44:07 fantasai: I'm not sure I understand the asymm issue. happy to resolve on fixed 23:44:19 astearns: Resolve on just the fixed today, then I'd want to come back next week for % 23:44:20 fantasai: Sure 23:45:02 iank_: Prop: When we have a compressible elements also transfer a fixed min block size through the aspect-ratio to become a min inline size 23:45:11 astearns: Any further discussion? 23:45:17 astearns: Objections? 23:45:28 RESOLVED: When we have a compressible elements also transfer a fixed min block size through the aspect-ratio to become a min inline size 23:45:37 astearns: We'll come back next week for % case 23:45:47 Topic: [css-overflow-3] Clarify padding-bottom in overflow content 23:45:56 github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-891194919 23:46:29 iank_: I wasn't around last week. We have data that weren't not as compat constrained as we thought. So I'd like to undo resolution 23:47:04 iank_: We've been slowly changing our behavior. most recently for flex to consider inline and block end padding. Did this in Chrome 91 which has been out for 2 months. Haven't received any bug reports 23:47:10 fantasai: That's in the spec already 23:47:15 florian: Resolution is only block layout 23:47:23 iank_: Getting to that. As part of this we had use counters 23:47:37 iank_: 1 for if we change behavior for if flexbox already scrolled 23:48:18 iank_: [missed] If block it's already scrollable that's less than the change we did for flexbox. So if the block scrollable element is scrollable in that axis we can add the end padding 23:49:01 iank_: Second is that we're making something not previously scrollable in inline direction. looking at data might be web compat as well but need to investigate more. One library is causing use counter to be relatively high and I need to research more. May be one trick we need to do 23:49:21 florian: If I got that right you say that even w/o adding padding we were scrollable that case is safe? And looking at remaining? 23:49:23 iank_: Coorrect 23:49:35 florian: How long to get data? I think you're right that if we can do it it's preferable 23:49:41 iank_: That's why i want to undo previous 23:49:45 florian: Or at least hold 23:50:16 q+ 23:50:17 iank_: If something is scrollable and we add inline-end padding that's fine. Should revert that. we're prepared to try and we can report back. We're doing this slowly and watching metrics 23:50:33 iank_: I think still might be possible to do it universally. one trick we might need to do 23:50:37 ack dholbert 23:51:11 dholbert: The bit about if things are already scrollable makes me slightly uneasy. Are you saying whether or not we include inline padding depends on if we're overflowing and what happens to content changes where we wouldn't be 23:51:12 +1 to concern if we can only do this for already-scrollable things 23:51:53 iank_: Today Chrome calc both overflow areas and return one or the other. With these 2 overflow areas can compare to padding rect and see this is already scrollable so we could return slightly larger one. 23:52:09 iank_: If it became dynamic and it didn't have overflow we would stp including inline end padding 23:52:36 dholbert: And if it would if you inlcude inline end and wouldn't if you didn't? Or if you weren't in that scenario and content is deleted do we suddenly not include the inline padding? 23:52:38 iank_: Correct 23:52:54 florian: Prop we resolve on this, leave rest, and you tell us when you know? Or leave whole undefined? 23:53:25 iank_: Prob easiest to leave undefined at the moment with an explanation. I think might be able to do universal but I need more use counters 23:53:39 florian: I suspect it's worth waiting for if it's a reasonable timeframe. It's a better behavior 23:53:56 iank_: Yeah. I need to add use counters to detect for this library to see if we break 23:54:07 I'm ok with leaving this specific case -- inline-end padding within block container scroller -- to be undefined for now 23:54:09 florian: Do we need to be concerned about different compat concerns for other browsers? 23:54:20 iank_: Not for inline. I would have been more concerned about block 23:54:39 iank_: Example timeframe for the data is 3-6 months 23:54:48 astearns: Is that reasonable timeframe? 23:54:55 florian: I guess. Was hoping for CR shorter 23:55:02 iank_: Issue has been open for 5 years 23:55:11 astearns: And we have reverted resolutions in the past too 23:55:30 astearns: My understanding is that we are gaining consensus on undo previous resolution and leave the issue open until more data 23:55:40 fantasai: Happy to leave undefined but I don't think needs to block CR 23:55:45 astearns: Undefined in draft? 23:55:58 florian: It's an issue. We'll mark as issue and undefined 23:56:14 astearns: Prop: Undo previous resolution. Explicitly mark as undefined in the draft for now 23:56:16 astearns: Obj? 23:56:23 RESOLVED: Undo previous resolution. Explicitly mark as undefined in the draft for now 23:56:56 s/mark/mark inline-end padding of block container scrollers/ 23:57:01 iank_: What I'm going to do next is change behavior to include inline end padding if it was scrollable and I'll add another use counter for the case I was more worried about. I'll report back in a couple months 23:57:22 Topic: [css-transforms] After #6320 there's no way to get an identity transform for interpolation of perspective 23:57:31 github: https://github.com/w3c/csswg-drafts/issues/6488 23:58:11 TabAtkins: Previously we had odd behavior where perspective funt with 0 treated as no perspective. That was null transform. 23:58:42 TabAtkins: A little while back resolved that's weird and silly. perspective of 0 px is your eyes are on he screen and that's different. We clampped to a floor. You can't say 0 anymore 23:59:31 TabAtkins: No we have no way to say no perspective applied. That means infinite. Possibly this can be done with infinity keyword in calc. A bit awk and implies infinite link is stored internally or the max value triggers this 23:59:53 TabAtkins: We probably want an actual preserved value. Proposal is allow perspective to take keyword infinity directly 00:00:08 TabAtkins: That's the no transform, does 0 stuff 00:00:17 astearns: Reasonable to me. Any concerns? 00:00:25 smfr: Do we have that keyword? 00:00:31 florian: How is it different from none 00:00:59 TabAtkins: None is a null transform list. If you need to match 2 lists and want 2nd list to not do anything you cannot write that. You can't put none in the middle of a transform list 00:01:10 TabAtkins: I'm not sure what you mean smfr 00:01:30 smfr: animation iteration takes keyword infinite. Are there other places in CSS where this would be reasonable or is this special 00:02:15 TabAtkins: I think special case b/c any other place where....well...any place where infinity might be meaningful we should have a keyword indicating that behavior rather than fallback to calc constant b/c that is clamped to a numeric value 00:02:34 smfr: What happens when interpolate between infinity and 100 00:03:01 TabAtkins: Well defined. infinite is identiy matrix. It has to b/c before this perspective 0 was the infinite, it was just the wrong way to write it 00:03:11 q? 00:03:13 astearns: We're over time. I'm guessing we should punt to next week and resolve 00:03:17 smfr: Sounds fine 00:03:19 TabAtkins: Fine 00:03:22 Topic: end 00:03:32 astearns: Thanks to everyone for calling in. We'll take this up next week 00:03:38 zakim, end meeting 00:03:38 As of this point the attendees have been argyle, dael, dholbert, TYLin, Rossen_, dlibby, fantasai, alisonmaher, mwoodrow, smfr, heycam, dandclark, plinss, sanketj, amy_c, chris 00:03:41 RRSAgent, please draft minutes v2 00:03:41 I have made the request to generate https://www.w3.org/2021/08/04-css-minutes.html Zakim 00:03:44 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 00:03:49 Zakim has left #css 01:57:13 CSSWG_LogBot_ has joined #css 02:08:38 projector has joined #css 02:09:08 leaverou has joined #css 02:09:38 Rossen has joined #css 02:10:08 shans has joined #css 02:10:39 sylvaing has joined #css