14:56:47 RRSAgent has joined #css 14:56:51 logging to https://www.w3.org/2026/04/16-css-irc 14:56:51 RRSAgent, make logs Public 14:56:52 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:00:54 lwarlow has joined #css 15:01:55 flackr has joined #css 15:02:05 present+ 15:02:09 present+ 15:02:24 jarhar has joined #css 15:02:24 present+ 15:02:47 masonf has joined #css 15:02:53 present+ 15:04:14 Present+ 15:04:15 present+ 15:04:15 present+ 15:04:29 zcorpan has joined #css 15:05:23 present+ 15:06:00 github-bot, take up https://github.com/whatwg/html/issues/12273 15:06:00 Topic: Overscroll areas via command=toggle-overscroll 15:06:00 OK, I'll post this discussion to https://github.com/whatwg/html/issues/12273 15:07:07 vmpstr: *gives intro to overscroll areas* 15:08:12 JohnJansen_ has joined #CSS 15:08:13 flackr: we started this as a css feature, and based on feedback at tpac we changed it to an html attribute which seems to have addressed some concerns 15:09:50 denkeni has joined #css 15:09:53 flackr: *gives demo of overscroll areas* 15:10:20 can we get the link to these demos? 15:11:00 https://flackr.github.io/web-demos/html/overscrollcontainer/ 15:11:31 astearns: i didnt see a way to delete without the scroll gesture in the last demo 15:11:52 flackr: when i was building that demo i was looking at what the native gmail app does, and they use actions. theres additional commands associated with each item 15:11:58 flackr: the only stop in gmail is a single entry for the email 15:12:07 flackr: you can swipe up and down with a screen reader to iterate actions 15:12:11 q+ 15:12:34 flackr: with that in mind, we are pursuing an approach where an overscroll area would add an implicit action to the container its attached to, and that way screen reader users can access those 15:12:41 flackr: in this case, the container is the email 15:12:48 Kind of like this pattern? https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-actions/ 15:12:49 astearns: this would require AT that understands this implicit action? 15:13:03 flackr: its a common thing that is already done for native apps on android, but yes it would require that 15:13:14 flackr: the expectation in these designs is that these are shortcuts to access things 15:13:19 flackr: that you would have other ways of doing 15:13:38 astearns: im wondering if theres a way of designing this such that having a different way to get to the action is enforced 15:13:58 astearns: id rather the design allows for this to be an extra way to get to an action as opposed to relying on authors to ensure there are multiple ways to get to the action 15:14:07 flackr: if a screenreader supports actions then we could support that though the actions 15:14:44 vmpstr: this is an ongoing discussion at openui. originally it was proposed that a button would be mandatory, and of course you could still hide the button. we are slowly moving away from that to say what if we dont need a button and how do we ensure this is still accessible 15:14:53 vmpstr: theres no hard decisions made yet, but thats the stage we're at 15:15:08 flackr: we can easily shift to a model, any solution 15:15:08 q? 15:15:11 ack lwarlow 15:15:18 q+ 15:15:28 lwarlow: when you say actions, is that like the aria actions type thing? where its exposed to AT. in that case its well supported across the board 15:15:30 flackr: yes 15:15:43 lwarlow: that works for screen readers and obviously if youve got an ability to scroll the container then you can 15:15:54 lwarlow: if a touch screen user is using voice control i dont know if it would work 15:16:00 lwarlow: unless voice control exposes the actions 15:16:10 lwarlow: that might be one area where the design needs thinking about 15:16:18 lwarlow: even if its not enforced, guidance to think about this scenario 15:16:25 lwarlow: i think not relying on the button probably makes more sense 15:16:35 lwarlow: because you can still hide it 15:16:54 lwarlow: for the bottom sheet one, the bottom sheet there is that a dialog? 15:17:39 flackr: this isnt overscroll areas. there is an overscroll area at the top that is basically just a dismiss action. all of this is just a regular dialog element 15:18:04 lwarlow: sometimes you have just the handle you can swipe up 15:18:07 flackr: you could make that 15:18:18 ack keithamus 15:18:49 keithamus: accessible isnt just the accessibility tree, i want to make sure were making a design that is flexible to many modalities of input, including motor impairment with sticky keys and people who cant use swipe gestures 15:19:01 keithamus: enforcing a button helps with that, even if not everyone is going to make the button visible 15:19:10 keithamus: if we can offer this pit of success where people at least have to think about it 15:19:17 q+ 15:19:19 keithamus: im not necessarily saying that one design is good and one is bad 15:19:37 flackr: we did start with button required approach. it was very awkward to create it for the gmail example and its not what gmail actually does 15:19:43 flackr: devrel said that the button is awful 15:20:11 keithamus: i could imagine the pushback, and i would challenge them and wonder whether theres another way to do it. i wonder if their keyboard behavior works to avoid swipe 15:20:18 keithamus: could we enforce a keyboard behavior for it? 15:20:34 keithamus: i understand that adding a bunch of html to do this thing is probably a poor experience 15:20:48 ack lwarlow 15:21:07 lwarlow: because this is an overscroll area rather than part of a scroll container itself, can you use the arrow keys and keyboard to scroll into it? i would guess no? 15:21:15 flackr: its kind of a what do you think it should do? our intuition was no 15:21:29 lwarlow: for the gmail example, if you focus on the email and press the arrow then it slides across 15:21:35 flackr: pull to refresh was a case where that would be bad 15:21:46 lwarlow: menu that comes in from the side probably doesnt make sense with an arrow key 15:21:53 flackr: this made sense for direct interactions with the page 15:22:04 lwarlow: if you have focusable content within it can you get into it with tab or is it inert when its closed 15:22:08 flackr: we intend to make it inert when closed 15:22:16 lwarlow: i wonder if you could make it a focus group that way 15:22:24 lwarlow: that probably needs more thinking about how keyboard users can get in there 15:22:36 lwarlow: you might have screen readers covered, but touch only or keyboard only might suffer 15:22:42 lwarlow: maybe keyboard needs a way to trigger actions 15:22:59 flackr: we wanted to start prototyping this in html 15:23:05 vmpstr: in the spec 15:23:12 vmpstr: thats the goal, is to have a pr at some point 15:23:26 vmpstr: i dont know if we need to resolve on anything 15:23:36 masonf: can we do whatwg stage 1 here? 15:24:00 https://whatwg.org/stages 15:24:06 cwilso: stage 1 is basically acceptance that theres interest in looking at the problem 15:24:14 astearns: does it require buy in from more than 1 implementor? 15:24:18 astearns: or no objections? 15:24:27 lwarlow: whatwg is interested, doesnt say specific implementors 15:24:49 cwilso: there has to be an explainer and there has to be consensus that whatwg is interested in looking in the problem space, and at least one implementor interested in prototyping 15:25:02 cwilso: doesnt actually mean that the problem is solvable or that this solution is the right one 15:25:12 cwilso: lets have the conversation, doesnt mean that the conversation will lead anywhere 15:25:36 zcorpan: just file an issue in whatwg and then we can bring it up in whatnot 15:25:50 keithamus: the question is whether this is an applicable forum for applying the stage 15:25:57 keithamus: it seems like theres enough of us here to do that 15:26:03 keithamus: im struggling to find a reason not to do that 15:31:23 q+ 15:31:50 q+ 15:32:38 ack JohnJansen_ 15:33:04 ack cwilso 15:35:59 *long discussion about stages* 15:37:39 everyone agrees to move this to stage 1 15:37:47 github-bot, take up https://github.com/w3c/csswg-drafts/issues/13594 15:37:47 Topic: [selectors][css-position-4] `:modal` pseudo-class needs to account for top layer exit animations 15:37:47 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13594 15:38:15 topic: none 15:38:57 github-bot, take up https://github.com/whatwg/html/issues/12286 15:38:58 Topic: outline and ::picker(select) 15:38:58 OK, I'll post this discussion to https://github.com/whatwg/html/issues/12286 15:39:46 annevk: *gives intro* 15:40:40 The CSSwg issue for the proposed inset value: https://github.com/w3c/csswg-drafts/issues/13765 15:40:56 RRSAgent, please draft minutes v2 15:40:58 I have made the request to generate https://www.w3.org/2026/04/16-css-minutes.html keithamus 15:41:40 q+ 15:42:04 ack lwarlow 15:42:16 lwarlow: i agree, i think that the inset value makes sense and solves the problem quite neatly 15:42:30 lwarlow: i can see that there could be issues in certain cases where the outline might end up clipping hte content of whatever has the outline 15:42:36 lwarlow: for options that wont be an issue because of the padding 15:42:48 lwarlow: if we use it for other things in the future then you can account for tiny bit of padding somewhere 15:43:03 lwarlow: would it compute to the inset keyword? 15:43:18 Ship it 15:43:18 annevk: yeah. currently in webkit it doesnt because were trying to hide it. if we standardize it then it should compute as a keyword 15:43:55 astearns: there hasnt been any discussion on the css issue yet. the first thing that comes to my mind, if we have this keyword, its now something that authors can use everywhere. is that going to cause any issues? 15:44:20 annevk: its the same as if they took the width value, negated it, and put it on outline-offset. its alreayd possible. its only really novel for auto because for auto you dont know the width 15:44:36 annevk: for chrome youd have to use -0.5px, and for webkit youd have to use -3px 15:44:44 astearns: the keyword would give that to you 15:45:04 annevk: i think overall its a win. you dont have to ua sniff for the negated value for auto 15:45:15 q+ 15:45:21 astearns: are we deciding here to endorse this new value for outline offset and use it in this case for appearance base? 15:45:48 flackr: i wanted to ask if we have considered something more radical like not clipping outlines? outlines are already outside of some of the regular box painting 15:46:06 flackr: from a developers perspective, there are many things we can honor to outline things in a scrollable container 15:46:16 q+ 15:46:23 ack flackr 15:46:27 annevk: it would probably get a lot more complicated if you wanted to draw outside. youd need a new layer. it would be more expensive and deal with the interaction with the scrollbar 15:46:39 annevk: i definitely thought about it, it would be nice, but doesnt feel very pragmatic 15:46:54 flackr: yeah its already the case that the outline goes on top of other things that you wouldnt paint on top of like ancestor borders 15:47:13 flackr: i dont claim to have a complete idea here, but it seems like the developer friendly thing would be to not reserve space for the outline 15:47:39 annevk: i did find at least one other scenario where outline required a new layer but we didnt use one. if the border has blending, all UAs do something wrong where the blending bleeds into the outline 15:47:45 annevk: that path also has risky perf implications 15:47:52 ack lwarlow 15:47:52 ntim has joined #css 15:48:03 lwarlow: i dont think theyre mutually exclusive. as a value this makes sense to add 15:48:14 lwarlow: i havent experienced the outline clipping in scroll containers and being really annoyed by it 15:48:22 lwarlow: the behavior seemed inconsistent between browsers 15:48:28 lwarlow: with this value i could get it consistent 15:48:38 lwarlow: if we could solve that separately that would be great but it doesnt need to block this 15:48:44 Proposed Resolution: Accept outline-offset: inline keyword, it computes to the keyword, and use it on base appearance options. 15:48:45 flackr: yes we can pursue both. this is a nice simple short term fix 15:48:59 Proposed Resolution: Accept outline-offset: inset keyword, it computes to the keyword, and use it on base appearance options. 15:49:00 +1 15:49:09 RESOLVED: Accept outline-offset: inset keyword, it computes to the keyword, and use it on base appearance options. 15:49:20 astearns: i suspect that we may talk about this separately in csswg 15:49:54 annevk: this could just apply to option elements without needing to consider base appearance 15:50:03 astearns: trying to think whether there would be any web compat issues 15:50:12 annevk: if people looked at computed style and branched their code 15:51:42 jarhar: [ something about how options aren't focusable except when outside select so this is ok if we just make the selector match only options in a select ] 15:52:08 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11983 15:52:08 Topic: [css-forms-1] Include fieldset and legend 15:52:08 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11983 15:52:44 lwarlow: this was discussed at csswg f2f, and these elements are going to get base appearance 15:53:02 lwarlow: while prototyping this in chrome i realized that resolution leads to a fairly bad looking fieldset legend because you have no padding and stuff like that 15:53:17 lwarlow: the question is what styles do we actualy want to apply besides the border change 15:53:24 lwarlow: html defines some, and i dont know if they make sense 15:53:32 lwarlow: fieldset has a weird padding block 15:53:43 zcorpan: is the idea to get rid of the special fieldset behavior? 15:53:49 annevk: can you show a picture or something? 15:54:04 zcorpan: still having some padding makes sense 15:54:11 lwarlow: as it is resolved, you dont have any padding at all 15:54:19 lwarlow: depending on your interpretation 15:54:42 lwarlow: the fieldset basically just becomes a border, and right now legend is just a plain child 15:55:01 lwarlow: part of me thinks that the legend might want to be rendered with a bolder font weight like we do for optgroups to signify that this is the legend 15:55:09 lwarlow: and then the padding value is the main thing that we have to think about 15:55:22 annevk: the optgroup legend also has some kind of padding? can we do the same? 15:55:28 Sorry, not on the meeting, but legend already doesn't have any magic behavior right? 15:55:30 lwarlow: with optgroup, the options within an optgroup are shifted over 15:55:38 I think we should just get rid of the magic fieldset layout 15:55:40 lwarlow: you dont get internal spacing 15:56:00 lwarlow: if you have radio buttons inside your fieldset, there is no default spacing between them 15:56:42 annevk: we dont have to inherit all of that. we just have to create some sort of plain appearnace people can style. if we have a border thing because fieldset which has a border, and the legend is at the top, and the content has the padding then its clear that its below the heading, then thats a clear minimal set of styles 15:56:51 zcorpan: would it be reasonable to get rid of the border and padding as well? 15:56:56 lwarlow: i think border makes sense 15:57:13 masonf: people usually style it to have no border right? if thats the most common thing then maybe that is the right way 15:57:24 lwarlow: ive never really seen this in the wild 15:57:45 zcorpan: appearnace base is an opt in, and we expect pages to have their own styling. 15:57:53 ntim: it should be usable by default. 15:57:58 annevk: i think it might still be ok even as a default 15:58:07 annevk: i think you do want to add the bold on legend to make it heading like 15:58:19 masonf: if you made fieldset legend bold and got rid of the border it would be good 15:58:44 Do we want "font-weight: bold" or "font-weight: bolder". I suspect we want "bolder" but I'm not 100% sure. 15:58:46 astearns: looking at the discussion we had 2 weeks ago, there is an assertion that making a fieldset look like a div makes it useless 15:58:53 astearns: and that adding a border makes it look like other controls 15:59:05 lwarlow: i think that making it a div doesnt make it useless, that was a misunderstanding 15:59:16 lwarlow: some people think that is what fieldset is useful for 15:59:25 lwarlow: it makes all of its contents disabled 15:59:36 lwarlow: theres a11y stuff to it besides just the layout. it laying out like a div is fine 15:59:57 annevk: we could make it more like a paragraph, so consecutive fieldsets arent bunched up. default top bottom margin of 1em 16:00:06 annevk: if youre not going to do a border then we could do that to indicate separation 16:00:11 annevk: i think fairly minimal styling is fine 16:00:11 s/contents disabled/contents disabled (excluding descendants of the legend)/ 16:00:18 zcorpan: we dont have margins for form or article or section 16:00:34 annevk: most of those are standalone, or they would have their own block level descendants, which in fieldset is not the case 16:00:43 masonf: you could put it on legend 16:01:14 astearns: i dont think were coming to consensus on what to do here. i think it would be good to get images of different options so that we have concrete things to choose between here. luke can you do that? 16:01:15 lwarlow: yes 16:01:21 annevk: we could do a social media poll 16:01:31 astearns: the csswg allows polls in their github discussions 16:01:37 annevk: then we can invite people, sure 16:03:29 topic: end 16:03:51 RRSAgent, please draft minutes v2 16:03:52 I have made the request to generate https://www.w3.org/2026/04/16-css-minutes.html JohnJansen_ 16:26:51 sbender has joined #css 16:57:39 dgrogan has joined #css 17:08:28 Why would bikeshed believe that a document that does not contain a single tab character is tab-indented (and thus complain about every line that starts with spaces)? 17:15:12 (also the bikeshed documentation says the mixed indents warning shouldn't apply inside of 
 anyway!)
17:20:44  oh, sorry, there are tabs, but it's still not ignoring 
 like the docs say...
18:01:58  Zakim has left #css
18:04:01  github-bot has joined #css