` effects the element or it's whole subtree 00:36:31 sorvell: subtree 00:36:42 anne: seems reasonable and close to what we're already doing with the shadow root 00:37:44 sorvell: because the attribute on the element isn't in a template, can it be a parse time configuration so later affectations do not effect the actual registry 00:37:44 zcorpan has joined #whatwg 00:38:11 anne: with that let's do the changes (1 and 3 in the slides) and then follow up later with a "customelementregistry" attribute on all elements later. 00:38:36 justin: points out that 1 is the only part blocking the chrome implementation shipping 00:38:43 sorvell: agrees 00:38:56 anne: looking for someone to drive spec updates on this "agreement"... 00:39:32 sorvell: would attempt to do so... 00:39:47 ...: thanks in advance for implementor support in this area. 00:40:21 jayson: agrees to support inline with his work on shipping this in Chrome 00:41:15 rniwa: this attribute and it's effects only address the current DOM tree, right? 00:41:20 sorvell: yes. 00:41:25 sorvell: not shadow root inclusive 00:41:42 anne: only a parse time solution, right? 00:41:44 sorvell: yes. 00:41:56 sorvell: only want to change the registries _when you want to_. 00:42:21 anne/sorvell: bringing up 3 later (being it currently throws) will be fine. 00:42:53 jayson: recap... 00:42:57 ...: 1 will ship 00:43:20 ...: 2 looking into adding the attribute to support same tree null registries 00:43:46 anne: 3 change createElement(), and attachShadow() as separate spec/test changes 00:43:55 justin: we have rough agreement? 00:44:01 anne/rniwa: seems like it. 00:44:32 jayson: who's ready to take 1 in the spec 00:44:36 anne: volunteers 00:45:07 justin: again, many thanks to everyone who's been part of this process!! 00:45:38 sorvell: so excited to break to global namespace after a long time coming, really appreciates all of the work that's gone into it. 00:46:14 scribe+ 00:46:22 justinf7 has joined #whatwg 00:46:41 justinf7 has left #whatwg 00:46:49 Kurt0 has joined #whatwg 00:47:00 domfarolino: Menu elements proposal 00:47:06 justinf has joined #whatwg 00:47:24 ... menu is an overloaded term 00:48:01 ... motivation: menubar and menulist is very common. 00:48:20 ... menulist items could invoke things or have sub menus 00:48:46 ... another motivation is that, despite being very common, the behavior is wildly inconsistent 00:49:49 ... keyboard behavior especially is inconsistent 00:50:16 ... or does clicking an item close the menu or not? 00:50:30 ... or loop behavior through the menu 00:51:39 ... second motivation: we've built a lot of the foundational pieces out now, so the time is good 00:52:02 ... [explains the gif being show] 00:52:42 ... the prototype uses little JS, thanks to new features built out on the platform 00:53:29 ... [explains the code sample on the slide] 00:54:08 ... re Navigation: menubars are commonly used in these cases 00:54:51 ... but is controversial, and we don't really want this element to be used for navigation. The Navigation Bar proposal is meant to cover this use case 00:55:37 ... [explains the ARIA role mapping slide] 00:57:13 ... keyboard navigation: we've referenced different OSes and other tools, to build out the sensible defaults 00:58:19 ... [finishes explaining slides] 00:58:20 q? 00:58:26 q+ 00:58:30 q+ 00:58:35 ... could be questions about legacy menu element 00:58:51 ack next 00:58:53 q+ 00:59:03 keithamus: arrow key navigation: is that spatially consistent? 00:59:29 ... does a right arrow on open a submenu open a menu on the left because of screen constraints? 00:59:40 masonf: no, we want consistent keyboard behavior 00:59:57 domfarolino: I think it would be good to allow both in that situation 01:00:10 masonf: we should follow ARIA APG's suggestion here 01:00:20 keithamus: looping or not? 01:00:34 domfarolino: we're still discussing but we're hopeful it will come 01:00:51 ... just want to make sure we think about confusing use cases 01:01:11 keithamus: unless you have a menu with 100s of items, it should be clear you've looped 01:01:55 rniwa has joined #whatwg 01:02:04 q? 01:02:23 q+ 01:02:30 keithamus: there's some behavior in Firefox that I don't like, so would like consistency here 01:02:33 ack next 01:02:53 sorvell: concerned it could be too opinionated 01:03:35 ... there's a lot of things built out that means that devs could build this out themselves 01:03:53 ... and it would enable devs to have the flexibility to customize 01:03:56 s/there's some behavior in Firefox that I don't like/I'm thinking about the menu's in firefox's UI and how we could replace with this/ 01:04:11 ... so what's the benefit here? 01:04:39 ... of using these opinionated behaviors vs using a template that's built out? 01:05:03 domfarolino: keyboard is tedious to implement, hard to build out 01:05:15 ... and where things are very inconsistent 01:05:34 Penny has joined #whatwg 01:05:38 ... a11y upfront, keyboard, and checkable state 01:06:00 rniwa has joined #whatwg 01:06:05 zakim, who is here? 01:06:05 Present: cwilso, LeoLee, masonf, frehner, Jacques, ari, sorvell, bvandersloot, jan 01:06:08 On IRC I see rniwa, Penny, justinf, Kurt0, zcorpan, mehm8128, pmeenan1, cabanier, bkardell, bvandersloot, oriol, JRJurman, jan, westbrook, Zakim, RRSAgent, Jacques, sorvell, 01:06:08 ... LeoLee, Adam_Page, Jayson, zrhoffman, frehner, miketaylr, noamr, masonf, keithamus, JakeA, ada, ZoeBijl, ari, miriam, vmpstr, Mike5, adekker, hayato, foolip, nicolo-ribaudo, 01:06:12 ... snek, cwilso, TabAtkins, astearns, tantek-projector, jbroman, hdv, chrishtr, smaug, alice, emilio, christianliebel, jyasskin, cbiesinger 01:06:14 rrsagent, make minutes 01:06:15 I have made the request to generate https://www.w3.org/2025/11/13-whatwg-minutes.html cwilso 01:06:42 masonf: menus are misused very often and get them wrong all the time 01:07:04 sorvell: do you support keyboard shortcuts? 01:07:10 domfarolino: not initially 01:07:49 sorvell: concerned about not using this then if I have different opinions about how this should work 01:08:07 keithamus: shortcuts: we could solve this outside of menus 01:08:36 q? 01:09:05 q+ 01:09:06 sorvell: would be good to find the balance between wanting to customize parts of this with having to throw out the whole thing 01:09:44 q+ 01:10:12 domfarolino: we're not preventing it, it should be possible 01:10:43 ... there isn't really anything preventing extensibility of this 01:11:01 q+ 01:11:10 ... our survey of most websites found that this should be able to cover most of them 01:11:20 sorvell: worried about parsing-related concerns 01:11:57 domfarolino: to encourage them to not be used incorrectly, things like anchor elements are display:none by default but can be overridden 01:12:07 rniwa has joined #whatwg 01:12:10 q? 01:12:14 ... at least until navigation bar happens 01:12:25 ack next 01:12:31 masonf: +1 to no change the parser 01:12:53 ... how do we fell about new elements vs reusing existing? 01:13:00 new 01:13:22 q+ to say HTML usually doesn't hide things that's not conforming to content model, and to consider treating these as block in the parser 01:13:29 domfarolino: reason for new elements: the existing one could do new opt-in stuff. It could work, but we prefer new 01:13:47 ... but open to discussion 01:14:01 ack next 01:14:07 rniwa: in window or stick out? 01:14:20 domfarolino: in window 01:14:45 rniwa: some consideration about in the future to support native UI 01:15:15 ... so let's keep that in mind as we design this 01:15:36 ack next 01:15:44 Kurt: how to style these? new selectors needed? 01:16:06 domfarolino: existing things seem to cover it all so far 01:16:16 q+ 01:16:17 Kurt: can customize how to popup? delay? 01:16:47 domfarolino: we talked about "safe triangle" pattern, but it's tricky JS 01:16:58 ... so not built in at the moment 01:17:12 ... have discussed default hover delay 01:17:35 justinf: what's the plan for safe triangle? 01:17:52 q+ 01:18:07 keithamus: could consider some click behavior to help out 01:18:25 ... or setting menu items to active 01:19:07 westbook: should really consider safe-triange pseudo 01:19:31 masonf: need to study this, validate that it's true 01:19:34 q+ 01:19:53 ack next 01:20:09 JRJurman: checkbox and radio, how do you access them? are they in a form? 01:20:34 domfarolino: [shows slide with code on it] using a fieldset around the menuitems 01:20:43 ... not form associated 01:21:06 ack next 01:21:22 justinf: talk about issue 1323 01:21:50 ... google docs does this, figma does, and custom elements in here too 01:22:22 domfarolino: interactive should be sibling, because of nested interactive content 01:22:44 masonf: +1 nested interactives is bad 01:22:55 ... gdocs example is possible with this proposal 01:23:09 justinf: what about table? 01:23:42 domfarolino: need to think about this. maybe some questions about custom elements as siblings 01:24:00 justinf: maybe a protocol or something 01:24:04 q? 01:24:07 q- 01:24:28 ack next 01:24:28 q? 01:24:28 zcorpan, you wanted to say HTML usually doesn't hide things that's not conforming to content model, and to consider treating these as block in the parser 01:24:38 zcorpan: re hiding links: not something HTML generally does 01:24:45 keithamus: +1 01:24:55 ... could see a reset stylesheet 01:25:28 zcorpan: also the parser: have these elements as block 01:26:08 masonf: for clarity, I'm ok with changing the parser for this 01:26:28 zcorpan: problem is that you can mix elements like

01:26:37 Can `` just be directly nested in a `` instead of using the `commandfor` attribute? 01:26:53 domfarolino: will make a note and explore 01:27:00 ack next 01:27:22 Jacques: in many menu systems, you go deeper and deeper. 01:27:30 domfarolino: by default support click and drag 01:27:31 q+ 01:27:42 ack next 01:27:53 sorvell: not used to seeing submenus on mobile. How do these render? 01:28:05 domfarolino: no 01:28:18 ... no native difference in rendering. but could use media queries if you need to 01:28:27 sorvell: could be problematic/footgun 01:28:42 ack next 01:28:53 Kurt: what happens when you have a large one? overflow scroll? 01:29:06 domfarolino: same as select; scroll overflow 01:29:18 ... lots of similarites to select 01:29:52 domfarolino: concerns about fieldset vs menuitemgroup? 01:30:10 fieldset here feels more like optgroup 01:30:24 anne: styling should be ok, if we fix fieldset styling 01:30:49 masonf: is it broken or just weird? 01:31:01 anne: not described in CSS yet, so this would need to happen as part of that 01:31:31 scribe- 01:34:51 kzms2 has joined #whatwg 01:36:52 Adam_Page has joined #whatwg 01:50:17 Adam_Page has joined #whatwg 01:52:28 rrsagent, make minutes 01:52:29 I have made the request to generate https://www.w3.org/2025/11/13-whatwg-minutes.html cwilso 01:53:28 jarhar has joined #whatwg 01:54:06 Adam_Page has joined #whatwg 02:02:21 jan has joined #WHATWG 02:02:27 scribe+ 02:02:35 bvandersloot has joined #whatwg 02:02:45 q? 02:03:09 Penny has joined #whatwg 02:03:19 github bot, take up https://github.com/whatwg/html/pull/11758 02:03:21 rniwa has joined #whatwg 02:03:26 github-bot, take up https://github.com/whatwg/html/pull/11758 02:03:33 zakim, start meeting 02:03:34 RRSAgent, make logs Public 02:03:35 Meeting: WHATWG 02:03:38 sakhapov has joined #whatwg 02:03:40 github-bot, take up https://github.com/whatwg/html/pull/11758 02:03:41 JRJurman has joined #WHATWG 02:04:15 github-bot, take up https://github.com/whatwg/html/issues/11477 02:05:00 topic: base appearance for customizable select 02:05:14 rrsagent, make minutes 02:05:15 I have made the request to generate https://www.w3.org/2025/11/13-whatwg-minutes.html cwilso 02:06:05 jarhar: customizable select already in spec, listbox in document with list of options, want to make that customizable in appearance 02:06:55 ...prereq issue, mobile platforms no way to get listbox , made PR to discuss 02:07:40 https://www.w3.org/events/meetings/c3357551-d84b-4e96-b02d-4eab08a16d9e/ 02:08:46 [show demo] Chrome canary with exp feature enabled, regular select with regular attiributes, show customizable already in spec. Multiple hard to use because need to select multiple using shift, base appearance has visual indication of what's selected 02:08:53 ...renders similarly to drop down one 02:09:23 ...size=4, 3 items, can only select 1 02:09:57 q+ 02:10:03 ...[talking to demo] multiple size=1, pending outstanding OpenUI discussion, trying to get 2 listbox into spec 02:10:14 tantek has joined #whatwg 02:10:24 present+ 02:10:47 present+ 02:10:57 present+ 02:11:05 ...positive mozilla position PR that redefines how influence dropdownbox vs. listbox 02:11:28 q+ 02:11:30 ...hoping to make "multiple size=1" work on macOS 02:11:30 q? 02:11:46 q? 02:11:49 lea has joined #whatwg 02:11:50 zcorpan: width of widgets depends on what's inside 02:11:57 present+ 02:11:58 jarhar: same as regular 02:12:09 q? 02:12:19 zcorpan: should we solve it for regular ones 02:13:06 jarhar: hard to solve, can do it for case where button not replaced, using fieldsize property, open question whether to respect fieldsizing property, open to changing even if this shipped already 02:13:18 q? 02:13:24 ack zcorpan 02:13:24 ack zcorpan 02:14:17 bkardell: people are now using it, are there OTs shipping this or customizable select, any feedback this not usable because can't go outside window 02:14:22 westbrook has joined #whatwg 02:14:59 ack bk 02:14:59 jarhar: if make list very long, will have scroll bar instead of escaping content, but to make this escape window is tricky 02:15:34 Just to add a use case around listboxes, laying them out horizontally can be pretty useful: https://codepen.io/leaverou/pen/yyBLZwz 02:16:02 bkardell: dealbreakers for some devs, looking at electron, devs do wild stuff just to escape window (impossibly complicated), talk to VSCode (PWA version) that should just work that same way, but they do things to escape the window 02:16:24 ...should be fine, consensus has changed, curious what's the feedback 02:17:24 jarhar: not huge pushback, launched "multiple size=1" in chrome, users filed bug that it doesn't escape window. In future primitives, we could make this work with customizable select. 02:17:58 masonf: developers understand they have a choice 02:18:23 bkardell: does this use native picker on mobile 02:18:36 jarhar: uses more native, iOS same 02:18:58 keithamus: appearance based, do we get same thing or native? 02:19:08 q? 02:19:10 jarhar: get exactly same behavior 02:19:39 zcorpan: ship it 02:19:56 +1 02:19:57 room consensus, no objections 02:21:03 q+ 02:21:11 jarhar: want to do base appearance for "multiple size=1" afterwards, for base appearance 02:21:24 annevk: we can proceed with base appearance 02:21:51 lea: continue to be listbox on macOS, or just auto with appearance base, what's the intent? 02:22:31 ...if listbox in same cases and another in others, might be confusing 02:23:21 q? 02:23:23 ack lea 02:23:29 zcorpan: trying to solve consistency between dropdown and listbox on desktop, proposal makes it more consistent 02:24:13 anne: appearance:base consistent on desktop, appearance auto it depends 02:24:34 lea: multiple shouldn't make it multiple ideally 02:24:48 https://github.com/mozilla/standards-positions/issues/1304 02:24:50 jarhar: standarads position open, asking for review 02:24:56 zcorpan: will review 02:24:56 s/multiple shouldn't make it multiple ideally/multiple shouldn't make it multiple ideally but that ship has sailed/ 02:25:05 scribe- 02:25:13 topic: declarative css modules 02:25:34 scribenick: jarhar 02:25:46 Kurt0: i discussed this at web components and brought it up here a few times. i can share some context of the feature 02:26:24 *kurt shows demo on screen* 02:27:18 Kurt0: a big thing that came up at web components was consistency 02:27:26 Kurt0: consistency as in consistency with the existing style tag 02:27:33 Adam_Page has joined #whatwg 02:27:35 Kurt0: it does behave a little differently here 02:27:56 Kurt0: domenic said to treat it static like an import map 02:28:03 Kurt0: which is counter to some of the suggestions from web components 02:28:16 Kurt0: what happens when the style contents changes? with the static way, it would be too late 02:28:29 Kurt0: there were some suggestions to look up the specifier from the import map and then replace sync the new contnets 02:28:33 Kurt0: would get it more consistent 02:28:39 Kurt0: curious what yall have to say about that 02:28:42 Kurt0: is this a good idea? 02:28:52 JakeA: would the same happen if you change the specifier? 02:28:56 Kurt0: yes that was my next question 02:29:05 side note about this and the custom element registries thing: I'm sorry for suggesting "shadowroot*" attribute names. Way too long. 02:29:10 Kurt0: right now its all very static. nothing changes when you mutate 02:29:29 Kurt0: import maps go through an execution context and only run once 02:29:29 Kurt0: with a style tag folks expect it to be live 02:29:35 q? 02:29:39 q? 02:29:40 q+ 02:29:47 JakeA: aside from the text, would this have a sheet property? a cssom? 02:29:53 Kurt0: not on the style tag. it would be in the module map 02:30:00 Kurt0: you could import it throuh script and get it that way 02:30:06 Kurt0: you coulud replace things there and do that through script 02:30:19 JakeA: so you could modify that stylesheet and look at the text of this style it would override those changes? just replace sync 02:30:23 Kurt0: yes 02:30:33 Kurt0: this wouldnt be new, it would just be more consistent 02:30:44 ack next 02:30:49 q+ 02:30:50 westbrook: if i were to import with an import attribute something that was on the import map which had css 02:30:54 westbrook: the value that came out would be live 02:31:05 westbrook: what is the functional difference with the value that comes out here and the imperative use case? 02:31:06 q+ 02:31:17 q+ 02:31:18 Kurt0: there would be no difference, youre changing the same underlying sheet 02:31:27 Kurt0: it would be doing the same thing as if you imported foo here and then replace sync 02:31:34 q- 02:31:38 Kurt0: theres no new scenario, it would just do that automatically when the contents of the style tag change 02:31:42 q+ 02:31:45 ack next 02:31:53 sorvell: i used kurts implementation in canary 02:32:13 sorvell: the stylesheet that you get in this div's shadowroot, its going to have an adopted stylesheet. you can access it and replace sync on it 02:32:20 sorvell: this is basically the same as if you messed with textcontent 02:32:25 anne has joined #whatwg 02:32:33 sorvell: thats sort of similar to if it were directly imported 02:32:33 q? 02:32:38 q+ 02:32:45 sorvell: i think the style text content should be live, the specifier should not be allowed to be cchanged 02:32:52 (That seems extra weird to me.) 02:33:04 sorvell: i think that jakes point about can you just apply the sheet in css, anyone that uses css is going to want that 02:33:05 q+ 02:33:10 sorvell: that should be part of the mvp 02:33:18 sorvell: i think youre going to get that feedback from csswg 02:33:23 Kurt0: @import ? 02:33:29 sorvell: yes 02:33:32 q+ 02:33:41 Kurt0: that it tricky because you cant do that with existing css modules, its broken 02:33:46 q- 02:33:46 Kurt0: thats something i will look into 02:34:19 sorvell: when we discussed this at web components, one idea was - the syntax was import url, could be good to propose a css issue. maybe we could do at import module 02:34:41 keithamus: yes that was the thing we discussed, you can have this tainting thing so you couldnt allow at import modules with any stylesheet 02:34:49 keithamus: emilio said that was fine 02:34:56 keithamus: i dont want to speak for them but that seems tractable 02:35:06 Kurt0: ill file an issue and get that going, but i think it can be done in parallel 02:35:07 ack next 02:35:10 q+ 02:35:20 keithamus: i dont think this demo demonstrates the issue 02:35:27 rniwa has joined #whatwg 02:35:28 keithamus: there are more compelling reasons for this 02:35:38 keithamus: for the replacement 02:35:53 q? 02:36:00 keithamus: the shadowroot adoped stylesheets is ordered. if you dont load it in the right timing then youre stuck with unresolved modules and silent failures. i think its important that we make this live 02:36:21 q+ 02:36:21 keithamus: on the topic of changing the specifier, if you dropped type module does that become a regular style tag? 02:36:25 Kurt0: yes 02:36:41 keithamus: you could have a module stylesheet and if you drop type module it becomes a global stylesheet? 02:36:49 Kurt0: thats not how i implemented it, that would be good to discuss 02:37:01 Kurt0: i freeze the type when its first connected, you cant turn it back from a module into global 02:37:07 Kurt0: if this is soemthing people want then it could change 02:37:16 keithamus: i dont think its desirable, but its interesting that you locked it 02:37:33 Kurt0: this was another side effect of following the import map because they have an already started flag 02:37:47 q+ 02:37:48 keithamus: does that mean that you could drop type module and also the text content and it wouldnt update the module? 02:37:54 jridgewell has joined #whatwg 02:37:55 q- 02:38:05 keithamus: if it was live you couuld make it un-live by dropping module? 02:38:07 Kurt0: yes 02:38:10 keithamus: fine, but weird 02:38:14 ack next 02:38:18 this is way more like a `