2025-12-01 [17:45:23.0442] For https://html.spec.whatwg.org/multipage/interaction.html#attr-writingsuggestions can somebody remind me why the empty string is a conforming value for that — even though the table there only explicitly lists `true` and `false` as the allowed values? [17:46:44.0304] And note that at https://html.spec.whatwg.org/multipage/indices.html#attributes-3:~:text=writingsuggestions the index of attributes is where the spec (though non-normatively there, I guess) states that the empty string is an allowed value. [17:48:03.0230] …and similarly for, e.g., the `spellcheck` attribute, the index at https://html.spec.whatwg.org/multipage/indices.html#attributes-3:~:text=spellcheck also says the empty string is allowed for that. [17:48:51.0957] And for `hidden` too https://html.spec.whatwg.org/multipage/indices.html#attributes-3:~:text=hidden,-HTML [17:50:10.0920] But looking at the whole index, I guess it’s just those three which the index says are allowed to have the empty string as a value. `hidden`, `spellcheck`, and `writingsuggestions` [17:52:02.0659] …whereas, in contrast, if you look at what the index says about other enumerated — such as `wrap` at https://html.spec.whatwg.org/multipage/indices.html#attributes-3:~:text=integer-,wrap — the index _does not_ say the empty string is allowed. [17:53:34.0633] see `popover` at https://html.spec.whatwg.org/multipage/indices.html#attributes-3:~:text=popover,-HTML for another empty-string-not-allowed example [17:58:53.0000] d’oh nevermind — found the requirement at https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#enumerated-attribute:~:text=The%20empty%20string,-and > For authoring conformance purposes, if an enumerated attribute is specified, the attribute's value must be one of: > > - An [ASCII case-insensitive](https://infra.spec.whatwg.org/#ascii-case-insensitive) match for one of the conforming keywords for that attribute, with no leading or trailing whitespace. > > - The empty string and the attribute must have an [empty value default](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#empty-value-default) defined. [18:00:29.0161] So, the index is wrong (or incomplete/imprecise) in the cases where, for any enumerated attributes, it doesn’t explicitly list the empty string as an allowed value. [00:09:55.0672] sideshowbarker: r? https://github.com/whatwg/html/pull/11974 [00:10:37.0761] beautiful [00:11:05.0268] but now you make me feel like I’m just a lazy complainer 😆 [00:11:11.0038] will review it right now [00:12:39.0509] Nah all good. Luke and I changed this around a bit recently as part of making reflection more formal and this is something we missed. [00:38:50.0684] annevk: You need to put on your glasses; seems like you missed a few: https://github.com/whatwg/html/pull/11974/commits/02f24ef01e1c3dd7f4fb53ec43b5e692a80050d4 [00:38:57.0813] oh wait [00:39:21.0183] Had you outsourced that to copilot or something? [00:52:03.0384] sideshowbarker: I don't really understand your commit. Why would the empty string be valid for `autocapitalize` for instance? [00:52:39.0487] The attribute needs to define an "empty value default" for the empty string to be a valid value. I only added it for attributes that define that. [00:55:29.0904] d’oh yeah I see now you’re right — I hadn’t read the requirements at https://whatpr.org/html/11974/common-microsyntaxes.html#:~:text=The%20empty%20string%20and%20the%20attribute%20must%20have%20an%20empty%20value%20default%20defined. carefully enough [00:55:56.0065] so yeah then, that additional commit I made can just be ignored [00:59:46.0690] Okay, I'll revert it and the squash & merge. [03:02:18.0975] annevk: By the way, not trying to butter you up, but I am (again) reminded that basically any time it seems to me like you made a mistake or oversight, it’s very significantly more likely (or close to certain) that it’s me who actually made the mistake. [03:03:14.0522] You seem to make exceptionally few mistakes. We could probably add a “Mistakes that Anne has made” page to the wiki, and not even come close to filling up the page. [03:15:03.0920] Hah, well I made a fair number of mistakes with custom element registries recently and Domenic was pretty good at spotting errors in my PRs as well over the years. I do try to be precise and do my due diligence, but I'm certainly not infallible. [09:43:30.0653] About the index, I don’t see Keith around here, but I wanted to say, I notice the index doesn’t seem to include entries for `headingoffset` and `headingreset` global attributes. And further, the spec doesn’t state any document-conformance requirements about the allowed values of those attributes — that is, it should rightly explicitly state somewhere that they are non-negative integer (`headingoffset`) and boolean (`headingreset`). (Which can be inferred from the implementations requirements, but should also be stated explicitly somewhere.) [09:43:52.0468] * About the index, I don’t see Keith around here, but I wanted to say, I notice the index doesn’t seem to include entries for the `headingoffset` and `headingreset` global attributes. And further, the spec doesn’t state any document-conformance requirements about the allowed values of those attributes — that is, it should rightly explicitly state somewhere that they are non-negative integer (`headingoffset`) and boolean (`headingreset`). (Which can be inferred from the implementations requirements, but should also be stated explicitly somewhere.) [09:44:05.0398] * About the index, I don’t see Keith around here, but I wanted to say, I notice the index doesn’t seem to include entries for the `headingoffset` and `headingreset` global attributes. And further, the spec doesn’t state any document-conformance requirements about the allowed values of those attributes — that is, it should rightly explicitly state somewhere that they are non-negative integer (`headingoffset`) and boolean (`headingreset`). (Which can be inferred from the implementations requirements, but should also be stated explicitly somewhere.) 2025-12-02 [16:32:21.0122] quick question as I'm working on the State of HTML survey results: is there currently a proposal for a Datatable element? [21:42:55.0977] keithamus: zcorpan: see above issues with the `heading*` attributes. [21:43:07.0090] Sacha Greif: I'm not aware of any. [01:51:25.0602] sideshowbarker: filed https://github.com/whatwg/html/issues/11977 [02:06:29.0634] https://github.com/whatwg/html/pull/11978 /cc sideshowbarker [02:08:18.0314] oh, didn’t yet know about the _“between 0 and 8”_ qualification [02:08:51.0730] I guess I’ll need to update the HTML checker to limit it to that [02:12:15.0139] What does setting `headingoffset=0` do? [02:13:15.0796] sideshowbarker: the IDL attribute reflection enforces that range and values outside the range are effectively clamped by the algo [02:13:24.0645] sideshowbarker: 0 does nothing [02:13:28.0764] OK [02:13:50.0156] then I wonder, why is 0 allowed? [02:14:02.0530] why not limit it to 1–8? [02:14:47.0134] sideshowbarker: same reason `class=""` is allowed [02:15:10.0999] sideshowbarker: can be more convenient to set to 0 than call `removeAttribute` [02:15:24.0067] I see [02:18:59.0080] keithamus: I had also started a PR lol, but yours didn't include doc conf https://github.com/whatwg/html/pull/11979 [02:19:19.0820] Oh awesome thanks! [03:21:05.0494] zcorpan: about https://github.com/validator/validator/issues/1396, under what conditions is it conforming for the `sizes` attribute to be ommitted? [03:21:43.0173] Currently in the checker, we enforce this requirement: > When the srcset attribute has any image candidate string with a width descriptor, the sizes attribute must also be specified. [03:22:39.0846] and so this: ```html ``` …currently causes the checker to report the above error message [03:23:32.0711] ah, only if `loading=lazy` is also present? [03:24:02.0671] sideshowbarker: https://html.spec.whatwg.org/#attr-source-sizes:~:text=selected%2E-,If,selected [03:24:05.0699] hmm no I guess it’s not that simple and I need read the actual spec requirements… [03:25:29.0949] sideshowbarker: and https://html.spec.whatwg.org/#attr-img-sizes:~:text=If%20the%20srcset%20attribute%20is%20present%20and%20has%20any%20image%20candidate%20strings%20using%20a%20width%20descriptor%2C%20the%20sizes%20attribute%20must%20also%20be%20present%2E for img [03:30:00.0571] hmm but I see that the spec does still state this requirement: > If the srcset attribute is present and has any image candidate strings using a width descriptor, the sizes attribute must also be present. [03:30:07.0471] Hmm for this > If the srcset attribute is not specified, and the loading attribute is in the Lazy state, the sizes attribute may be specified with the value "auto" (ASCII case-insensitive). This was added so that you could have a stable layout before setting `srcset` when using auto-sizes (because UA style is different). But I don't know why we didn't allow any value starting with "auto," [03:30:51.0848] sideshowbarker: Yes for img it must be present [03:31:32.0195] So the following is in fact not conforming, right? ```html ``` [03:31:45.0128] Correct [03:32:58.0544] OK, I ask because at https://github.com/validator/validator/issues/1396 you had identified it as valid [03:33:28.0223] The rationale is: the UA style needs to be different for auto-sizes to work correctly (needs `contain: size`), and it wasn't web compatible to change that for `img` elements that omit `sizes` [03:33:43.0655] but it’s an old issue (2022), so maybe it was valid at one time, back then? [03:33:50.0605] We changed the spec and I forgot to comment about it there [03:34:01.0202] no worries [03:39:48.0980] and apologies in general for letting so many checker issues rot for so long [03:40:11.0905] I’m going to try to get all the open ones resolved this month [03:40:38.0536] …and then I after that I can go back to ignoring the new ones for next 3 years or whatever 😆 [03:40:55.0744] …and I can just work on writing webkit patches instead [04:27:00.0759] zcorpan: per these requirements: > The keyword auto is a width that is computed in parse a sizes attribute. If present, it must be the first entry and the entire value must either be the string "auto" (ASCII case-insensitive) or start with the string "auto," (ASCII case-insensitive). … then the following is not actually conforming, right? ```html ``` [05:05:35.0341] sideshowbarker: right [05:05:59.0970] sideshowbarker: leading space is also invalid [05:06:41.0350] oh then that means I need to not have my checker code trimming it [08:01:15.0616] jarhar: did you miss https://github.com/whatwg/html/pull/11878? [14:11:12.0133] annevk: I've just been through all the WHATWG specs and confirmed they'll build correctly with the next release of Bikeshed (after accepting some trivial PRs I've just submitted), so I'm gonna go ahead and push the release. Please let me know if there are any unexpected issues; I've tried very hard to make things work smoothly for such a significant under-the-covers change. 2025-12-03 [16:30:25.0464] sideshowbarker: Is the https://github.com/w3c/mdn-spec-links project dead? It looks like it hasn't updated in two years, and now there are three specs listed in https://w3c.github.io/mdn-spec-links/SPECMAP.json whose files no longer exist in the repo. [16:31:06.0463] Dead [16:31:13.0885] Essentially, yes [16:31:31.0256] is there a replacement? otherwise I need to just remove the MDN-panel feature from bikeshed [16:32:11.0952] Please go ahead and remove it. [16:32:23.0305] There's no replacement [16:32:54.0133] If I could get somebody to take over maintenance on it, that would be great [16:33:07.0385] Or to make a replacement [16:33:47.0724] But in the meantime, let's just rip it out [16:37:27.0800] kk, i'm just gonna check with our internal mdn people first [21:45:07.0603] sideshowbarker: Encoding standard is failing over "This document appears to be written in Kinyarwanda but the “html” start tag has “lang="en"”. Consider using “lang="rw"” (or variant) instead." for many files. I guess I'll try to suppress that warning. [21:57:04.0025] TabAtkins: thanks for all the fixes! [22:06:34.0243] sideshowbarker: is there a new charter for the Wasm WG somewhere? [22:08:54.0546] Ah, found https://github.com/w3c/strategy/issues/533 [00:21:59.0280] 🤯 [01:59:09.0818] annevk: I've updated the out-of-order streaming explainer after the discussion about prepend last WHATNOT... https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#interleaved-patching In short, I think we still need append/replace-children as methods to allow multiple patches to the same element accumulate, and doing that with comments would be messy [03:22:55.0114] zcorpan: ping re. merging https://github.com/whatwg/html/pull/11692 when you get a chance, it's been approved and all the boxes are ticked :) [03:38:31.0878] Noam Rosenthal: Thanks for pinging here, and apologies for the delay [03:39:55.0035] No worries! [04:50:56.0917] Dominic Farolino: any chance I can convince you to tackle these issues: https://github.com/domenic/jake-diagram-generator/issues? [04:56:02.0119] Oh, maybe the checker is wrong? /me finds https://github.com/whatwg/html/issues/10532 [04:56:52.0769] from what I recall of that, I maintain that the checker is in fact not wrong [04:57:23.0673] that is, the checker is flagging an actual “table integrity” error [04:59:32.0784] but that said, the message is just a warning; and if the table-integrity “error” isn’t causing any known actual problems for anybody trying to use the information in the — in particular, not for AT users especially, but also, not resulting in an visual breakage — then the right (pragmatic) thing to do it, just ignore it [05:00:19.0540] and also in general, it may be time for us to no longer be treating all checker warnings as errors — as far as the spec builds go [05:03:45.0171] Sorry about that. I was aware of it and at https://github.com/validator/validator/blob/main/build/build.py#L1281 — in the whatwg-spec-build-check thing I added to the checker CI — I am filtering that warning out. But it should have occurred to me that would not fix it for the actual upstream whatwg builds. I guess that was because I had been (wrongly) assuming the builds were only failing on checker errors, but not on warnings. [05:06:01.0516] We don't fail on "info warnings" it seems, which is why HTML is still going strong. I think I agree with you that this Jake diagram pattern is suspicious. At least the HTML standard makes no mention of a "missing cell" concept. [05:06:08.0241] The language guesser that the checker uses — and I think that in general, all other such language guessers, as a class — do not operate predictably on non-prose text content. [05:07:29.0735] One mitigation I already have the language guesser in the checker tuned to do, is to just not try to operate on any text content that is less than about ~200 words (1024 characters). [05:09:22.0618] …but that doesn’t help for the case where there is more than 1024 characters of completely no-prose text content. Which under normal real-world cases is a highly exceptional case. But those Encoding spec legacy-coverage files are highly exceptional in a lot of ways… [05:11:37.0604] So one thing I want to suggest considering is: For the Encoding spec, we change the build to only running the HTML checker on the spec index.html file itself — and not on any of those (dozens) of other legacy-coverage files (which are anyway just big tables of characters, or whatever they are) [05:13:01.0161] Alternatively, I am fairly certain I could tune the language guesser further such that we could make it end up just completely not trying to do any language-guessing at all on content of those Encoding legacy-coverage files. [05:14:22.0948] And lastly I will say that I personally have zero love for maintaining that language-guessing (mis)feature of the HTML checker anyway, and my life would be somewhat easier if I could just rip that feature out entirely. [05:17:37.0953] …but what stops me from doing that is the fact it’s an accessibility-related use case — specifically, trying to make sure that people aren’t just cargo-cult-copying lang=en into every document, despite the actual language of the document’s content) [05:18:12.0983] In other words, it’s not something I added to the checker myself on a whim. And I don’t have any replacement for it at hand that would do the job any better. [06:00:10.0966] FWIW, I think it's fine. Suppressing it was not too much work. [06:00:31.0251] Yeah, that said, I don’t exactly strongly disagree the standard necessarily _shouldn’t_ have such a “missing cell” concept. But as currently written, it doesn’t. I don’t personally care that much about it either way. But it’s just the thing of, making the checker conform to the spec requires doing what the spec actually says, rather than what I or anybody else thinks it rightly _should_ say instead. 2025-12-04 [06:06:54.0442] Noam Rosenthal: can the fetch-later branch on whatwg/fetch be removed? [06:10:00.0800] Sure! [10:03:39.0132] annevk: for https://github.com/whatwg/meta/pull/367 it seems whatwg/html doesn't have this label. I guess I missed a step? [10:06:18.0116] zcorpan: you need to run `labels.py --update` manually [10:57:27.0620] sorry i was on vacation since tpac and just got back, im looking now 2025-12-05 [03:33:54.0467] annevk smaug I got a debrief from Noam Rosenthal yesterday about https://github.com/whatwg/html/issues/11982#issuecomment-3614418258 but just want to confirm my understanding before writing any comments. The only difference between contentmethod=append and contentmethod=replace-children is that the latter removes children in one step. Is the hope that append isn't needed because it could be done with marker nodes instead? Is the main benefit having just one method (and thus a boolean attribute) or is append in particular troublesome? [05:13:38.0795] I wrote https://github.com/whatwg/html/issues/11542#issuecomment-3616886398 [08:09:51.0189] foolip: I think my hope is having one method and not needing the attribute at all (as we already have other attributes). It also feels a little weird to have "replace" and "append", but not the others. Need to think about it some more. [08:16:21.0432] foolip: my comment about append was mostly that it is very much unclear in the explainer that what it does. [08:16:32.0109] Not sure replace-children is very clear either [08:18:52.0370] "replace-children is the basic one that allows replacing a placeholder with its contents". 'placeholder' there might refer to the element which has contentname, or it might refer to the content of the element which has contentname. And 'its' refers somehow to placeholder in that sentence [08:19:00.0869] Anyhow, I should probably read some pr [11:57:14.0400] smaug: I see, I honestly haven't looked at the explainer in a while, should give it a refresh to align with decisions made in the PR. [11:58:47.0691] smaug: in short, the target element is the one with the contentname attribute. append appends nodes to the target element. replace-children does too, but first removes any existing nodes. 2025-12-08 [23:51:08.0387] TabAtkins: hmm, was Python 3.12 really needed? This'll be a bunch more work. Oh well. [00:14:50.0985] Bumping stuff in https://github.com/whatwg/spec-factory/pull/81. If anyone wants to bump Node and make sure participate.whatwg.org doesn't fall over I'd appreciate it. [00:35:28.0314] I find these patching "methods" rather clunky and mechanical. Wouldn't `` work here? [00:35:42.0750] * I find these patching "methods" rather clunky and mechanical. Wouldn't `` work here? (posting here instead of the issue, because I am not sure :)) [02:47:33.0886] It doesn't. It requires you to think of your whole document as a shadow root and that has too many side effects [03:00:55.0098] ... the initial version of this was a element but it was a lot more difficult to reason about. It meant either doing something like having a giant shadow tree inside the body, and then having to remember which parts are "shadow" and which are "light", or create a new type of shadow roots which nobody has appetite for. [03:03:29.0818] In the end "patching" is what a lot of frameworks/sites do for out-of-order streaming, but with scripting and unsafe proprietary server-client protocols. Happy to consider suggestions on how to make the API feel less clunky; It is a bit of a low level API and some of the API decisions were made to support doing this while being fairly XSS-protected. [07:06:33.0643] > <@annevk:matrix.org> TabAtkins: hmm, was Python 3.12 really needed? This'll be a bunch more work. Oh well. 3.9 went EOL in October and no longer receives security updates, so I had to bump it. 3.12 seemed like a decent version to jump to, based on looking around a little bit. [07:08:20.0289] TabAtkins: is it tested with 3.14 as well? [07:08:34.0380] That way I can bump all of WHATWG and not worry about it for the next several years (I hope). [07:08:46.0309] It is, yes [07:09:19.0750] zcorpan: can you review the spec-factory PR? [07:15:36.0739] annevk: what does `@@build_with_node@@` do? [07:18:58.0630] zcorpan: it outputs node stuff if a specification needs that; see https://github.com/whatwg/webidl/blob/main/.github/workflows/build.yml for some example output [07:20:26.0568] annevk: ok. reviewed [12:49:14.0584] Hi all, just a friendly reminder to post any discussion topics for this Thursday's joint CSSWG/WHATWG/OpenUI task force meeting to the meeting agenda issue: https://github.com/whatwg/html/issues/11889 2025-12-09 [06:27:59.0979] smaug: https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md is updated now, and explains what append and replace-children do now. [06:30:08.0155] annevk: https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#interleaved-patching has an example using append and a bunch of alternatives. Having written it down, I quite like the simplicity of the "Automatic defaults" alternative in common cases, but it would be good to get your take on this. 2025-12-11 [02:18:43.0690] annevk or Dominic Farolino do you want to take another pass at https://github.com/whatwg/html/pull/11560 ? [06:22:22.0714] What am I doing wrong: https://github.com/whatwg/html/pull/11519 If I look at "Files changed", the pr talks about `entry global objects` and such, but if I click (diff), the changes are about `inclusive descendant navigables of target` [06:23:31.0617] Perhaps (diff) is pointing to an older variant of the PR? [06:24:52.0159] smaug: looks like he force-pushed Oct 4 but the PR preview is from Aug 5 [06:25:49.0834] I kicked it, let's see if it works [06:25:56.0363] thanks [06:26:36.0810] Feels error prone to allow this kind of situation where someone might be reviewing the diff and someone else the pr, and those might be totally different things. [06:29:07.0005] Yeah. Maybe there should be a date and sha above the PR preview links, so it's easier to tell if it's out of date [06:48:13.0434] smaug: filed https://github.com/tobie/pr-preview/issues/171 [07:35:32.0842] Hey gang! I realized that I have a team meeting I need to be at during our regular WHATNOT triage time. I've set up the agenda in the doc, and I'll get the minutes sorted out afterward. There are currently only two items on the agenda. Can someone else just kick the meeting off and chair? I'll try to duck out of the meeting and join if I can. [07:40:59.0406] cwilso: can do. Hope you got some sleep! [07:43:25.0993] we have more than two items on the agenda, I think there were 2 agenda requests on the meeting issue [07:51:00.0139] Noam Rosenthal: there are only two things here: https://github.com/whatwg/html/issues/11889 [07:52:52.0305] There are also two issues that are not there that I've put Agenda+ on: https://github.com/whatwg/html/issues?q=state%3Aopen%20label%3A%22Agenda%2B%22 [09:05:33.0863] ah sorry that was for the joint meeting, not the whatwg meeting, i got mixed up [10:30:48.0351] the base appearance listbox PR is ready for review and has all checkboxes completed: https://github.com/whatwg/html/pull/11758