17:06:19 RRSAgent has joined #css 17:06:23 logging to https://www.w3.org/2025/11/26-css-irc 17:06:23 RRSAgent, make logs Public 17:06:24 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:06:27 ... do they have editors? 17:06:57 dbaron: to use transforms as an example, they're all minor changes 17:07:15 present+ 17:07:16 SebastianZ: transitions-1 didn't get many substancial changes 17:07:29 ... but others did have several big changes also backed by resolutions 17:07:47 florian: in general good to publish, but it gives a signal that what is in them might make sense 17:08:02 ... just publishing without knowing if it is in a good state would be concerning 17:08:16 SebastianZ: I tried to check commit messages for the changes recorded 17:08:38 florian: what you've done is great, buy we need to make sure every spec has an editor paying attention so we know if they're OK 17:08:46 SebastianZ: many of the editors are here in the meeting 17:08:58 astearns: we have editors here except for tables 17:09:10 ChrisL: that prevents us from publishing tables 17:09:30 astearns: shall we resolve to publish content, logical and transitions? 17:09:46 PROPOSED: New versions of content-3, logical-1 and transitions-1 17:09:54 RESOLVED: New versions of content-3, logical-1 and transitions-1 17:10:09 astearns: any volunteers for editors of tables? 17:10:42 RESOLVED: appointing keithamus as editor of tables-3 17:10:55 astearns: anyone who would like to help keith is welcome 17:11:07 ... we can publish it as soon as keithamus is editor 17:11:14 I'd be happy to help keithamus but not sure that needs necessarily to make me an editor :) 17:11:16 ChrisL: put old editors as former editors 17:11:27 astearns: thank you to SebastianZ 17:11:47 github-bot, topic https://github.com/w3c/csswg-drafts/issues/12598 17:11:47 Topic: [css-shapes-1] Proposal: Option for the radii of `round` on `` to resolve percentages against the rectangle itself instead of the reference box 17:11:47 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12598 17:12:08 TabAtkins: request from a user to allow % in border-radius of basic shapes 17:12:16 ... to calc % off of the rectangle you specify 17:12:46 ... right now they resolve off the size of the element that's being styled 17:13:02 ... this is a good behavuour but means % border-radius do not act like how they do on a element 17:13:13 ... so you can't set 25% and get a rectangle with straight segments 17:13:22 q+ 17:13:23 ... this might be longer than you expect and give you a full ellipse 17:13:41 ... so request to make it relative to the size of the defined rectangle 17:13:52 ... they suggest putting a self suffix on the round keyword 17:13:53 q+ 17:14:04 astearns: any other keywords? 17:14:15 ack noamr 17:14:16 TabAtkins: we have the round keyword, and presumsbly other variants 17:14:56 noamr: this is a problem when % can come from calc and vars from outside 17:15:11 ... all of those things end up being x% smooshed together from various sources 17:15:22 ... we have problem with arc with direction agnostic radius 17:15:32 ... you can't serialise back to the computed value 17:15:42 ... this has come with shape fn as well 17:15:55 ... anything with % relative to the shape rather than the box 17:16:03 ... now it's a length % from something else 17:16:08 ... so we need to consider that 17:16:16 TabAtkins: I don't understand the problem 17:16:23 ... it's a full switch with two types of percentages 17:16:31 ... it shouldn't change the timing of how we interpret them 17:16:41 ... you interpret as soon as you know how to interpret the sides 17:17:05 noamr: if you have calc with % from everywhere, you say they refer to the rect() rather than to the element; that would be confusing 17:17:08 castastrophe has joined #css 17:17:15 ... if you pass. 50% from somewhere, you change the meaning 17:17:34 ... in the past it might have meant something else, could be confusing to change the meaning of % 17:17:50 TabAtkins: you can already change the meaning at the point of use. you can change ??? as well 17:18:08 q+ 17:18:08 astearns: no different to using a % in two different properties that eval % in different ways 17:18:17 ... we might need this kind of switch in other fns 17:18:29 q- 17:18:38 noamr: it came up with other fns. usually the reference box. not just this issue but it's related 17:18:54 astearns: if there are other places where we have switches, it would be good to do it consistently 17:19:00 ... -self is good 17:19:05 ack emilio 17:19:20 emilio: I wasn't sure what was the issue with the independent computed value 17:19:45 ... it's weird. part of the issue is you can specify them in the input fn 17:20:07 ... if we want to do this, I'm not objecting, the weird thing is making only one of the % relative to the inset modfied box 17:20:15 ... that makes it very round specific 17:20:25 TabAtkins: use case is to make it act like border-radius 17:20:32 emilio: how often does it come up? 17:20:46 ... you can work around it with calc, but repeating the insets 17:20:49 ... it gets weird 17:20:57 ... but I think you can do it 17:21:14 ... weird that % in the same function is relative to something else 17:21:16 instead of 10%, you'd write calc((100% - TOP - BOTTOM) * .1), pretty non-trivial 17:22:03 astearns: given there's a workaround, maybe take back to the issue and do more investigation about the rest of the basic shape functions to see where else we want to do it 17:22:10 emilio: I think it's specific to round 17:22:16 ... I won't object to doing round-self 17:22:27 ... but I don't think it generalises well to other shape fns 17:22:47 q+ 17:22:51 astearns: I'd like to get opinion to the issue author to see if the workaround meets their needs or if it's non-trivial 17:22:59 ack noamr 17:23:02 noamr: also applies when you have curves 17:23:12 ... and you want the points to be % of the rectangle 17:23:26 ... no matter how big the rect is, it's similar to this rounding thing 17:23:50 astearns: I wonder if there's a simpler design that is a self-size function where you tag a % 17:24:08 ... and it could make it clear that that's a special percentage. could be added to other functions 17:24:24 ... so take back to the issue saying we're not against it, but we want more investigation 17:24:40 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12651 17:24:40 Topic: [CSS-UI] caret-shape: block/underscore and zero width space 17:24:40 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12651 17:25:10 florian: Spec says a thing, Igalia did in chrome what the spec says 17:25:21 ... with carot property, we can change the shape to underscore or block 17:25:31 ... unlike the bar, they have the width of the next character 17:25:44 ... but in unicode, some chars are invisible or very thin 17:25:51 ... in that case, width is 1ch 17:26:07 q+ 17:26:10 ... but question is: does that apply if the carot is in the middle of the line 17:26:24 q+ 17:26:50 ... and if after the carot is an invisible char and then more visible chars, if the carot is 1ch wide, it appears to be after the invisible thing 17:27:01 ... one suggestion was to make the carot 1px so you don't confuse it 17:27:15 ... so for now, the spec says it's 1ch when the next is invisible 17:27:17 s/carot/caret 17:27:20 ... should we do something else? 17:27:32 ack schenney 17:27:34 ... does anyone have a strong case for something better? 17:28:18 schenney: thinking from user perpsective. say you've got char with non visible space, the issue isdeterming if the caret is before or after the invisible char 17:28:28 ... if you are copying something, it probably doesn't matter 17:28:35 ... it matters when you're trying to delete something 17:28:50 ... and it seems to me that is an acceptable level of confusion 17:28:56 q+ 17:29:06 ack TabAtkins 17:29:17 TabAtkins: I sympathise with florian's concern 17:29:30 ... but I also sympathise with a 1px underscore being hard to see 17:29:37 ... just one dot! 17:29:54 ... so for that usability sake, the observability of the caret is more important 17:30:01 q+ 17:30:07 ... text editing invisible characters is always confusing 17:30:32 ... so we need to make sure the caret is always visible. I have a weak preference that 1ch caret is still the most reasonable 17:30:42 astearns: agreed 17:31:09 "char" is "char", it being short for "character" doesn't matter 17:31:16 ... I wonder if it would help to take this scenario and if it happens in the middle of the line, to center the caret 17:31:22 ack florian 17:31:25 ack astearns 17:31:35 florian: we could experiment and see what user testing reacts to 17:31:50 ... like people have said, it's confusing editing these characters anyway 17:32:10 ... so maybe this is an interesting idea, but i wouldn't go ahead with it without user testing 17:32:23 astearns: I'm hearing consensus to close the issue no change? 17:32:27 +1 17:32:34 RESOLVED: close issue, no change 17:32:48 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11977 17:32:48 Topic: [css-multicol-2] `column-height` and nested fragmentation 17:32:48 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11977 17:33:18 rachelandrew: in situations where you set a col height and you're in fragmentations 17:33:27 ... in last meeting, we had a resolution 17:33:43 ... it's in the issue, when col height is set, only when no rows fit, use multi col pagination rules 17:33:57 ... otherwise fit as many rows as you can in fragment, and then move to next ????. 17:34:16 ... ?? had a look and had problem with spanners in outer fragment context 17:34:28 s/??/Morten/ 17:34:40 ... we're settling on how rows fragment regular blocks across fragment containers 17:34:49 s/????/column 17:35:13 ... and then what's not spent in col height is used for subsequent fragment containersa 17:35:27 ... and that would make the rows behave like break-inside avoid 17:35:39 ... now i think florian agrees with direction 17:35:55 florian: I think I'm describing the same thing so they're probably the same 17:36:10 ... I have follow up thoughts, but not contradicting what you said 17:36:22 ... only a small twist 17:36:37 astearns: proposing to specify rows behave like break-inside avoid 17:36:57 ... pretty much 17:37:15 florian: there's also how these react to force breaks 17:37:50 RESOLVED: specify rows are pretty much like break-inside avoid in a fragmentation context 17:38:04 florian: as you write down the details of 'pretty much' 17:38:30 ... earlier, rachelandrew said we'd fit as many rows as fits in the frsg container, and any that don't move to the next 17:38:40 ... but taking into account that sizes are variable 17:39:06 ... if you move to the first one that doesn't fit to the fragment container, it might not fit again because it's too small. so in that case, don't move it. let it overflow 17:39:18 ... but this is food for thought as you write the details 17:39:32 github-bot, take up https://github.com/w3c/csswg-drafts/issues/13037 17:39:32 Topic: [css-borders-4] Rendering of outset shadow spread with concave 50% corner-shapes 17:39:32 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13037 17:39:43 https://github.com/w3c/csswg-drafts/issues/13037#issuecomment-3552123049 17:39:47 noamr: this is a continuation of shadow conversation 17:39:54 ... this comment shows the rendering 17:39:56 s/let it overflow/let it there and break it/ 17:40:15 ... of how shapes spread to a shadow when there is a concave corner shape 17:40:24 ... the current spec is wrong 17:40:44 ... I want to resolve on having a rendering that looks like the [image in the issue] 17:40:55 ... clipping them to expand to the border rect 17:41:12 ... it doesn't do what mine does. it only extends to the external border rect 17:41:28 ... there seemed to be consensus on the issue, but I wanted to check here 17:42:03 ... so to resolve on the one tile clip 17:42:14 ... it doesn't extend to infinity 17:42:23 q+ 17:42:30 ... we don't want the corner shape to make sharp corners have a round shadow 17:42:30 q+ 17:42:33 ack smfr 17:42:47 smfr: for impl, do you have to compute the path as if it was ?????. 17:43:23 noamr: it's quite simple. it extends a tangent that starts from the control point and continues to the outer rect. 17:43:37 ... it's actually a straight line that continues the ??. 17:43:47 smfr: is the clip always axis aligned? 17:43:50 noamr: yes 17:44:05 ... I'll put a more precise algorithm in the spec, probably 17:44:08 present+ 17:44:09 ack SebastianZ 17:44:20 SebastianZ: I just want to iterate on what I wrote in the issue 17:44:27 ... I believe rounded version is the best one 17:44:33 ... i would be fine with all three, though 17:44:52 astearns: I also have preference for that but won't object 17:45:27 smfr: the round option is a behaviour change for existing box-shadow with offset, so we can't do it 17:45:36 present+ 17:45:52 PROPOSED: to specify clip behavour 17:45:59 RESOLVED: specify clip behaviour 17:46:19 github-bot, topic https://github.com/w3c/csswg-drafts/issues/13079 17:46:19 Topic: [css-anchor-position] Scrollable Containing Block + Fallbacks/`position-visibility: no-overflow` & visibility of positioned element to users 17:46:19 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13079 17:46:44 dshin: for certain cases with default anchors 17:46:45 q+ 17:47:15 ... as a result, I noticed when we have higher overscroll area, when you have a fallback, the fallback doesn't trigger when you scroll something so that the positioned element isn't visible any more 17:47:26 ... it seems to defeat the purpose of having these fallbacka 17:47:37 ... it matters to authors that users can see it 17:48:02 ... the purpose of scroll-contained-block was that when you make the position ara grid 17:48:29 ... when you use it for an anchor that is initially outside the viewport, the grid will be 0 size 17:48:40 ... so you'll have items that are 0 size which doesn't make sense 17:48:53 ack TabAtkins 17:48:53 ... but i don't think we can entirely get rid of it 17:49:07 TabAtkins: the issue here is one we recognise 17:49:12 ... problem is different use cases 17:49:38 ... if it's just a layout primative, you just want the scrollable containing block 17:49:51 ... but if using as a popover, you want the fixed containing block, not the local 17:50:00 ... these are two extremely different use cases 17:50:07 ... with the behaviour and sizing 17:50:18 ... so there is no way to magically determine the default 17:50:27 ... resolution before lets authors opt into one 17:50:41 ... and we just needed to choose one or the other as the default 17:51:10 ... current behaviour is largely worthless but it does live inside the scrollable area 17:51:14 q+ 17:51:15 ... so we thought it was better to use that 17:51:23 astearns: what is the switch? 17:51:45 TabAtkins: add to the position properrty another keyword to choose which containing block you use, local, scrollable or fixed 17:52:09 ... for legacy reasons, it didn't matter when we first decided, local is the default 17:52:17 ... so as soon as you start scrolling, that is off the screen 17:52:29 ... abspos didn't care about that much, but anchor pos does 17:52:40 ... they're on opposite sides of the spectrum 17:52:40 ack emilio 17:52:59 emilio: the fixed containing block would still cause the popup to scroll along with the anchor, right? 17:53:19 TabAtkins: yes, would still scroll, but would treat the scroll port as its overflow bounds 17:53:50 emilio: so position-visibility do interact badly with this and it's not worth fixing with the scroll containing block bounds. is that what you mean? 17:54:28 ... dshin was proposing using the fixed containing block of the scroller so that the visibility checks work as they would otherwise 17:54:54 ... assuming you want the layout behaviour of the scrollable containing block, is there any reason for using it as a fallback mechanism 17:55:41 TabAtkins: so there is behaviour where the scrollable containing block-- the root scroller, if you use this as layout primative, it means if the anchor is off screen, you sitll get the behaviour you want 17:55:43 q+ 17:56:01 ... if you use the fixed containing block, you're just outside of the containing block below the fold 17:56:22 ... and you will go through your fallbacks because you're outside of the ?? by default 17:56:38 ... but yes there's two use cases and you can't satisfy both at the same time. 17:56:45 ... so we need to let authors opt in 17:56:48 s/??/CB/ 17:56:50 ack dshin 17:56:57 dshin: thank you emilio that is my position 17:57:34 ... so TabAtkins you say if you want the scroll containing block, you wouldn't want the fallback to trigger 17:58:01 s/you wouldn't want// 17:58:11 The fallback wouldn't ever trigger 17:58:26 TabAtkins: the fallback would trigger in cases 17:58:47 ... so if you put a caption below a table, if that table is at the bottom of the sscrollable area, it would overflow the scrollable area 17:58:56 ... or visa versa if it's at the top 17:59:20 ... it triggers less often, it requires the element to be near the edges, but it's only needed for the layout related cases, not the popover cases 17:59:48 dshin: authors who use it for layout, they don't care that it's not visible for authors, just that it's laid out in the right position? 17:59:57 TabAtkins: correct. so even if they're off screen, does it matter? 18:00:10 ... you don't need to go through your fallbacks because it's below the fold 18:00:30 ... but with a popup, you only trigger it if the anchor is on screen, different use case 18:00:50 dshin: so we think if people want to use it for layout, people won't care about visibility? 18:01:00 ... as long as people can choose, that seems OK 18:01:23 astearns: are you OK with us closing this issue, or should we work through the cases with the switch? 18:01:31 dshin: yes I will investigate 18:01:36 astearns: OK! 18:01:44 Topic: end 18:48:34 Penny has joined #css 20:56:28 Penny has joined #css 23:22:44 Penny has joined #css 23:32:13 karlcow_ has joined #css 23:42:26 karlcow__ has joined #css