select with hr and div children

2025-11-01 [23:58:59.0855] currently if you have multiple

with the same [name] the browser will treat the group as an accordion. github has this behavior where if you're on the page for a commit or the changed files of a pr and hold alt/option and then click the caret then all the dropdowns in the group with open/close together. is there an open issue for this/any interest? [23:59:20.0838] * currently if you have multiple \

with the same \[name\] the browser will treat the group as an accordion. github has this behavior where if you're on the page for a commit or the changed files of a pr and hold alt/option and then click the caret then all the dropdowns in the group will open/close together. is there an open issue for this/any interest? [00:03:48.0251] Sounds interesting to me (as someone who implemented the existing details@name accordion/grouping stuff in an engine) [00:04:05.0084] …and there’s no existing open issue for it as far as I know [00:04:16.0022] * …and there’s no existing open spec issue for it as far as I know 2025-11-02 [15:51:33.0267] is not what html6 should do to us, it is what ......HTML5 web3❓ 2025-11-03 [06:28:22.0546] are deprecated features tracked anywhere? For example, the MimeType and MimeTypeArray interfaces which are deprecated but I don't see represented in the current webref repo's IDL files. I presume deprecated interfaces are removed? [06:29:27.0681] well, it does look like they are in the html idl [06:30:24.0663] I guess the real question is are deprecated features expected to still be represented in the webref repo? [06:39:45.0000] Brian Cardarella: yes, everything that's defined should probably be in there. Maybe things can have annotations. 2025-11-04 [00:17:35.0475] `div` is now allowed as a descendant of `select`? [00:17:38.0229] https://html.spec.whatwg.org/multipage/dom.html#select-element-inner-content-elements-2 [00:18:32.0451] The following are [select element inner content elements](https://html.spec.whatwg.org/multipage/dom.html#select-element-inner-content-elements-2): [option](https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element)[optgroup](https://html.spec.whatwg.org/multipage/form-elements.html#the-optgroup-element)[hr](https://html.spec.whatwg.org/multipage/grouping-content.html#the-hr-element)[script-supporting elements](https://html.spec.whatwg.org/multipage/dom.html#script-supporting-elements-2)[noscript](https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element)[div](https://html.spec.whatwg.org/multipage/grouping-content.html#the-div-element) [00:18:43.0621] * The following are [select element inner content elements](https://html.spec.whatwg.org/multipage/dom.html#select-element-inner-content-elements-2): [option](https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element)[optgroup](https://html.spec.whatwg.org/multipage/form-elements.html#the-optgroup-element)[hr](https://html.spec.whatwg.org/multipage/grouping-content.html#the-hr-element)[script-supporting elements](https://html.spec.whatwg.org/multipage/dom.html#script-supporting-elements-2)[noscript](https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element)[div](https://html.spec.whatwg.org/multipage/grouping-content.html#the-div-element) ``` [00:19:40.0764] * > The following are select element inner content elements: > * option > * optgroup > * hr > * script-supporting elements > * noscript > * div [00:20:05.0746] Do current parsers actually support that? [00:20:24.0711] The Gecko/validator.nu parser doesn’t seem to [00:23:00.0748] trying the HTML checker with this: ```html select with hr and div children ``` I get parse-error messages: "file:/Users/mike/workspace/validator/tests/html/elements/select/hr-and-div-children-isvalid.html":7.3-7.27: error: Stray start tag “div”. "file:/Users/mike/workspace/validator/tests/html/elements/select/hr-and-div-children-isvalid.html":7.3-7.40: error: Text not allowed in element “select” in this context. "file:/Users/mike/workspace/validator/tests/html/elements/select/hr-and-div-children-isvalid.html":7.41-7.46: error: Stray end tag “div”. [00:23:47.0826] * trying the HTML checker with this: ```html select with hr and div children ``` I get parse-error messages: :7.3-7.27: error: Stray start tag “div”. :7.3-7.40: error: Text not allowed in element “select” in this context. :7.41-7.46: error: Stray end tag “div”. [00:25:15.0190] hmm yeah also in Firefox — the DOM looks like this: ```html ``` [00:26:26.0013] hmm yeah same DOM in Safari — no `div` in the DOM [00:27:15.0821] sideshowbarker: that's a very recent change; I think Chrome might have shipped it. I did implement these aspects in WebKit, but nothing shipped as-of-yet. [00:27:33.0313] ah OK [00:28:08.0061] so I guess I may need to implement in the vnu HTML parser — or wait til Henri or somebody does [00:28:35.0131] Do you know if there’s an open gecko bug for it? [00:29:49.0896] sideshowbarker: https://bugzilla.mozilla.org/show_bug.cgi?id=1933591 [01:47:44.0977] incidentelly I've seen dl/dt/dd got similar changes too, but I haven't checked if that was implemented [01:47:49.0895] * incidentaly I've seen dl/dt/dd got similar changes too, but I haven't checked if that was implemented [01:58:17.0174] I think those were just conformance changes. The parser wasn't changed for those elements. [05:07:14.0754] annevk & smaug are we OK marking Menu Elements (https://github.com/whatwg/html/issues/11729) as stage 1? This was raised a few WHATNOTs ago [05:28:22.0363] Dominic Farolino: okay from our side. [06:05:17.0889] that is ok 2025-11-05 [23:13:32.0756] sideshowbarker: you around? The “Running the HTML checker…” part of the WHATWG build pipeline is failing on a 404. [23:14:02.0280] sideshowbarker: https://github.com/whatwg/compression/pull/79 and https://github.com/whatwg/cookiestore/pull/290 [23:30:03.0907] I suppose I can still merge and we just won't have validation this time around. I might do that given that these are overdue. [01:55:56.0930] * I suppose I can still merge and we just won't have validation this time around. I might do that given that these are overdue. Edit: that does not work. sideshowbarker I need your help. [02:57:46.0626] Here now. Will take a look right away as soon as I can (where as soon as I can is, after finishing up with usual evening responsibilities at home) [04:22:48.0040] sideshowbarker: https://github.com/whatwg/whatwg.org/pull/476#issuecomment-3490878207 [04:27:27.0514] https://github.com/validator/validator/releases/tag/latest [04:28:11.0229] But there are missing release assets there [04:32:07.0564] The releases are generated by a CI build — from GitHub Actions — that runs for every push to main [04:33:13.0931] But for some reason, the last time it ran, it seems it didn't actually upload all the assets to where it should have [04:34:27.0259] So I just now retriggered the GH Actions workflow for it, manually [04:36:10.0810] …and now all the assets are there [04:36:16.0978] https://github.com/validator/validator/releases/tag/latest [04:36:40.0549] https://github.com/validator/validator/releases/download/latest/vnu.linux.zip [04:38:39.0160] I'm away from my laptop still, so I haven't looked at the deploy.sh script. But can you remind me what the logic is in the case where it can't download the latest release? [04:39:22.0883] Apparently it then makes a request to validator.nu? [04:40:33.0704] If so, we should change that to have it fall back to validator.w3.org/nu instead [04:48:29.0119] sideshowbarker: now that you fixed that it's all working again. [13:50:07.0753] Must all new content attributes be reflected by an IDL attribute? Is this a requirement anywhere? [14:06:15.0645] > <@domfarolino:matrix.org> Must all new content attributes be reflected by an IDL attribute? Is this a requirement anywhere? https://www.w3.org/TR/design-principles/#html-idl-must-by-synced 2025-11-06 [02:53:42.0962] jjaschke (out until Dec 1), smaug, if you're around at TPAC we can perhaps do some navigation API whiteboarding to resolve some of the pending messy issues. I understand farre won't be there unfortunately. Anyone else who's around is welcome of course (e.g. Dominic Farolino) [02:54:02.0054] I'll be there [02:56:43.0135] I don't think wait-for-all is that messy. The spec is mostly good in that case, and API is part of interop, so "encouraging browsers to precisely match the web standards " 😉 But yeah, that issue, and perhaps others too should be discussed. [02:57:45.0604] And we should also discuss about that "encouraging browsers to precisely match the web standards " part. [03:08:04.0988] It's messy when there is a divergence between WPTs and spec which in some cases begs the question of which one is correct. [03:09:39.0408] anyway, I saw that the process/meta question is already on the agenda requests but what I want is to spend a bit of time on the specifics and make sure we make the right decisions for users/web-devs. [03:10:58.0868] Sure. [03:14:52.0583] I must admit that I'm surprised by the amount of divergence [03:18:19.0307] I wasn't involved when it was spec'ed/implemented but I remember that there was a huge hanging PR with a lot of details for quite a while, and the prototype was progressing alongside the spec. So it caught me by surprise as well but also it's not totally unexpected given the complexity of this API [03:18:40.0115] Or Session History and Navigation in genereal [03:18:42.0090] * Or Session History and Navigation in general [03:21:11.0632] Yea exactly. I am curious as to whether this is an outlier or there are other recent examples of this kind of divergence/complexity. Answering this can help the meta conversation. [04:26:45.0066] Trusted types was perhaps a bit similar, though there through some great collaboration specs and implementations got into a lot better shape. But it did mean filing spec issues and fixing them when the spec wasn't implementable and also writing tests following the spec, not the first implementation. [04:36:47.0837] Yea I see that TrustedTypes landed in 2019, and there were some recent spec-alignment changes [04:38:27.0628] "some" 🙂 And lots of new tests [04:39:22.0376] (I can't thank Frédéric enough for writing tons of tests) [04:40:50.0794] annevk zcorpan Jake Archibald: Noam Rosenthal and I are working on `streamHTMLUnsafe()` and would like to use the stages process, and would like to move https://github.com/whatwg/html/issues/2142 to stage 1. (https://github.com/whatwg/html/issues/11669 is also very relevant, but we don't need two issues in the stages process I think.) [05:43:53.0035] foolip: SGTM, maybe add to https://github.com/whatwg/html/issues/11711#issuecomment-3432130305 ? [08:42:32.0513] Yes definitely! Looking forward to this [11:52:13.0509] Draft WHATUP schedule posted :https://github.com/whatwg/html/issues/11711#issuecomment-3499143498 [11:52:26.0722] Please let me know if you need changes, and there are still a few openings. [12:56:09.0537] If there is time available, could we also talk about https://github.com/whatwg/html/issues/11711#issuecomment-3481575249? :) [15:48:02.0857] Gaaah nicolo-ribaudo Andreu Botella (🕑 JST, mostly off until Nov 10) I'm so sorry, I dropped that one. Added in. [15:48:36.0397] Schedule updated with some slight changes per requests: https://github.com/whatwg/html/issues/11711#issuecomment-3499143498 2025-11-10 [01:39:45.0328] Sure, I'm around and happy to discuss 2025-11-11 [16:46:03.0740] Notes doc for WHATUP: https://docs.google.com/document/d/1XQLLjETtdBPv-xGiGPRALR4X7hgSb_Lk13bdBucEJ_g/edit?usp=sharing [16:56:13.0453] https://docs.google.com/document/d/1XQLLjETtdBPv-xGiGPRALR4X7hgSb_Lk13bdBucEJ_g/edit?tab=t.0#heading=h.51akrqmzup50 https://webirc.w3.org/?channels=WHATWG [23:37:35.0012] Is scribing happening in a different GDoc now? [23:48:49.0893] It happens on W3C IRC `#whatwg` due to lack of Matrix bots [00:51:18.0869] note new draft Thursday schedule :https://github.com/whatwg/html/issues/11711#issuecomment-3515612334 [01:07:50.0216] TabAtkins: https://github.com/mstange/samply / https://docs.python.org/3/using/cmdline.html / https://share.firefox.dev/43n45Vy [03:38:23.0151] I fail to understand why whatwg is focusing on various API's in different browsers. I do protecting my API's to prevent fingerprinting. To me anything that needs the API to work is a threat and it must be contained with urgency. I hardly see any discussion about HTML here it's more like developing full applications that will use the browsers capabilities but completely disregarding the dangers of this. In my opinion anything that depends on specific API's in the browsers is a significant threat. [03:54:38.0017] Far as I know W3C and others do working on prevention of fingerprinting, I never seen any discussion regarding this issue in whatwg. The more API's are there which implemented by browsers the bigger the threat. I do not support more and more API's and more and more proposal to depend on them especially not when fingerprinting and privacy is completely left out of discussion. [04:03:55.0491] Probably the biggest most meaningful standard would be a new high-level API that mediates or annotates other APIs. One for all - all for one. This way it is possible to protect users privacy, resist fingerprinting etc. Pretty sure a lot of browsers would implement it. The API itself would be difficult but not impossible. Once there is a working version the development would be easier. [04:32:39.0069] I think there's significant overlap between whatwg/w3c that I presume most people in either group have seen things like v [04:32:40.0887] * I think there's significant overlap between whatwg/w3c that I presume most people in either group have seen things like https://www.w3.org/TR/fingerprinting-guidance/ [10:45:19.0538] There's not much discussion of HTML because there aren't many newly-proposed declarative HTML features, and cross-browser compatibility/ambiguity problems are largely addressed or at least known and added to web platform tests. [10:46:37.0552] Most of the activity in non-scripted features is happening in the very active CSS working group, but that's hosted by W3C so it doesn't come up here in WHATWG [10:48:29.0395] And most of the proposals to restrict capabilities of existing APIs are happening in the Privacy WG and CG. Often by the same people who are in this channel! [12:25:45.0565] zcorpan, annevk OK to move https://github.com/whatwg/html/issues/11819 to stage 1 following yesterday discussion? 2025-11-12 [22:19:06.0846] i wrote some notes about implementing customizable select which would be very helpful for anyone else who is implementing it: https://gist.github.com/josepharhar/9c359f5b8b6fa4c31065bd1fbeab40dd 2025-11-15 [18:42:24.0706] annevk: do you think it would be reasonable to make Request/Response transferable? I think the biggest piece there is the bodies and they are already transferable... i can open an issue with more detail if this sounds generally coherent. [07:15:49.0735] Would be good to clarify the use case beyond passing the bodies. [10:20:31.0476] > <@noamr:matrix.org> Would be good to clarify the use case beyond passing the bodies. server software (e.g. deno) passing them to different threads for processing 2025-11-17 [17:25:36.0930] does this group work with the webref repo or is that completely separate? [17:25:44.0622] webref being in the w3c org [18:08:42.0066] [@bcardarella:matrix.org](https://matrix.to/#/@bcardarella:matrix.org) I think everybody except François Daoust who wrote it and maintains it are just users of it [18:09:57.0984] …modulo some people maybe having contributed PRs at times [13:01:33.0014] https://github.com/whatwg/html/issues/11920 got this written up :) 2025-11-18 [02:34:19.0428] snek: yeah, seems reasonable in the abstract [04:10:52.0390] annevk: It looks like the reporter of https://github.com/whatwg/html/issues/11782 filed it on Gecko and Chromium but not on WebKit. [04:22:29.0614] hsivonen: presumably those reports will be closed as INVALID so it doesn't matter? Or am I missing something? [04:22:36.0702] (https://bugzilla.mozilla.org/show_bug.cgi?id=2000805 and https://issues.chromium.org/issues/461532443?pli=1 ) [04:23:29.0992] Mostly a FYI about trying different venues. I closed the Gecko bug. [04:23:46.0753] (Also doesn't seem like any of that is high priority for the i18n WG, but I suspect Richard at least still cares about it. And Elika prolly too.) [04:24:34.0861] Now that we've made other changes to the HTML parser maybe we should reconsider, but it seems really hard to determine where to draw the line. [08:20:14.0367] TabAtkins: seeing a weird warning at https://github.com/whatwg/fetch/actions/runs/19468018147/job/55725474022: "Remote data (2025-11-11 11:44) is more than two days older than local time (2025-11-18 16:17); either your local time is wrong (no worries, this warning will just repeat each time) or the update process has fallen over (please report this!)." [08:21:25.0309] Yu, someone just reported it over the weekend, looking into it now [08:49:36.0001] Ah, it's a data issue that was triggering an error in the update process (someone left an empty id attribute on their heading). Fixed the spec and am currently verifying the fix in Bikeshed. 2025-11-19 [07:27:28.0415] LEARN HOW TO HACK 🕹 🕶️ CyberSecurityExpertsHQ— born from the 2013 cyber underground. Real intel. Real exploits. No noise — just raw cybersecurity knowledge. ⚡ JOIN US HERE 📌 📱Telegram Account Hacking 📩Hotmail and Outlook Hacking ☎️Track cellphone 📱YouTube Account Hacking 📩Gmail Hacking 🛡SS7 attack launching 📱Facebook Hacking 📱WhatsApp Account/Spy 📱Twitter Account Hacking 📱Instagram Account Hacking 📱Tiktok hack 💳Carding and selling Carded tools 📱Skype Account Hacking 📱Snapchat Account Hacking 🎮Game hacking 📞number Hacking/Cloning 📱Phone Hacking/Android Hacking 📱Tinder/ Onlyfans account Hacking 📱Website Database Hacking 💻Computer/Laptop Hacking ☁️ Bitcoin Mining 📱Phone Hacking/Android Hacking 📱Normal account Hacking like Apple account JOIN NOW🔎 https://t.me/CyberSecurityExpertsHQ2