2026-04-01
[00:32:36.0090] <hsivonen>
annevk: I don't know bidi well enough to reason about the proposed rules and what happens to the attack surface. Anecdotally, the current situation does not seem as bad practically than abstract reasoning suggests: So far, there haven't been actual Web compat issues arising from the current rules ending up on my plate to fix, and the reported cases of rejected names were attack host names. I mainly care about not having to make the `is_passthrough_ascii_label` function at https://github.com/servo/rust-url/blob/main/idna/src/uts46.rs#L143 _stricter_. The current bidi check is a bit simpler in the sense that one the domain as a whole is found to be a bidi domain, you don't need to care about the positions of the labels to do further checks, but once the checking is triggered, it doesn't seem too onerous to have a bit of extra state to have different rules for different labels such that labels that we'd remember the status of the most recently checked label so that if the label after it a bidi label, we'd do a deferred decision on the status of the label immediately before the bidi label.

[00:33:41.0718] <hsivonen>
* annevk: I don't know bidi well enough to reason about the proposed rules and what happens to the attack surface. Anecdotally, the current situation does not seem as bad for Web compat practically as abstract reasoning suggests: So far, there haven't been actual Web compat issues arising from the current rules ending up on my plate to fix, and the reported cases of rejected names were attack host names. I mainly care about not having to make the `is_passthrough_ascii_label` function at https://github.com/servo/rust-url/blob/main/idna/src/uts46.rs#L143 _stricter_. The current bidi check is a bit simpler in the sense that one the domain as a whole is found to be a bidi domain, you don't need to care about the positions of the labels to do further checks, but once the checking is triggered, it doesn't seem too onerous to have a bit of extra state to have different rules for different labels such that labels that we'd remember the status of the most recently checked label so that if the label after it a bidi label, we'd do a deferred decision on the status of the label immediately before the bidi label.

[00:35:01.0415] <hsivonen>
(`is_passthrough_ascii_label` passes through labels that are ASCII and that will be allowed whether or not the domain ends up being a bidi domain name.)

[00:37:50.0107] <hsivonen>
Currently my main annoyance is that `is_passthrough_ascii_label` has to reject `1password` and `9to5mac`, so the perf is pessimized even though what follows is as plain as `.com`. But realistically, it's not too bad that these domains don't get the same perf as domains that don't start with a digit.

[00:40:41.0834] <hsivonen>
These names are still faster to process than various other names that are so fast that IDNA isn't what makes browsers slow anyway.

[02:33:44.0494] <sideshowbarker>
Anybody know if there’s a channel/room some place where people from different browser engines who work on implementing accessibility/AT/screen-reader support get together to chat?

[02:35:43.0206] <sideshowbarker>
I mean for the parts of the engine that communicate with the platform-specific accessibility APIs: AX/NSAccessibility on macOS, ATK/AT-SPI2 on Linux, and whatever the names of the equivalent Windows APIs are.

[02:36:26.0765] <Ms2ger>
Alice (🇳🇱) might know

[02:42:37.0813] <Alice (🇳🇱)>
if there is I wasn't invited :( but either way we should make a new one

[02:44:10.0300] <sideshowbarker>
Howdy Alice 🙂 Yeah, let’s figure out a place that’d be agreeable to everybody, and make a room there

[02:50:09.0511] <Alice (🇳🇱)>
it's an awkward time of day for both east-coast Australia and all of north America but I'll ping some folks and see who'd be interested (and if my invite got lost in the mail for any hypothetical existing space)

[02:51:06.0584] <sideshowbarker>
No rush, anyway. But looking forward to having it :)

[06:05:04.0521] <Alice (🇳🇱)>
Splitting this out to a thread just avoid spamming everyone. Jamie Teh didn't know of anything either, and he'd be happy to join.

[06:06:01.0480] <Alice (🇳🇱)>
We agreed Slack or Matrix would probably be the best platforms; he said Slack is somewhat more accessible for him, but that he also already uses Matrix and finds it ok on desktop other than (ironically) threads

[06:06:17.0470] <Alice (🇳🇱)>
I'm waiting for the west coast to wake up to ping some WebKit folks :) 

[06:06:58.0789] <Alice (🇳🇱)>
I'm not even sure who I'd ping on Blink any more :( but others may know

[06:12:18.0052] <sideshowbarker>
I see Joanie touched some ui/accessibility sources in there a couple months back.

[06:12:42.0918] <sideshowbarker>
Would be great to have Joanie joining, regardless

[06:20:40.0949] <sideshowbarker>
This is what I find for the top of a `git shortlog` of the last 6 months for the `ui/accessibility/platform` tree:

    12  Benjamin Beaudry <benjamin.beaudry@microsoft.com>
     6  Jacques Newman <janewman@microsoft.com>
     5  Lei Zhang <thestig@chromium.org>
     4  Ramin Halavati <rhalavati@chromium.org>
     3  David Tseng <dtseng@google.com>
     3  Victor Hugo Vianna Silva <victorvianna@google.com>
     2  Alexander Surkov <asurkov@igalia.com>
     2  Avi Drissman <avi@chromium.org>
     2  Benjamin Beaudry <bebeaudr@microsoft.com>
     2  Carlos Barrera <carlosbarrera@google.com>
     2  Carlos Marcelo Barrera Nolasco <carlosbarrera@google.com>
     2  Chris Davis <chrdavis@microsoft.com>
     2  Fernando Fiori <ffiori@microsoft.com>
     2  Greg Thompson <grt@chromium.org>
     2  Kyra Seevers <kyraseevers@google.com>
     1  Aaron Leventhal <aleventhal@google.com>



[06:22:31.0514] <sideshowbarker>
And for `ui/accessibility`:

```
   14  David Tseng <dtseng@google.com>
    12  Benjamin Beaudry <benjamin.beaudry@microsoft.com>
    11  Lei Zhang <thestig@chromium.org>
     9  Aaron Moss <aaronmoss@google.com>
     8  Ramin Halavati <rhalavati@chromium.org>
     7  Victor Hugo Vianna Silva <victorvianna@google.com>
     6  Akihiro Ota <akihiroota@chromium.org>
     6  Jacobo Tapia <jatapiaro@google.com>
     6  Jacques Newman <janewman@microsoft.com>
     6  Jocelyn Tran <jocelyntran@google.com>
     5  Alexander Surkov <asurkov@igalia.com>
     5  Chrome Release Translations <mdb.chrome-release-translation-dump@google.com>
     5  Martin Kong <martinkong@google.com>
     4  Lauren Winston <lwinston@google.com>
     4  Mark Schillaci <mschillaci@google.com>
```

[06:42:05.0207] <zcorpan>
annevk: for https://github.com/whatwg/fetch/pull/1898 , I've now merged the HTML PR

[06:52:13.0675] <annevk>
Ok cool, I merged CSP & Fetch

[06:57:22.0305] <zcorpan>
Thanks!

[07:05:46.0949] <sideshowbarker>
by the way, this is what I’ve been working on:

https://github.com/LadybirdBrowser/ladybird/pull/8603


2026-04-02
[00:50:47.0184] <Jake Archibald>
annevk: I think me and mfreed agree on a set of changes to `popover=hint`, so it'd be good to get some WebKit thoughts on it at today's WHATNOT. It's part of Interop, but I don't think WebKit have started work on it.

[02:05:27.0802] <annevk>
Jake Archibald: I suspect that should be fine. Pointer?

[02:06:46.0139] <Jake Archibald>
annevk: https://github.com/whatwg/html/issues/12304#issue-4121948352 has videos of all the issues, and a proposed behaviour

[02:07:30.0225] <Jake Archibald>
annevk: I wrote some pseudo-spec for it at https://github.com/whatwg/html/issues/12304#issuecomment-4120000430

[08:14:20.0026] <annevk>
I don't think I'll be able to make it today, but popover=hint changes seem okay. I do think we need to have agreed specification changes in soon though.

[09:00:25.0298] <smaug>
hmm, Meet gives me some error

[09:03:54.0717] <smaug>
Apparently a regression in Nightly which was fixed already 

[10:55:21.0709] <Lea Verou>
Belated regrets for today, at the CSS WG F2F

[11:09:54.0835] <krosylight (they/them)>
re: https://github.com/whatwg/streams/issues/1365, when do we exactly use `abstract-op`?

[13:33:24.0934] <TabAtkins>
value was added at Anne's request, iirc, so annevk would have a better answer

[13:33:34.0386] <TabAtkins>
(I don't use it, personally.)


2026-04-03
[00:20:13.0037] <annevk>
It's mainly for when you want to emulate the ECMAScript specification. I thought we'd go harder in that direction specification-wise, but we mostly stuck with `dfn`.


2026-04-04
[22:40:35.0373] <aresuii>
https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/javax/swing/text/html/HTMLEditorKit.html

[22:41:49.0895] <aresuii>
so i've been messing about with making a swing-based browser [code or snippets later] and was wondering how much newer stuff could be built out of the things it already supports

[22:42:14.0606] <aresuii>
already have graaljs in my project, isn't integrated properly tho

[23:04:05.0056] <aresuii>
also haven't written a line in a few days

[23:05:55.0515] <aresuii>
* already have graaljs in my project, isn't really integrated properly tho

[23:06:18.0973] <aresuii>
like for example noscript blocks don't get hidden yet


2026-04-06
[10:30:03.0639] <jarhar>
do we have any guidance on whether new events should bubble or not?

[10:31:52.0933] <jarhar>
for context, i am prototyping a new "beforefilter" event for filterable select and base appearance input+datalist.


2026-04-07
[00:02:25.0128] <annevk>
I think we generally make events bubble, but it might be worth investigating some other recent introductions.

[00:02:55.0246] <annevk>
But also, I wish we'd focus on fixing all the existing issues with customizable <select>. There's way too many.

[02:27:08.0197] <Noam Rosenthal>
Generallly events that relate to interaction bubble (click, keydown, change, submit) and other events (media progress, load, error, formdata) don't. though this has some exceptions that are not always obvious. "beforefillter" should perhaps bubble if you want to be able to handle it at the form level for example. 

[02:38:23.0280] <Noam Rosenthal>
(this is by judging from existing events, not from some official guidance)

[04:31:02.0418] <Noam Rosenthal>
annevk: mind looking at https://github.com/whatwg/html/pull/12266 when you get a chance? It has been ready for review for a while and is quite small

[04:43:02.0557] <annevk>
Looks good modulo nit.

[12:43:53.0846] <nektro>
does the note "no elements will be added to HTML, SVG, or MathML with hyphen-containing local names going forward" apply to attribute names as well?

[12:44:50.0664] <nektro>
ie is it html's purview to leave unhyphenated names to html and hyphenated names to devs?

[12:45:55.0113] <nektro>
* ie is it html's purview to leave unhyphenated attributes to html and hyphenated attributes to devs as well?

[12:46:58.0728] <Noam Rosenthal>
aria and svg have hyphenated attribute names. The official userspace for attribute is `data-*` afaik

[12:48:40.0169] <Noam Rosenthal>
but there is a "consistency" somewhat unofficial rule to keep names concatenated without a separator, see https://www.w3.org/TR/design-principles/#casing-rules

[12:57:13.0723] <Luke Warlow>
> <@noamr:matrix.org> aria and svg have hyphenated attribute names. The official userspace for attribute is `data-*` afaik

I guess with custom attributes that might change to more generally allow hyphenated userland attributes?

I think we generally shouldn't add new hyphenated ones as built-ins personally.

[12:57:26.0018] <Luke Warlow>
* I guess with custom attributes that might change to more generally allow hyphenated userland attributes?
I think we generally shouldn't add new hyphenated ones as built-ins personally. 

[13:15:49.0770] <Noam Rosenthal>
Yea I agree that making that semi-official API design principle something more official can be useful (with `aria-` being an exception)

[13:16:42.0322] <Noam Rosenthal>
(Also `http-equiv` and `accept-charset` if we want to be archeological about it)


2026-04-08
[06:56:25.0221] <krosylight (they/them)>
annevk: Would you be more open to:

1. removing abstract-op (this will also change the references from `[$..$]` to `[=...=]`)
2. or adding no-export to them

?

[08:33:52.0276] <Jake Archibald>
annevk: https://github.com/whatwg/html/pull/12345 here's my proposed changes to `popover=hint`.


2026-04-09
[00:14:37.0982] <annevk>
Jake Archibald: did an editorial pass. Will let someone else verify the logic.

[00:17:44.0631] <Jake Archibald>
annevk: are you happy with it landing without someone from WebKit verifying the logic? 

[00:34:56.0520] <annevk>
Yeah, that seems okay. If we hit issues when implementing we can always raise those at that point, but that is hopefully unlikely given the amount of vetting it will have had by then. (Assuming people still actually read the specification.)

[01:25:28.0507] <annevk>
foolip: seems like a long shot, but do you perhaps remember how the `muted` attribute of media elements is supposed to work? The description is essentially prose, which isn't great. It kinda suggests that script mutations should not work, but we don't really distinguish those from the parser setting attributes in the specification.

[01:27:15.0916] <foolip>
The content attribute is reflected as `defaultMuted` and only affects the real `muted` IDL attribute at one point.

[01:27:33.0783] <Jake Archibald>
(independent folks like Luke Warlow are looking at it)

[01:30:06.0804] <annevk>
foolip: I think specifically the problem is this sentence: "When a media element is created, if the element has a muted content attribute specified, then the muted IDL attribute should be set to true"

[01:33:38.0254] <annevk>
foolip: for instance, when cloning we'd first create the element and then copy the attributes, but the tests assume that .muted returns true for that case.

[01:34:52.0735] <annevk>
foolip: and the parser also does not create an element with all of the attributes at once.

[01:35:07.0936] <annevk>
I guess I'll file a specification issue.

[01:35:59.0063] <foolip>
OK, so the issue is exactly when the content attribute is supposed to be read.

[01:36:15.0011] <annevk>
Ah, https://github.com/whatwg/html/issues/5013 

[01:37:22.0247] <foolip>
Looks like Blink only respects the content attribute if set by the parser

[01:40:26.0636] <foolip>
annevk: is there establish spec language for special-casing the parser but not cloning?

[01:41:18.0063] <annevk>
foolip: https://wpt.fyi/results/html/semantics/embedded-content/media-elements/user-interface/muted.html suggests otherwise.

[01:42:49.0589] <annevk>
And no, none of those subtleties are supposed to be available. But engines had them for optimizations maybe and it got never cleaned up and then features started to depend on it.

[01:43:16.0208] <foolip>
OK, a proper code search also finds that cloning is handled

[01:44:13.0583] <foolip>
Those are the two places the attribute is read in addition to the `defaultMuted` generated bindings.

[01:47:10.0513] <annevk>
Thanks for checking! I've agenda+'d it with some added context.

[01:49:28.0539] <foolip>
I linked the code in a comment. Does WebKit not do the cloning bits?

[03:10:39.0073] <Jake Archibald>
* (independent folks like @lwarlow:igalia.com are looking at it) (edit: this was in relation to popover=hint but I hadn't received the other messages at the time)

[03:11:12.0046] <Jake Archibald>
annevk: https://github.com/whatwg/infra/pull/706 https://github.com/whatwg/infra/pull/707 - slice & reverse for infra

[03:18:38.0887] <zcorpan>
Jake Archibald: we should have "flip and reverse" also :)

[03:21:25.0804] <Jake Archibald>
annevk I see you're correcting "If [condition], then:" to "If [condition]:" - the former used to be the convention right?

[07:51:48.0963] <Luke Warlow>
Do we have the joint taskforce meeting today? I can see it on the calendar but can't find an agenda

[07:59:02.0012] <Noam Rosenthal>
https://github.com/whatwg/html/issues/12291

[08:13:31.0287] <annevk>
Jake Archibald: yeah, we decided that when followed by : you don't need it and it's nicer when it's shorter

[08:14:25.0282] <annevk>
foolip: WebKit doesn't have the creation-time semantic

[08:14:54.0309] <annevk>
(Will try to review slice & reverse tomorrow. Others are welcome to that as well of course.)

[09:04:13.0366] <Usama Nadeem>
annevk: do you have any idea about the timeline? I mean, how long does it usually take for someone to review my PR?
https://github.com/whatwg/fs/pull/182
And who is the person responsible for reviewing the PR?

[09:50:32.0074] <zcorpan>
Luke Warlow: re "appearance:none still exposes some OS stuff I think", is there anything that's not "top layer"?

[09:50:46.0508] <zcorpan>
I guess `file`

[09:53:48.0450] <Luke Warlow>
The range input's thumb is an odd one that I *think* might still be OS dependent

[09:54:49.0450] <Luke Warlow>
But yeah also stuff like Safari file input which has image preview.

Perhaps we should define an appearance:none for file input anyway though? Seeing as we're defining appearance to apply to it for base mode

[09:55:37.0042] <zcorpan>
Luke Warlow: we probably can't change what appearance: none does for `file` for web compat

[09:56:11.0692] <zcorpan>
At least I expect making the button "appearance: none" fugly will result in user complaints for real sites

[09:56:35.0900] <Luke Warlow>
We could define it to render the button in appearance:auto and the label and not allow for stuff like the file image preview. Which is probably far less breaking?

[09:56:40.0817] <Luke Warlow>
But probably not worth it

[09:56:53.0690] <zcorpan>
Maybe

[10:00:32.0795] <annevk>
I've given up on making "none" good. I've not given up on making it well-defined and interoperable.

[10:02:06.0624] <smaug>
cwilso: was that your last WHATNOT? If so, thank you 🙂 


2026-04-10
[20:34:11.0710] <jmdyck>
In https://html.spec.whatwg.org/#common-input-element-events, 3rd para, toward the end, it might be
> the user agent must (1) queue a task ... and (2) fire an event ...
or

[20:35:10.0674] <jmdyck>
* In https://html.spec.whatwg.org/#common-input-element-events, 3rd para, toward the end, it might be

> the user agent must (1) queue a task ... and (2) fire an event ...
or
> the user agent must queue a task ... to (1) set its validity.. and (2) fire an event...

[20:35:21.0418] <jmdyck>
* In https://html.spec.whatwg.org/#common-input-element-events, 3rd para, toward the end, it might be

> the user agent must (1) queue a task ... and (2) fire an event ...

or
> the user agent must queue a task ... to (1) set its validity.. and (2) fire an event...

[20:36:52.0841] <jmdyck>
I'm pretty sure it's the latter, but it seems like that could be  clearer.

[20:44:47.0372] <jmdyck>
In prose, you could distinguish the two by inserting a "both", e.g.
> the user agent must both queue a task and fire an event

or
> the user agent must queue a task to both set its validity and fire an event

but it might be clearer to use an `<ol>` or `<ul>`.

[20:45:24.0566] <jmdyck>
Could the whole para be more list-ified?

[21:15:33.0758] <jmdyck>
It's one enormous sentence.

[23:42:53.0588] <annevk>
Yeah I think that would be a good change.

[04:19:56.0804] <emilio>
annevk: FWIW I just left a question in https://github.com/web-platform-tests/wpt/pull/57959#issuecomment-4223338679 (just saw the failure during triage). I'm not sure that expectation is justified? It doesn't match any other pseudo-element

[05:12:24.0231] <annevk>
emilio: yeah that does seem wrong. I can take a look later today but feel free to overwrite if you have something going already.

[05:12:55.0179] <annevk>
(Perhaps that test should be collapsed into the other pseudo-element tests.)

[05:18:17.0131] <emilio>
annevk: I think having the test separately is fine, either way tho... https://phabricator.services.mozilla.com/D293487 if you want to stamp :)

[05:19:08.0214] <emilio>
(cc keithamus ^)

[05:20:52.0169] <annevk>
emilio: hmm but what should happen when there's nothing in the style sheet?

[05:22:23.0402] <annevk>
Because now it's testing something slightly different as far as I can tell.

[05:36:58.0918] <emilio>
annevk: I mean, same thing? Style is resolved, just no rules applied, so default style inheriting from parent

[05:37:08.0053] <emilio>
annevk: but happy to test that as well i guess by adding another div

[05:40:48.0598] <annevk>
emilio: WebKit will pass with your change, pretty sure

[05:41:11.0672] <annevk>
So you'll be hiding the bug.

[05:43:11.0859] <annevk>
We pass existing ::file-selector-button tests around this for instance despite those using pretty much the same code path. Except the tests for that have an existing style rule.

[05:46:54.0966] <emilio>
annevk: ok, that's rather bizarre... Added a test for that

[07:24:01.0782] <annevk>
emilio: if you're curious: https://github.com/WebKit/WebKit/pull/62444 

[07:32:19.0024] <emilio>
annevk: sweet!

[13:01:40.0117] <Usama Nadeem>
hello there someone could tell me do It take more time? Im asking about the PR! and if theres some issue please do let me know!


2026-04-11
[03:04:16.0877] <Noam Rosenthal>
Several people were on extended easter holidays, I'll try to wake up some folks next week


2026-04-14
[17:59:59.0312] <jmdyck>
In wording such as "abort the image request, queue an element task ... to restart the animation if restart animation is set, and return", I'm looking at the phrase "if restart animation is set".

It's ambiguous whether it associates with the "queue" or the "restart". Probably the latter (i.e. the check of 'restart animation' happens when the task runs), but it's unclear how I'm supposed to know that. Should I assume that an 'if' like that always associates with the most recent verb?

[20:14:34.0836] <Kaiido>
In that case I'd assume it's the whole "queue a task to X" that's conditional to this "if"; it would be weird to queue a task to do nothing. Maybe placing that "if" at the beginning of the clause would be clearer, and maybe using a sub-list would be even clearer.

[20:18:05.0560] <jmdyck>
It would indeed be weird to queue a task to do nothing, if you knew at the time of queuing that it would do nothing. But in this case, I don't think you know, because you don't know if 'restart animation' will be set at the time the task runs.

[20:21:17.0371] <jmdyck>
But anyhow, it's useful to see that someone can reach a different conclusion about how the 'if' attaches: shows there's some need for disambiguation.

[20:22:24.0769] <Kaiido>
I took *restart animation* as the param passed to the call to `update the image data` not as the mutable flag anymore.

[20:27:26.0032] <jmdyck>
Hm, yeah.

[20:29:34.0987] <jmdyck>
Yeah, now i'm leaning to the 'if' attaching to the 'queue', like you say.

[23:08:03.0532] <annevk>
I think it could do with a rewrite to use nested steps instead. The "if" at the end is always awkward and probably a sign you should reword.

[23:08:32.0033] <annevk>
Except in very trivial ternary cases I suppose.

[01:35:01.0505] <Luke Warlow>
Fwiw I find these prose conditionals really hard to grok quite often. Even in fairly trivial cases it takes an extra second to realise oh this is a conditional thing and it's also harder to write and get the grammar right too. I wouldn't even mind this being split into an ol and two lis. I think single line ifs without the steps only really work if it's a single inner step

[06:07:41.0395] <annevk>
Anyone interested in reviewing https://github.com/whatwg/url/pull/904? (A couple of minor changes.)

[07:36:34.0618] <annevk>
keithamus: it seems serialization order in the test is still mismatching with the standard; I'll put up a PR

[08:28:50.0282] <annevk>
Did nobody file an issue yet on PR Preview not working? I just filed https://github.com/tobie/pr-preview/issues/176 

[08:50:30.0542] <annevk>
Andreu Botella: just a draft for now based on your work, but hoping to make multipart/form-data happen finally: https://github.com/whatwg/fetch/pull/1922

[08:50:53.0661] <Andreu Botella>
oh, that's awesome

[08:51:08.0266] <Andreu Botella>
i don't know if i'll have much time to help here soon

[08:51:17.0593] <Andreu Botella>
but I'll be keeping an eye on it

[09:10:45.0529] <Luke Warlow>
I did think that it was missing on your URL pr but assumed that maybe it was only on DOM and HTML.

[14:17:00.0657] <mfreed>
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/12351


2026-04-15
[00:42:25.0329] <annevk>
TabAtkins: if you have any idea what might be the cause of https://github.com/w3c/spec-generator/issues/765 I'd appreciate it. I guess ideally we just have one build path, but then we'd need to feed PR Preview the results of our build output somehow. Which maybe we could do, but it'd be work I'd rather avoid.

[02:30:05.0861] <keithamus>
https://github.com/whatwg/html/pull/12373 runs `specfmt source` and commits it, as trying to run `specfmt` causes noisy diffs making it less disirable to use. Feel free to close if we don't think this is important. 

[02:42:41.0644] <annevk>
That's a lot smaller than what I would have expected. Did you spot check it for accuracy?

[02:43:04.0594] <keithamus>
I did. Couldn't see anything untoward. 

[02:44:08.0067] <annevk>
It seems determined to keep <dt>s on a single line.

[02:44:16.0089] <annevk>
Not sure that's actually our style.

[02:45:23.0920] <annevk>
The other changes look good though. Dominic Farolino ^^

[04:30:39.0971] <Noam Rosenthal>
Details aside, I think this is a good idea. git is capable of following beyond a single change so clobbering history with this is not a huge problem

[05:33:36.0687] <annevk>
Yeah, it seems fine but I'd like some more eyes on the <dt> changes. Definitely if you follow back blame you'll find many Hixie commits that changed wrapping across the entire specification. They're slightly annoying, but also easily skipped.

[09:12:50.0672] <zcorpan>
Need --full-spec to get it to process all lines.

[09:33:22.0760] <annevk>
keithamus: not sure when you stop working but if you or a colleague could fixup and land https://github.com/web-platform-tests/wpt/pull/58713 in the next 24h that'd be great; I'll pre-approve

[09:34:52.0562] <keithamus>
done. 

[09:35:45.0435] <keithamus>
thanks for landing https://github.com/whatwg/html/pull/12267! 

[10:07:10.0292] <TabAtkins>
annevk: looking into it


2026-04-16
[23:10:19.0777] <annevk>
I disabled comments on commits for a bunch more WHATWG repositories. I don't think anyone has been relying on that as I would've seen it, but let me know if this creates a problem.

[23:11:12.0515] <annevk>
Also, if someone has a connect at GitHub that could turn that into an organization setting: I think we'd love that.

[00:05:03.0200] <sideshowbarker>
I had completely forgot I’d said I was gonna do that, sorry

[00:56:54.0865] <annevk>
I will be a bit late, but do plan to attend WHATNOT

[01:59:18.0748] <Noam Rosenthal>
(For `muted`):

  On September 25, 2010 IRC:
  > "[04:18] <Hixie> i don't see any way to have a muted="" content attribute that is reflected by the IDL attribute, since it would mean that if the user had requested a blanket mute of all audio... it would magically sprout a muted="" attribute in the DOM each
  time the document was parsed"

So it sounds like a `defaultValue` sort of reasoning

[02:02:43.0657] <annevk>
Right, but that doesn't explain the creation-time magic.

[02:02:44.0714] <Noam Rosenthal>
annevk: where did you see that an import map key is a tuple? https://html.spec.whatwg.org/multipage/webappapis.html#module-specifier-map seems to be string->url

[02:03:35.0612] <annevk>
Noam Rosenthal: I thought we were discussing the module map. Was I confused?

[02:05:16.0284] <Noam Rosenthal>
Yes I think so. The `<style specifier="...">` thing changes the *import map* which doesn't have a "type" but probably should in some form

[02:05:18.0773] <annevk>
I think I did read out loud "A module map is a map keyed by tuples consisting of a URL record and a string." so if I was confused nobody corrected me at the time.

[02:06:02.0142] <Noam Rosenthal>
Yes, the module map is keyed by tuples. So that's where the confusion is

[02:08:31.0746] <annevk>
Sorry, I still haven't entirely wrapped my head around these `<style>` proposals. I find it weird that'd we have `<style specifier>` but not `<script specifier>` for instance. But yes, I can see how it could be used to clobber the import map. (I'm pretty sure someone said module map though and we also discussed the fetching pipeline of these things, none of which really apply to inline style sheets.)

[02:10:32.0680] <Noam Rosenthal>
Agreed, I think it's a design issue with `<style specifier>`. We need a type-safe way to define styles in importmap so that it fetches them with the right fetch destination, regardless of the new `<style specifier>` thing.

[02:13:07.0409] <Noam Rosenthal>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13327 alludes to this is a way to prevent extra `volumechange` events. but anyway I'll leave this to foolip 

[02:13:55.0898] <annevk>
TabAtkins: Denis from the W3C found that Bikeshed behaves differently between URL and file input. He commented on the issue.

[02:15:15.0153] <annevk>
Noam Rosenthal: no I don't think, before that it already had the "When a media element is created" magic. The problem is that you can't actually observe attributes when an element is created. It's always created without attributes.

[02:15:23.0106] <annevk>
* Noam Rosenthal: no I don't think so, before that it already had the "When a media element is created" magic. The problem is that you can't actually observe attributes when an element is created. It's always created without attributes.

[02:35:54.0414] <Noam Rosenthal>
ah ok `importmap` is just a specifier/url map and that's fine. it doesn't fetch anything (only the module map does). This is an issue with allowing a `<style>` element to have impact on shadow-piercing global state. There is no CSP issue

[04:08:24.0877] <Luke Warlow>
I notice that WPT now has test262 in a third_party folder. I wonder if something similar could be done for https://github.com/html5lib/html5lib-tests? I seem to recall mention of moving it to WPT recently but can't find where that was (might have been on the select parser changes)

[04:13:50.0938] <jgraham>
Note that https://github.com/web-platform-tests/wpt/tree/master/html/syntax/parsing has the html5lib tests, just directly converted to a form that allows them to be run in browsers, rather than doing the conversion at runtime.

[04:16:22.0310] <Luke Warlow>
Huh, TIL in that case maybe we don't need to do anything.

[04:21:16.0480] <jgraham>
Unrelated:

https://github.com/w3c/webdriver-bidi/pull/1061 tries to define a "specification realm" which is essentially a construct for calling specification text that assumes it's running as part of script execution, without that script execution being visible to web content (e.g. via global error handlers, or unhandled promise rejection events or similar). The use case is stuff like getting a network stream from some call to `fetch` and wanting to be able to read that stream without accidentally leaking that read to content.

Is this a bad idea? :) The alternative where we try to run algorithms in whatever content realm makes the most sense (e.g. the one associated with the document or worker that initiated a network request) seems like it might work for most(?) cases, but with the cost that we need to plug every case where the execution could leak to the web content.

[04:22:51.0692] <jgraham>
Yeah, I don't think we _need_ to do anything. The issue you mentioned is based on the idea that wpt should be the canonical home of these tests, and libraries like html5lib should import them, rather than the other way around. That has merit, but it's not necessary per-se.

[05:14:07.0779] <Ms2ger (🌴 back 15 April)>
Perhaps one notable risk is that you're calling into specification prose that expects the realm it gets is a Window, or either a Window or a Worker, and is not well defined in your case

[05:18:35.0874] <jgraham>
Yes, agreed.

[05:35:10.0621] <annevk>
It would make working on the HTML parser a lot easier.

[09:44:23.0126] <annevk>
I wonder how this is actually implemented.

[09:44:53.0635] <annevk>
If we can change the specification in some way so it can be used for such purposes without requiring synthetic realms that'd be better I think.


2026-04-17
[18:14:12.0029] <AvMaster>
configuration zoho

[00:09:15.0687] <annevk>
PR Preview should be fixed now. If you ever notice PR Preview not working please attempt to escalate immediately by opening an issue against the PR Preview repository. Thanks!

[00:09:40.0701] <annevk>
(Credit for fixing goes to Denis (W3C) and Tab!)

[00:09:52.0062] <annevk>
* (Credit for fixing goes to Tobie, Denis (W3C) and Tab!)

[00:09:58.0823] <annevk>
* (Credit for fixing goes to Tobie, Denis (W3C), and Tab!)

[01:31:21.0763] <jgraham>
Well in Firefox it's probably actually implemented by running js in the parent process (or maybe privileged js in the content process, but basically same deal) :p

In other browsers I assume there are native-code APIs to manipulate streams &c. But the spec doesn't consider that possibility.

[04:26:28.0644] <Shannon Booth>
ladybird actually happens to have such a concept which is used for non observable stuff like in shadow trees. but for other things like internal fetch we just use whatever realm is available. it meant we had a bug at some stage where if scripting was disabled (like in a sandboxed iframe) fetch wouldn't work. https://github.com/whatwg/html/commit/905b7218 fixed that for us though

[04:26:46.0168] <Shannon Booth>
* ladybird actually happens to have such a concept which is used for non observable stuff like in shadow trees. but for pretty much everything else like internal fetch we just use whatever realm is available. it meant we had a bug at some stage where if scripting was disabled (like in a sandboxed iframe) fetch wouldn't work. https://github.com/whatwg/html/commit/905b7218 fixed that for us though

[04:28:29.0442] <Shannon Booth>
* ladybird actually happens to have such a concept which is used for non observable css stuff like in shadow trees. but for pretty much everything else like internal fetch we just use whatever realm is available. it meant we had a bug at some stage where if scripting was disabled (like in a sandboxed iframe) fetch wouldn't work. https://github.com/whatwg/html/commit/905b7218 fixed that for us though

[09:38:42.0453] <Dominic Farolino>
When fetching in parallel, what's the best way to convert a response into JSON? It seems you can't use https://infra.spec.whatwg.org/#parse-json-bytes-to-an-infra-value since it technically expects a realm, but maybe it's "OK" if you handle the errors good enough? Perhaps https://tc39.es/ecma262/#sec-ParseJSON would be better, but it seems unused outside of ES

[10:32:00.0396] <Noam Rosenthal>
seems like multiple specs are using "parse JSON bytes to an infra value"

[10:44:33.0614] <TabAtkins>
Is the realm expectation some transitive dependency buried deep in the call chain? I'm not easily finding it.

[13:12:28.0168] <bkardell>
It’s a shame that https://html.spec.whatwg.org/multipage/html-design-principles is 404 instead of a redirect or explanation - there are external links to it


2026-04-18
[00:28:31.0432] <annevk>
bkardell: that never existed though. Those are probably broken links to https://www.w3.org/TR/html-design-principles/

[00:30:25.0239] <annevk>
Fetching while in parallel in general is not something I would recommend. Preparing a fetch requires all kinds of global state.

[00:31:31.0436] <annevk>
%JSON.parse% needs a realm. This is a known issue: https://github.com/whatwg/infra/issues/625

[01:31:17.0505] <Noam Rosenthal>
I think some specs prepare the request based on a global state and then pass those parameters along to the parallel processing to be fetched later

[06:52:52.0735] <bkardell>
ah weird it is actually a bad w3c redirect

[06:58:33.0492] <bkardell>
links to http://dev.w3.org/html5/html-design-principles/#priority-of-constituencies redirect to the url I shared. I'll let them know

[07:00:28.0013] <annevk>
Even that link seems somewhat suspect, but maybe it was hosted in the same repository at some point. I guess that's plausible. Hard to fathom we worked on that almost 20 years ago now.


2026-04-19
[13:48:17.0394] <bkardell>
Idk, its linked from https://dbaron.org/log/20150318-priority-of-constituencies - 


2026-04-20
[01:00:45.0350] <annevk>
sideshowbarker: can you add a redirect from http://dev.w3.org/html5/html-design-principles/ to https://www.w3.org/TR/html-design-principles/ ?

[01:42:48.0761] <Julian Descottes>
Hi, can someone can look at the review for https://github.com/whatwg/fetch/pull/1860 and let me know if there is anything to update for the WebDriver BiDi / fetch integration ?

[01:47:57.0701] <annevk>
Julian Descottes: I've added a calendar entry for tomorrow as I'm traveling. Apologies for the delay. Looking at the PR it seems like the MDN checkbox needs to be checked still and I don't see a bug for WebKit. I think we've started on WebDriver BiDi so that might be useful. But maybe Sam Sneddon [:gsnedders] thinks otherwise.

[02:24:28.0079] <Julian Descottes>
Thanks! 

I think Sam starting implementing the network module for WebKit indeed. Looking at the tracker the meta for the network module https://bugs.webkit.org/show_bug.cgi?id=281936 probably makes sense here.

I am going to check the box for MDN. We started documenting BiDi on MDN, so I will check if we have an issue already to document the network module, and if not I will file it.

[02:37:14.0298] <Julian Descottes>
* Thanks! 

I think Sam started implementing the network module for WebKit indeed. Looking at the tracker the meta for the network module https://bugs.webkit.org/show\_bug.cgi?id=281936 probably makes sense here.

I am going to check the box for MDN. We started documenting BiDi on MDN, so I will check if we have an issue already to document the network module, and if not I will file it.

[11:29:53.0912] <Sam Sneddon [:gsnedders]>
https://wpt.fyi/results/webdriver/tests/bidi/network?run_id=5080768643858432&run_id=5107343082913792&run_id=5131298195898368&run_id=5067679865241600 at least makes it look like there's no network module, as does https://github.com/WebKit/WebKit/tree/main/Source/WebKit/UIProcess/Automation/protocol

I've also done no implementation work on WebDriver BiDi myself.

My gut would suggest there's a lot less benefit to having a separate issue filed when there's no support yet?

[13:53:01.0550] <Julian Descottes>
ah sorry I'm probably misremembering


2026-04-21
[22:11:15.0506] <sideshowbarker>
Sent a request to W3C systems team to update that. (I no longer have direct access myself to update it.)

[00:21:46.0471] <sideshowbarker>
ah — seems they’d already fixed it. I guess a request from Brian must’ve already bubbled up to them.

[01:02:37.0837] <zcorpan>
Patrick Meenan: ping https://github.com/HTTPArchive/httparchive.org/issues/971

[07:35:02.0855] <jgraham>
I think one problem with requiring that scripts run in a content realm is what happens if that realm is navigated.

With stream support in WebDriver I'm not sure if there are cases where we want to be able to access a stream once the underlying document has navigated (or worker has been discarded). I wonder a bit about downloads; if you want to stream a download which realm should that be associated with? If it's the global for the document that initiated the download the stream would certainly have to survive if that document was navigated.

We also kind of wanted to use this mechanism to allow using the existing WebRTC specifications for screen capture, rather than rewriting all the details of how to capture a screen and get the data into a specified format and so on. That would certainly have to survive navigation and so wouldn't work if the spec depended on running algorithms in a specific content realm.

[12:32:00.0221] <Mattias Buelens>
Peter Linss: I've opened a PR for widlparser to properly support `async_sequence<T>`, PTAL 🙂 https://github.com/plinss/widlparser/pull/95


2026-04-22
[06:31:21.0600] <Julian Descottes>
thanks for reviewing and merging!