2026-02-01
[23:38:48.0946] <annevk>
Yeah, when Hixie wrote algorithms we didn't have an established way of writing them yet and not everything he wrote has been refactored. The `img` element could really do with a refactoring of its processing model as well as abstracting some aspects of the fetch pipeline so they can be shared with other image endpoints.

[07:23:49.0192] <jebez>
Hi

See https://www.mediawiki.org/wiki/Project:Support_desk#Why_%3Cbr%3E_instead_of_just_a_new_line?

I created a simple test.html thanks to the 1st example of https://www.w3schools.com/html/html_basic.asp & I discovered the issue of this link is general to HTML, so same question of the link.

[08:30:46.0487] <Ms2ger (FOSDEM)>
Wikitext is not HTML 


2026-02-02
[11:11:54.0191] <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/12104


2026-02-03
[18:10:13.0437] <sideshowbarker>
TabAtkins: Regarding https://github.com/w3c/csswg-drafts/issues/12054#issuecomment-3837656822 I’m trying to figure out what needs to be done — what people want to be done.

[18:11:54.0621] <sideshowbarker>
Question: It seems like all the auto-publishing plumbing that Andreu had originally set up has maybe subsequently been superseded by tooling you set in since then?

[18:12:59.0596] <sideshowbarker>
And to make auto-publishing work for the FXTF and Houdini stuff, I could replicate the workflow y’all currently have set up for the w3c/csswg-drafts repo?

[18:13:18.0476] <sideshowbarker>
/me waves to Andreu Botella too

[18:14:18.0055] <sideshowbarker>
Andreu Botella: I don’t wanna bug you with stuff if you’re swamped and I can manage to get it working without you needing take any time away from what you’re working on n

[18:14:20.0984] <sideshowbarker>
* Andreu Botella: I don’t wanna bug you with stuff if you’re swamped and I can manage to get it working without you needing take any time away from what you’re working on

[18:15:33.0091] <sideshowbarker>
I’m gonna need to step away now from my machine for the next 90 minutes to 2 hours anyway — but I’ll get back to this after that

[18:16:41.0934] <sideshowbarker>
However, if anybody else has more clear idea of what exactly the problems are that need to be solved, and you want to take a shot at doing the set up to fix them, I wouldn’t mind at all if somebody beat me to it… 

[18:20:46.0135] <Andreu Botella>
well, currently the index of specs is still handled by plins's server, and eventually we'd want to get that also generated by the gh actions workflow

[18:21:25.0255] <sideshowbarker>
OK, can definitely do that — probably by end-of-day my time

[18:22:41.0544] <Andreu Botella>
at first bin/build-index.py would build an index, as well as create level-less shortcuts (e.g. css-fonts for whichever the current level is)

[18:23:02.0796] <Andreu Botella>
and for that it'd use various heuristics to figure out which is the current work, with a list of exceptions

[18:23:44.0873] <Andreu Botella>
in my repo there's still a version of that that does generate an index, although it looks quite different from the one in plins's server

[18:25:05.0603] <sideshowbarker>
OK, I’ll take a look

[18:25:30.0127] <sideshowbarker>
the *“various heuristics”* is clearly the hard part…

[18:26:54.0435] <sideshowbarker>
for the csswg-drafts repor, there are corresponding _“various heuristics”_ captured in existing build stuff there?

[18:27:46.0259] <sideshowbarker>
I mean, I just want something I could use as a model for the *“various heuristics”* for the other repos

[18:30:15.0815] <Andreu Botella>
okay, so first I'm trying to get the shortname from bikeshed metadata, and i'm hardcoding some cases where it's wrong (where the shortname includes the level): https://github.com/w3c/csswg-drafts/blob/main/bin/build-index.py#L68-L84

[18:30:46.0359] <Andreu Botella>
there's something similar for html-only specs in `get_html_spec_metadata`

[18:33:21.0847] <Andreu Botella>
and in https://github.com/w3c/csswg-drafts/blob/main/bin/build-index.py#L171-L193 I'm grouping specs by their shortname, and for each shortname, i'm picking the earliest level that isn't marked as complete – or otherwise the highest level

[18:33:44.0056] <Andreu Botella>
and there's the list of exceptions for cases where that's wrong

[18:35:03.0492] <Andreu Botella>
in the august F2F folks mentioned that (at least for csswg-drafts) you can find out which level is the current work based on the github issue labels

[18:35:11.0815] <Andreu Botella>
but it'd be better to maintain that as a json in the repo or something

[20:44:17.0304] <sideshowbarker>
Andreu Botella: got it all, thanks — that’s enough for me to work with

[21:26:31.0826] <sideshowbarker>
Incidentally, I’ve noticed that the toolchain seems to still be set up to add some client-side script to the output HTML to make the w3c.github.io/csswg-drafts URLs redirect to drafts.csswg.org URLs

[21:27:17.0353] <sideshowbarker>
…but it apparently is no longer working, and I’ve tried to figure out why, but I haven’t been able to figure it out

[21:28:15.0371] <sideshowbarker>
But I’m not complaining. We shouldn’t be doing those redirects, so I’m glad it’s turned off … somewhere … or else, broken.

[21:28:38.0514] <sideshowbarker>
If something broke it accidentally, then thank god for that happy accident.

[21:57:22.0131] <sideshowbarker>
TabAtkins: Question: does `--md-Text-Macro="BUILTBYGITHUBCI foo"` have any purpose other than making that redirect happen? (when it was actually working/enabled)

[22:18:06.0880] <sideshowbarker>
ok wait, only now do I notice that y’all got all the FXTF drafts moved to the csswg-drafts repo? And you’re redirecting all the old URLs?  And if so, then it gets me back to my original question of, trying to figure out what actual problem people commenting in https://github.com/w3c/csswg-drafts/issues/12054#issuecomment-3837656822 want solved

[22:47:26.0550] <TabAtkins>
What I want solved is to take Peter's server out of the loop entirely

[22:47:38.0344] <TabAtkins>
Just use GitHub to just and use our domain name

[22:49:54.0371] <sideshowbarker>
Yeah me too

[22:49:59.0753] <sideshowbarker>
so, let’s do that

[22:50:24.0567] <TabAtkins>
* Just use GitHub to host and use our domain name

[22:50:48.0262] <sideshowbarker>
I will huddle with the systems team and get a concrete plan put together for that

[22:51:02.0597] <sideshowbarker>
Chris Lilley wants that too

[22:51:40.0743] <sideshowbarker>
(I mean, as far as I can tell from his GH issue comment — I haven’t talked to him about out directly)

[22:52:21.0718] <sideshowbarker>
but I will not be volunteering to replicate anything from the drafts.csswg.org server except for the actual document publishing

[22:53:19.0603] <sideshowbarker>
whatever else myriad features it might have, I’m not gonna try to be the one to set up some server at w3c to do any of that other stuff

[22:55:15.0820] <sideshowbarker>
What I want is simply that: When some implementor from a browser project is in the middle of implementing some CSS feature, they can reliably access the CSS specs, and not instead have their work blocked by the server being down/broken/wedged

[22:56:42.0547] <sideshowbarker>
personally I would prefer to quit using that domain main, except for to hosting 301 redirects to the GH locations. But I don’t feel strongly about it — if we could just do the CNAME thing, then, fine.

[22:56:50.0433] <sideshowbarker>
* personally I would prefer to quit using that domain name, except for to hosting 301 redirects to the GH locations. But I don’t feel strongly about it — if we could just do the CNAME thing, then, fine.

[22:58:31.0893] <sideshowbarker>
TabAtkins: (or anybody else who might now) Do you have any idea what is being used by that server to do the markdown-to-html conversion? If so, I will try to set up something in the GH repo to do that. But if not, then I guess for now I’ll try to … black-box reverse-engineer it.

[22:59:14.0396] <sideshowbarker>
will just use the python `markdown` thing, I guess?

[23:19:46.0291] <TabAtkins>
> <@sideshowbarker:matrix.org> personally I would prefer to quit using that domain name, except for to hosting 301 redirects to the GH locations. But I don’t feel strongly about it — if we could just do the CNAME thing, then, fine.

Depending on the GitHub url space is not great; I'd prefer it if the w3c offered non-rename redirects to all the WGs so they had urls under w3.org. We don't want to break a lot of links if GitHub ever goes away.

[23:20:23.0998] <TabAtkins>
> <@sideshowbarker:matrix.org> TabAtkins: (or anybody else who might now) Do you have any idea what is being used by that server to do the markdown-to-html conversion? If so, I will try to set up something in the GH repo to do that. But if not, then I guess for now I’ll try to … black-box reverse-engineer it.

Not a clue. But maybe we can just redirect anything with an md to the GitHub rendering 

[23:23:50.0700] <sideshowbarker>
I wouldn’t object to others setting up that stuff. But in the meantime at least, I’m personally pretty happy with GH publishing. It’s what pretty much all other projects I contribute to outside of W3C are using, so … to me it’s reliable and familiar, at least.

And now I say that, I do realize that for WHATWG stuff, we do have a different non-GH thing set up. So yeah, point taken.

[23:34:27.0656] <sideshowbarker>
OK, for the markdown-to-HTML conversion, here’s something quick and clean and simple: https://github.com/w3c/csswg-drafts/pull/13432/files

[23:35:39.0197] <jebez>
You understood not...

To make it simple:

In HTML, why a line break, new line is not interpreted, <br> needed? It's not WYSIWYG...

Related to https://wiki.archlinux.org/title/Help_talk:Editing#%3Cbr%3E_works_not_well. , https://www.mediawiki.org/wiki/Project:Support_desk#Why_%3Cbr%3E_instead_of_just_a_new_line?

[23:40:29.0068] <jebez>
You understood not...

To make it simple:

In HTML, why a line break, new line is not interpreted, <nowiki><br></nowiki> needed? It's not WYSIWYG...

Related to https://wiki.archlinux.org/title/Help_talk:Editing#%3Cbr%3E_works_not_well. , https://www.mediawiki.org/wiki/Project:Support_desk#Why_%3Cbr%3E_instead_of_just_a_new_line?

[23:41:04.0635] <jebez>
* You understood not...

To make it simple:

In HTML, why a line break, new line is not interpreted, \<br>\ needed? It's not WYSIWYG...

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:41:45.0565] <jebez>
* You understood not...

To make it simple:

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:54:25.0550] <jebez>
* You understood not...<br>
<br>
To make it simple:<br>
<br>
In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...<br>
<br>
Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:54:37.0532] <jebez>
* You understood not...


To make it simple:


In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...


Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:55:10.0961] <jebez>
* You understood not...

To make it simple:

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:55:32.0727] <jebez>
* You understood not...



To make it simple:



In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...



Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:55:43.0264] <jebez>
* You understood not...




To make it simple:




In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...




Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:56:01.0084] <jebez>
* You understood not...<br>

To make it simple:<br>

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...<br>

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:56:13.0198] <jebez>
* You understood not...


To make it simple:


In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...


Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:56:27.0303] <jebez>
* You understood not...<br>
To make it simple:<br>
In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG...<br>
Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:57:15.0796] <jebez>
* You understood not...

To make it simple:

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG... E.g. need \<br> here.

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:57:33.0250] <jebez>
* You understood not...<br>

To make it simple:<br>

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG... E.g. need \<br> here.<br>

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[23:59:16.0865] <jebez>
* You understood not...<br>

To make it simple:<br>

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG... E.g. need \<br> here.<br>
https://www.w3schools.com/tags/tag_br.asp<br>
Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[00:01:02.0518] <jebez>
* You understood not...<br>

To make it simple:<br>

In HTML, why a line break, new line is not interpreted, \<br> needed? It's not WYSIWYG... E.g. needs \<br> here.<br>

https://www.w3schools.com/tags/tag\_br.asp<br>

Related to https://wiki.archlinux.org/title/Help\_talk:Editing#%3Cbr%3E\_works\_not\_well. , https://www.mediawiki.org/wiki/Project:Support\_desk#Why\_%3Cbr%3E\_instead\_of\_just\_a\_new\_line?

[00:13:52.0931] <sideshowbarker>
next bit: https://github.com/w3c/css-houdini-drafts/pull/1165/files

[00:31:59.0331] <sideshowbarker>
OK, and now https://github.com/w3c/csswg-drafts/pull/13433/files will give us a proper index page at w3c.github.io/csswg-drafts — rather than a redirect to the legacy server

[00:32:12.0051] <sideshowbarker>
(and with that, I take a break to cook dinner)

[00:53:45.0142] <sideshowbarker>
Andreu Botella: (or anybody else who might know) What exactly is the “issues list” that needs to be built?

Is that maybe https://drafts.csswg.org/issues.html? Or something else entirely?

[00:55:23.0547] <sideshowbarker>
I guess for now I’m gonna just assume that’s what it is, and try to figure out how to remake that

[00:55:52.0677] <sideshowbarker>
oh wait is just the `bikeshed issues-list` thing, I guess?

[07:51:11.0278] <zcorpan>
Noam Rosenthal: foolip : should pseudo-attribute parsing work differently in HTML docs vs XML docs? Right now xml-stylesheet uses XML-like parsing for the pseudo-attributes, also in HTML documents.

[07:51:58.0615] <zcorpan>
But we can switch to HTML-like syntax for xml-stylesheet in HTML docs, because why not

[07:52:02.0597] <foolip>
zcorpan: I think that it should, yeah. It would be fairly inconsistent with the rest of HTML if we require double quotes

[07:54:14.0116] <foolip>
zcorpan: If we define this is a little parser of `data`, I think we'd just use a different parser depending on the node document. For XML it would be the https://www.w3.org/TR/xml-stylesheet/#NT-PseudoAtts production, and for HTML, not totally sure yet, but maybe defined in terms of "<attrs " + data + ">", because that's actually how the XML thing is implemented.

[07:59:35.0592] <zcorpan>
foolip: that seems somewhat bogus since the data can contain `>` (also in HTML with DOM API)

[08:00:11.0177] <zcorpan>
Not sure if something bad happens because of it

[08:04:32.0345] <foolip>
zcorpan: yes, but there's no parser we could reuse that would skip past a ">". I think what we could do is to truncate `data` at the first ">" if it's there, before parsing.

[08:05:50.0430] <zcorpan>
foolip: > can be in a selector and works today https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14487

[08:09:32.0587] <Noam Rosenthal>
yea there's no way around escaping it inside a PI, due to compat with browsers that treat it as a bogus comment

[08:10:21.0632] <Noam Rosenthal>
This can happen today, if you adopt an XML PI and serialize it. if you re-parse it you'd get a bogus comment and some trailing characters

[08:12:43.0127] <Noam Rosenthal>
e.g. if you adopt `<?echo "x>1" ?>`  after a couple of steps of parsing and re-serialization it would be `<!-- echo "x -->1" ?>`

[08:13:36.0282] <zcorpan>
Noam Rosenthal: Right, or if you use createProcessingInstruction. The question is if it's good enough to use the fragment HTML parser or so and concat the data like how browsers implement it now for XML xml-stylesheet (which isn't quite per spec), or if the possibility of `>` in the data makes the approach too bogus?

[08:14:17.0330] <Noam Rosenthal>
I think it's OK to fragment-parse it, and only accept as attributes if it produces exactly one element

[08:15:07.0761] <Noam Rosenthal>
so `<attribs ${data}></attribs>` would produce more than one (empty) element if $(data} has a > anywhere

[08:16:20.0683] <zcorpan>
`<?xml-stylesheet ></?>`

[08:16:35.0378] <Noam Rosenthal>
(or we can search for > in advance, it would produce the same result)

[08:18:37.0843] <Noam Rosenthal>
Yea that produces a bogus comment in addition to the element

[08:19:18.0873] <zcorpan>
Sorry I meant `></` as data

[08:20:06.0742] <zcorpan>
Becomes `<attribs ></></attribs>` which parses fine and there are no child nodes in `attribs`

[08:20:18.0539] <zcorpan>
But I can live with weird cases being weird

[08:21:32.0312] <Noam Rosenthal>
yea it would have an empty attrib with name "<" 

[08:23:22.0647] <Noam Rosenthal>
also you could only get that by adopting an XML node and then setting its data with JS.

[08:24:49.0452] <zcorpan>
There is no < attribute in my example though?

[08:27:44.0116] <Noam Rosenthal>
Well you're taking an XML PI and re-parsing its data with HTML. 
Anyway, I'm also OK with saying that ">" means no attributes and everything else is HTML-parsed. It's all edge cases

[08:30:14.0733] <zcorpan>
Noam Rosenthal: right, agreed. Maybe don't need to scan for >. I can't envision real problems with it, if you parse into an inert DocumentFragment

[08:31:25.0424] <zcorpan>
I guess we should standardize the approach browsers use for XML xml-stylesheet, willfully violating the xml-stylesheet spec

[08:32:38.0680] <Noam Rosenthal>
It's definitely simpler than trying to be specific to "pseudo-attributes" and then trying to make it apply to HTML as well

[08:35:53.0383] <zcorpan>
Noam Rosenthal: I think the "clean" approach is to modify the HTML parser so that it can be started in before attribute state, and make it stop parsing when it tries to switch to a non-attribute-related state. But that doesn't exist today and is probably too much heavy lifting for pseudo-attributes

[08:36:39.0611] <zcorpan>
* Noam Rosenthal: I think the "clean" approach is to modify the HTML parser so that it can be started in before attribute name state, and make it stop parsing when it tries to switch to a non-attribute-related state. But that doesn't exist today and is probably too much heavy lifting for pseudo-attributes

[08:37:10.0408] <Noam Rosenthal>
Agreed

[12:50:53.0052] <TabAtkins>
https://github.com/w3c/css-houdini-drafts/actions/runs/21647222016/job/62402240607 btw, an error in the script

[13:00:34.0307] <TabAtkins>
ah, in both of them

[13:36:42.0739] <sideshowbarker>
Oh. I'll take a look

[13:53:14.0992] <sideshowbarker>
TabAtkins: https://github.com/w3c/css-houdini-drafts/pull/1166

[14:05:32.0530] <TabAtkins>
error at a later stage now, during deploy it looks like https://github.com/w3c/css-houdini-drafts/actions/runs/21649294456/job/62409406208

[14:08:58.0089] <sideshowbarker>
dang looking now

[14:10:00.0344] <sideshowbarker>
ah huhuh, just forget to actually flip on the GH Pages stuff in the repo settings. Will do that right now

[14:12:12.0998] <sideshowbarker>
https://github.com/w3c/css-houdini-drafts/actions/runs/21649294456/job/62411271506 re-running right now

[14:13:10.0649] <sideshowbarker>
* https://github.com/w3c/css-houdini-drafts/actions/runs/21649294456/job/62411271506 re-running right now (update: ✅)

[14:15:10.0984] <sideshowbarker>
TabAtkins: *voilà* https://w3c.github.io/css-houdini-drafts/

[14:15:39.0911] <TabAtkins>
now same fix on csswg-drafts ^_^

[14:19:17.0716] <sideshowbarker>
the `shopt -s nullglob` fix for the `./**/Overview.html` thing, you mean? Or something else I missed?

[14:21:03.0757] <sideshowbarker>
TabAtkins:  GH Pages is already on at https://github.com/w3c/csswg-drafts/settings/pages at least. And we got the purty https://w3c.github.io/csswg-drafts/ index page

[14:21:49.0376] <TabAtkins>
oh indeed, sorry

[14:22:20.0147] <TabAtkins>
I guess I accidentally was looking at the Houdini page when I said csswg-drafts was failing in the same way. (tho it *will* fail the same way if it ever hits the same case, I guess)

[14:27:43.0838] <sideshowbarker>
haha yeah I was doing the same thing earlier — I mean, looking at the Houdini repo settings when I thought I was looking at the csswg settings

[14:29:42.0205] <Andreu Botella>
so how are things going?

[14:33:00.0855] <sideshowbarker>
Andreu Botella: most-visible progress is https://w3c.github.io/csswg-drafts/. Take a look there and try out the search and push some buttons. It’s fun 😄 But also practical. With 164 specs, otherwise making everybody scroll or rely on browser find-in-page is not the most beautiful UX…

[14:34:32.0524] <sideshowbarker>
oh I see https://github.com/w3c/csswg-drafts/pull/13432 hasn’t been merged yet. Got a merge conflict to resolve there. (And a comment from Florian to respond to)

[15:11:37.0200] <sideshowbarker>
TabAtkins: merge conflict fixed at https://github.com/w3c/csswg-drafts/pull/13432 (and responded to Florian’s comment: I am confident that Python-Markdown does everything y’all need, and there’s point in using any other thing instead).

[15:14:11.0641] <sideshowbarker>
Andreu Botella: I think the changes I made yesterday resolved all the immediate/acute problems that had been brought up in recent comments in https://github.com/w3c/csswg-drafts/issues/12054. There’s still some room to make refinements along the lines you alluded to in some of your own comments. But it seems like this is good enough for now.

[15:15:40.0302] <sideshowbarker>
I guess the one biggish pending thing is the migration of the Houdini stuff. But it doesn’t seem like there’s any problems there — it’s just a matter of that work actually needing to get done.

[15:26:25.0211] <sideshowbarker>
I guess that’s one specific remaining refinement that could be worked on. That, and figuring out if there’s some way to *“which spec is the current work”* algorithm slightly smarter. But IMHO the `CURRENT_WORK_EXCEPTIONS` thing is just fine. It’s only 8 cases. So it’s not a big deal to maintain.

[15:26:52.0162] <sideshowbarker>
* 👆 I guess that’s one specific remaining refinement that could be worked on. That, and figuring out if there’s some way to _“which spec is the current work”_ algorithm slightly smarter. But IMHO the `CURRENT_WORK_EXCEPTIONS` thing is just fine. It’s only 8 cases. So it’s not a big deal to maintain.


2026-02-04
[16:00:16.0210] <Andreu Botella>
sure, as long as when publishing a new spec someone makes sure that it's not wrongly marked as current work

[20:58:48.0741] <nektro>
got https://github.com/nektro/zig-whatwg-url to pass 100% of `urltestdata.json` and `IdnaTestV2.json` (w/ base included this time)

[03:45:14.0859] <foolip>
What's up with https://www.w3.org/TR/xml/#NT-NameStartChar claiming that names in XML can start with ":"?

[03:48:31.0668] <foolip>
https://www.w3.org/TR/xml-names/#orphans seems to touch on this, but is non-normative...

[03:56:02.0507] <sideshowbarker>
Namespaces

[03:56:15.0314] <sideshowbarker>
it’s superseded by Namespaces, right?

[03:56:45.0038] <sideshowbarker>
so I guess in a non-Namespace aware XML implementation, it would be allowed

[03:57:02.0264] <sideshowbarker>
but there are no such implementations, I guess

[03:57:24.0310] <sideshowbarker>
there would be no point in any non-Namespace-aware XML implementation

[03:57:25.0444] <foolip>
Hmm, seems like https://www.w3.org/TR/xml-names/ doesn't monkeypatch this in the way I'd expect and not normatively, but fine, it's namespaces.

[03:57:51.0823] <foolip>
As long as ":" is the only special case it's all good.

[03:58:00.0417] <foolip>
I thought I might be reading the wrong thing entirely.

[03:58:18.0125] <sideshowbarker>
yeah, have fun trying to implement from those specs to begin with, I guess

[03:58:39.0354] <sideshowbarker>
I mean, they are not rigorous specs, by our current standards for such

[03:59:22.0482] <sideshowbarker>
I guess the productions are rigorous enough

[04:02:48.0049] <Noam Rosenthal>
`:` aside, this seems to be relatively close to `ID_Start` and `ID_Continue` in unicode (https://www.unicode.org/reports/tr31/#D1)
(*TIL)

We can probably use those for valid PI targets in HTML as well, which would exclude current uses of bogus comment such as `lit$$`

[05:23:27.0025] <sideshowbarker>
hsivonen: friendly bump on https://github.com/validator/htmlparser/pull/113

[05:29:16.0813] <hsivonen>
I happened to be already reviewing it, but I'm a bit confused. Should I be looking at some spec PR that's not landed, yet? 

[05:33:22.0378] <eemeli>
XML's `NameStartChar` and `NameChar` have not been updated to match Unicode changes, so e.g. the invisible Arabic Letter Mark U+061C counts as a valid first (and potentially only) character of an XML name.

[05:40:01.0775] <hsivonen>
For sure XML tooling compat, one needs to stay within the XML rules as they were in 1998. I'm skeptical of mixing UAX 31 into HTML conformance requirements. Rules like https://html.spec.whatwg.org/#custom-data-attribute have worked well enough so far. I suppose the validator could complain about going outside UAX 31, but UAX 31 checks would be bad for browser DOM perf.

[05:40:33.0067] <Noam Rosenthal>
Agreed, I think we can remain with a simple ascii subset of this.

[05:44:48.0388] <sideshowbarker>
No, that is intended to functionally match the spec requirements as I understand them. But if it’s too much of deviation that it’s not mapping back to the spec clearly enough, then I guess I need to revisit it. Or if you’re saying that as currently written, it’s not even functionally matching the spec requirements, then I guess I definitely need to go back and try again.

[05:46:24.0992] <hsivonen>
sideshowbarker: At least it _looks_ different from the spec. I haven't worked out if it's actually functionally equivalent, but I'll try to think about that more now that I know that I'm not supposed to be looking at an in-flight spec PR.

[05:49:54.0447] <sideshowbarker>
Well also go back in right now and make a re-try at seeing if I can make it strictly follow the spec algorithm. To be honest, in the first crack I took at it, I was focused just making it work for what I needed in the context of the HTML checker. Wasn’t remembering that it’d need to work in, you know, the more-important context of being in browser engine.

[05:50:58.0750] <sideshowbarker>
For me it’s always a bit of a challenge working and another level of remove, the way that’s necessary for working on the parser source in Java

[05:51:04.0461] <sideshowbarker>
* For me it’s always a bit of a challenge working at another level of remove, the way that’s necessary for working on the parser source in Java

[05:53:54.0462] <sideshowbarker>
hsivonen: well, and to put it in other terms, I was also writing against getting it to pass the tests. And it does pass the tests

[05:56:06.0823] <hsivonen>
sideshowbarker: Does the validator need to know in the steaming SAX mode whether a target that a browser would clone an "option" into exists earlier in the doc?

[06:08:50.0308] <sideshowbarker>
No. Because it’s using SAXStreamer, right? We don’t use SAXTreeBuilder for the checker. It builds no tree at all. So, never clones any content itself. Never fires any events for the cloning. It only ever knows about the source elements, and not at all about the browser-would-clone-this content.

[06:10:08.0660] <hsivonen>
sideshowbarker: So there's no validator hard requirement to track `selectedcontent` in the tree builder?

[06:18:42.0825] <sideshowbarker>
Right. No such requirement. So the selectedContentPointer etc. stuff gets called — but it’s all a no-op. But it’s there because of the inheritance from TreeBuilder. I mean, the only alternative would be to just have it in the code of the actual-tree-building-implementation subclasses where it’s not a no-op.

[06:19:20.0174] <sideshowbarker>
I guess I could try to see if I could make it be that way, if you that’d be better.

[06:19:43.0345] <foolip>
zcorpan hsivonen I'm curious if you have revised thoughts on > vs ?> for both conformance and serialization? https://github.com/whatwg/html/pull/12118#issuecomment-3844500491

[06:20:34.0087] <foolip>
At first I was convinced about the argument that a stray > could be flagged if we require ?>, but then I couldn't write an example that made sense...

[06:21:59.0411] <zcorpan>
foolip: `<?xml-stylesheet href="data:text/css,a>b{}"?>`

[06:26:27.0935] <foolip>
That's still a syntax error because the attribute value doesn't have a closing ", right?

[06:27:00.0459] <hsivonen>
A syntax error on another layer, right?

[06:29:37.0873] <foolip>
Yes, true with the plan I suggested. If we want it to be an error in the first layer, we could tokenize pseudo-attributes in the main parser.

[06:31:02.0514] <foolip>
Do we have any way to signal parse errors that would happen in the data setter? That's a question regardless of conformance, since you can get > in data.

[06:34:03.0075] <hsivonen>
We can have > without a preceding question mark be a HTML-layer conformance error even if pseudo attributes are parsed on the DOM layer. As for the DOM setters, I believe we already have plenty of ways to cause problematic serializations using DOM setters.

[06:34:46.0856] <zcorpan>
Right, e.g. --> in comment data is allowed

[06:40:55.0896] <foolip>
If I did tokenize pseudo-attributes in the main parser and did the parse errors in all the right places, would that tip the balance in favor of making just > the recommended syntax? My concern in a nutshell is that with ?> it looks like > in data should work but still it doesn't.

[06:44:21.0387] <zcorpan>
foolip: What would happen when dynamically changing .data? Still need DOM-level parsing also?

[06:44:47.0300] <hsivonen>
We should not put the pseudo-attribute parsing in the HTML parser.

[06:45:30.0423] <hsivonen>
foolip: Would you change how Blink and WebKti serialize?

[06:46:23.0332] <hsivonen>
sideshowbarker: I posted non-exhaustive review comments. I suspect that removing the tree builder tracking of `selectedcontent` will result in coming closer to the spec generally.

[06:46:54.0340] <sideshowbarker>
Ok, I’ll take a look there

[06:48:21.0743] <hsivonen>
(I need to step away from the chat now, unfortunately.)

[07:30:14.0262] <foolip>
I'd be happy to change it in Blink if the decision is to make <?foo> the more canonical HTML syntax, with whatever parsing and conformance changes required, yes.

[07:31:11.0957] <foolip>
I have to admit this is probably the right stance, because there's no way we can put the parsing in the XML parser for for PIs.

[07:32:10.0922] <zcorpan>
I'm ok with optional ? if the serializer omits it

[07:41:09.0103] <Noam Rosenthal>
I think this is equivalent to the stray slash in `<img />`, it should be tolerated but not be canonical

[08:29:28.0084] <foolip>
zcorpan: do you think we could define conformance rules for PI data to say that they have to follow certain rules, so that this becomes more like validating an attribute value than a parse error produced by the tokenizer?

[10:58:27.0564] <sideshowbarker>
What would be an example of such a rule?

[11:41:01.0220] <zcorpan>
foolip: sure, can say that the data must follow the syntax for pseudo attributes

[11:45:59.0652] <zcorpan>
foolip: is the idea that we ałlow authors to use any target names, and we just check for compat before minting new standardized PIs?

[12:51:38.0071] <Noam Rosenthal>
Yea pretty much, though we can maybe make some guarantee that we won't use `-` in minted ones, so that userland can feel confident they can use them (kind of like custom elements)

[13:35:20.0342] <foolip>
zcorpan: I think the choices are requiring pseudo-attribute syntax in data just for known PIs, or we just say that all PIs, including future PIs and custom PIs (with hyphens?) will use pseudo-attributes. I think the latter is probably fine in practice, because you can just put whatever in an attribute value if you want that.

[13:36:06.0401] <foolip>
I think we'd do the attribute parsing for any PI, so it would make the most sense to also have the conformance requirement for any PI.


2026-02-05
[00:28:36.0951] <zcorpan>
foolip: I think that makes sense

[00:50:15.0617] <zcorpan>
I'll run a new query for all of httparchive, with pi targets [a-zA-Z][a-zA-Z0-9-]* , excluding "xml"

[00:55:25.0811] <foolip>
zcorpan: if we define pseudo-attribute conformance properly (and it's implemented by validator.nu) do you think that changes the calculus for > vs ?> in serialization and conformance requirements?

[01:00:17.0342] <zcorpan>
foolip: I'm ok with > if the serializer omits ?. I suppose the lack of HTML parser-level parse error means some people will miss errors, but it's probably a small set of people anyway (who use an HTML parser in their pipeline but not validator.nu)

[01:00:21.0446] <foolip>
I've been looking at how to define conformance. I think it would be something analagous to "The value attribute, if specified and not empty, must have a value that is a valid time string."

[01:01:40.0506] <foolip>
zcorpan: could we report parse errors without actually parsing?

[01:03:04.0276] <zcorpan>
foolip: would need to step through new pseudo-attribute states in the tokenizer to get it right. It's overkill for just reporting errors from the parser

[01:37:24.0350] <zcorpan>
I proposed a change to the CSS of generated spec diffs. Which approach is more usable for screen reader users? See https://github.com/w3c/htmldiff-ui/issues/23

[01:54:00.0965] <Julian Descottes>
Hi, I opened a PR for fetch to integrate with WebDriver BiDi at https://github.com/whatwg/fetch/pull/1860 . Anything I should do to make it move forward?
(it's ok if it's just the normal process - things take time - just want to check if it wasn't missed or if I didn't forget to do something to make it actionable)

[03:15:56.0176] <zcorpan>
foolip: here are just the pi_target names and counts https://docs.google.com/spreadsheets/d/1mFzwvoixsIelVXgq3srm7aV2pjW8zcWpsH1wyp6Xfmo/edit?usp=sharing

[03:31:56.0308] <zcorpan>
Added a column for what chatgpt thinks the PI target is for

[04:29:25.0279] <Noam Rosenthal>
I researched a few of these, I can add notes with edit/suggest access

[05:07:33.0041] <zcorpan>
Noam Rosenthal: Done.

[05:09:40.0081] <zcorpan>
Noam Rosenthal: After checking a few URLs for xml-stylesheet, it seems the data includes JS resources even though the query tried to only include resources with type "html". e.g. https://instructor.go-red.co.uk/ has the matching PI in https://instructor.go-red.co.uk/portal/instructor/Login.aspx?_TSM_CombinedScripts_=True&v=ZaMfZ6yYhPPHZ1NeEf8j6-t902-6pHpn2MehV0eep-I1&_TSM_Bundles_=&cdn=False

[05:11:04.0833] <Noam Rosenthal>
This seems to be in a method `initializeSVG` so it probably creates a standalone SVG-XML doc on the fly

[05:13:09.0424] <zcorpan>
Noam Rosenthal: Right. Just something to keep in mind that not all matches are actually in HTML

[05:13:55.0045] <Noam Rosenthal>
Yea, `lit$$` was in the lit js files... coincidentally that also blocked the chromium commit because chrome devtools uses lit :)

[05:14:03.0144] <Noam Rosenthal>
* Yea, `<?lit$$` was in the lit js files... coincidentally that also blocked the chromium commit because chrome devtools uses lit :)

[05:35:19.0619] <foolip>
So there were 165k results, how many pages in HA in total?

[05:35:54.0619] <foolip>
Just wondering if it would be too noise to make more is these non-conforming because they don't use attribute syntax in the data part

[05:52:19.0631] <zcorpan>
foolip: 
```
SELECT COUNT(DISTINCT page) FROM `httparchive.crawl.pages` WHERE date = "2026-01-01"
AND client = "desktop"
```
20727999

[05:55:06.0472] <zcorpan>
foolip: they are already non-conforming, should be fine

[05:58:20.0248] <foolip>
Cool, so about 0.8%

[05:58:41.0746] <foolip>
We can probably do what we think is the best long term then when it comes to conformance 

[09:04:21.0498] <zcorpan>
foolip: 7,161 pages when excluding <?php. And some of those are still PHP

[10:03:37.0753] <zcorpan>
foolip: also I see 55,733 pages with PIs. The 165k rows is the number of PIs, not pages

[11:28:06.0640] <foolip>
Great, so at least we won't be adding red squiggles to lots of existing content

[11:28:36.0487] <foolip>
As you say, it was already non-conforming, so I guess my concern didn't make sense to begin with

[13:34:34.0150] <jmdyck>
https://html.spec.whatwg.org/#concept-optgroup-label has the phrase "descendants of descendants of the `legend`", which seems odd. Note that it skips children of the `legend` (because, while they're descendants of the legend, they aren't descendants of descendants of the legend), but it seems like you wouldn't want to skip them.

[13:37:26.0767] <jmdyck>
* https://html.spec.whatwg.org/#concept-optgroup-label has the phrase "descendants of descendants of the `legend`", which seems odd. Note that it omits children of the `legend` (because, while they're descendants of the legend, they aren't descendants of descendants of the legend), but it seems like you wouldn't want to omit them. (omit them from the exclusion, that is)

[13:39:54.0016] <jmdyck>
* https://html.spec.whatwg.org/#concept-optgroup-label has the phrase "excluding any that are descendants of descendants of the `legend`", and that "desc. of desc." seems odd. Note that it fails to exclude children of the `legend` (because, while they're descendants of the legend, they aren't descendants of descendants of the legend), but it seems like you do want to exclude them.


2026-02-06
[20:12:49.0029] <Kaiido>
jmdyck: I believe it is correct albeit not clear, the Text nodes are being excluded, they are the descendants of <script> or <svg:script> that are descendants of the <legend>. So they're indeed "descendants of descendants".

[00:06:39.0951] <sideshowbarker>
Phil Pizlo finally putting his Fil-C work to good use: https://yoshell.ai 😀

[03:22:06.0843] <foolip>
zcorpan: I'm trying to understand how `<script>console.log("</script>")</script>` manages to "back up" when it sees the ">" inside the console.log string so that the script element text is just 'console.log("'. Do you know what tokenizer state this is? It looks to me like "Script data double escape start state" or "Script data double escape end state", but it looks like 'console.log("</script' has already been emitted as character tokens at that point. How does the tokenizer "take back" what's already been emitted?

[03:32:07.0219] <zcorpan>
foolip: it doesn't back up it just closes the script element there. 
https://html.spec.whatwg.org/#script-data-state
https://html.spec.whatwg.org/#script-data-less-than-sign-state
https://html.spec.whatwg.org/#script-data-end-tag-open-state
https://html.spec.whatwg.org/#script-data-end-tag-name-state


[03:33:29.0335] <zcorpan>
foolip: you need <script><!-- to enter https://html.spec.whatwg.org/#script-data-escaped-state

[03:35:04.0194] <zcorpan>
foolip: and <script><!--<script> to enter https://html.spec.whatwg.org/#script-data-escaped-state (which causes a single </script> to not close the element)

[03:36:42.0224] <zcorpan>
* foolip: and \<script>\<!--\<script> to enter https://html.spec.whatwg.org/#script-data-double-escaped-state (which causes a single \</script> to not close the element)

[03:38:13.0389] <zcorpan>
https://html.spec.whatwg.org/#script-data-double-escape-end-state handling > is where </script> is sometimes "ignored"

[03:38:19.0887] <foolip>
Thanks, the `<script>console.log("</script>")</script>` case is clear now. It does use the temp buffer and if that > inside the string isn't there, it emits a character token for each char in the temp buffer.

[03:39:03.0677] <foolip>
That explains how the parallel lowercase + original case is handled in that case.

[03:40:06.0628] <foolip>
The context is I did https://whatpr.org/html/12118/parsing.html#processing-instruction-target-state yesterday and although it's readable, I think it's an unusual use of the temp buffer that maybe I should undo.

[03:40:30.0167] <snek>
is there a way to have a "back" button/link without js?

[03:40:43.0550] <foolip>
The motivation was to avoid saying "discard the current token" which the tokenizer never does elsewhere (including in Blink's implementation).

[03:41:00.0587] <snek>
i was hoping there would be some obsecure href target or button command or something, but i couldn't find anything

[03:41:33.0822] <foolip>
The problem is there might be unbounded buffering before we know whether we're going to create a PI or a bogus comment, and that we need the data lowercase for the first but the original for the latter...

[03:44:20.0798] <zcorpan>
Hmm right. Maybe the target should preserve case?

[03:44:44.0308] <foolip>
Huh, I didn't even think about that.

[03:45:36.0509] <foolip>
What I did consider was letting tree construction lowercase the target.

[03:46:15.0385] <foolip>
But preserving case is very un-HTML-y isn't it?

[03:48:39.0614] <zcorpan>
foolip: though https://html.spec.whatwg.org/#script-data-escaped-end-tag-name-state creates an end tag with arbitrary length and then throws it away

[03:49:51.0222] <zcorpan>
Except implementations could have a state to check what's up after temporary buffer > "script".length

[03:50:08.0752] <foolip>
Hmm, but it never says "discard the token" or something like, it just emit another token.

[03:50:45.0167] <zcorpan>
foolip: anything else

[03:51:09.0302] <zcorpan>
or > when temporary buffer != "script"

[03:52:18.0993] <foolip>
Right, but seemingly not explicitly saying that the current tag token is no longer current, right?

[03:52:45.0244] <foolip>
Maybe something else is guaranteed to say "create a bla token" before anything can get confused.

[03:53:29.0100] <zcorpan>
Right the end tag token is created but then nothing happens with it

[03:54:23.0660] <foolip>
I see that in Blink, for this case, there's a special `buffered_end_tag_name_`, so the token is only created once we know what it's going to be.

[03:57:45.0726] <zcorpan>
How much is ok to buffer? For compat with <?lit$ it's just 4 chars

[03:58:43.0553] <foolip>
I checked and it looks like Blink's buffer can grow unbounded. (I expected to find a hardcoded max size that is impossible to exceed because of how it's used, but no.)

[03:58:59.0657] <foolip>
Do you think there are important rules to follow here? Possible principles I've inferred include (1) only put things in the temp buffer to compare them, not to read them back (2) don't create a token unless it will be emitted (3) normalize casing in tokenization, not tree construction and (4) no unbounded buffering.

[03:59:41.0702] <foolip>
I don't think all of these can be hard rules at the same time.

[03:59:54.0119] <zcorpan>
The temporary buffer is sometimes emitted as characters

[04:01:09.0900] <foolip>
Yes, you're right, so taking it and sticking it into comment data feels OK, and what I did.

[04:01:37.0624] <foolip>
Just that the wording is slightly different because for character tokens they are emitted one by one.

[04:02:40.0125] <foolip>
We don't actually need unbounded buffering and lookahead, at most  `"xml-stylesheet".length + 1` is strictly required.

[04:03:17.0138] <foolip>
No wait, that's wrong. After the recent change there's also `<?superduperlong$not-a-pi?>`.

[04:04:52.0926] <zcorpan>
Right. But we could place some limit on how many characters to check

[04:05:19.0400] <foolip>
And after that if you see a $ we make it part of the target instead?

[04:05:25.0060] <zcorpan>
Yeah

[04:05:47.0393] <foolip>
The test cases are going to be fun at least :)

[04:08:21.0402] <foolip>
zcorpan: lit$ doesn't show up in httparchive, any idea how we can find out if there are more cases like it?

[04:08:36.0861] <foolip>
use counters?

[04:09:09.0898] <zcorpan>
foolip: My query didn't include PIs with $

[04:09:42.0368] <foolip>
Oh right, these are just the ones that would be valid PIs per our new stricter target names.

[04:10:12.0126] <zcorpan>
Yes. Or https://docs.google.com/spreadsheets/d/1o04eP_BwH1u7X8CyyLUvxOsntZNmfrDalfhU7ldVqlU/edit?usp=sharing did (just required the first char to be a-z), but was only 1% of the data

[04:10:59.0436] <foolip>
Noam Rosenthal: you also have a spreadsheet right?

[04:12:21.0164] <Noam Rosenthal>
> <@foolip:matrix.org> Noam Rosenthal: you also have a spreadsheet right?

This one looks more comprehensive but similar 

[04:16:25.0753] <zcorpan>
foolip: checking https://github.com/search?q=%2F%3C%5C%3F%5Ba-zA-Z%5D%2F+language%3Ahtml+NOT+%22%3C%3Fphp%22+NOT+%22%3C%3Fxml%22&type=code it looks like sometimes end tags are typoed as e.g. `<?a>`

[04:19:04.0214] <foolip>
So the concrete options I see are (1) preserve case in PI target (2) buffer both original + lowercased data until we know if it will be a PI or comment (3) buffer only original and then lowercase it when creating the PI token  (4) initially create a comment token and replace it with a PI token when we have a valid target.

[04:19:52.0012] <foolip>
I think 2-4 are equivalent, mostly a matter of what fits best with existing patterns.

[04:21:24.0195] <zcorpan>
hsivonen: do you have an opinion? ^

[04:21:39.0787] <foolip>
Oh, and (5) fixed length buffering or lookahead, so that the rules change after N characters are consumed as target.

[04:56:42.0503] <hsivonen>
Is the only downside of preserving case inconsistency with the rest of HTML?

[05:04:44.0855] <zcorpan>
hsivonen: Yeah I think so. Though <![CDATA[ is case-sensitive

[05:13:08.0979] <hsivonen>
Let's preserve the case. Makes everything simpler.

[05:17:32.0188] <Noam Rosenthal>
Does this mean <?marker> needs to be case-sensitive? or I guess we can do a case-insensitive target lookup when selecting them  foolip 

[05:25:03.0237] <zcorpan>
Noam Rosenthal: Case-sensitive lookup imo

[05:30:11.0876] <Noam Rosenthal>
> <@zcorpan:mozilla.org> Noam Rosenthal: Case-sensitive lookup imo

Works for me. Ok if the underlying target lookup is case sensitive 👍

[06:31:08.0081] <foolip>
Yeah, consistency is the reason.

[06:32:25.0916] <foolip>
If we make the target preserve case, how about attribute names?

[13:20:38.0469] <jmdyck>
Ah, okay, so "that are themselves script or SVG script elements" has to modify the second "descendants". Yeah, that makes sense.

[15:31:06.0222] <cwilso>
Hey gang - I just did the minutes-and-agenda-prep shuffle to prepare for next week's WHATNOT meeting (https://github.com/whatwg/html/issues/12141, AMER+EMEA timeslot).  Unfortunately I will be on a plane during the meeting, so I will need someone else to step in to chair.  Any volunteers?


2026-02-07
[10:38:49.0590] <Noam Rosenthal>
> <@cwilso:matrix.org> Hey gang - I just did the minutes-and-agenda-prep shuffle to prepare for next week's WHATNOT meeting (https://github.com/whatwg/html/issues/12141, AMER+EMEA timeslot).  Unfortunately I will be on a plane during the meeting, so I will need someone else to step in to chair.  Any volunteers?

I got it 


2026-02-09
[01:23:41.0778] <cwilso>
Thanks Noam!  I can do the minutes/summary stuff afterward

[04:49:48.0701] <Jake Archibald>
jarhar: I see that [show-popover](https://html.spec.whatwg.org/multipage/popover.html#show-popover) is called to show the `<select>` popover. This includes firing a `beforetoggle` event, but I don't see that happening in Chrome. Which is wrong, the spec or the implementation? (also, the spec doesn't say which element to fire the event on)

[05:02:52.0449] <Jake Archibald>
* jarhar: I see that [show-popover](https://html.spec.whatwg.org/multipage/popover.html#show-popover) is called to show the `<select>` popover. This includes firing a `beforetoggle` event, but I don't see that happening in Chrome. Which is wrong, the spec or the implementation? (also, the spec doesn't say which element to fire the event on. edit: oh yes it does I just didn't see it)

[05:03:30.0188] <Jake Archibald>
* jarhar: I see that [show-popover](https://html.spec.whatwg.org/multipage/popover.html#show-popover) is called to show the `<select>` popover. This includes firing a `beforetoggle` event, but I don't see that happening in Chrome. Which is wrong, the spec or the implementation? (<del>also, the spec doesn't say which element to fire the event on</del>. edit: oh yes it does I just didn't see it)

[05:03:51.0817] <Luke Warlow>
> <@jakea:matrix.org> jarhar: I see that [show-popover](https://html.spec.whatwg.org/multipage/popover.html#show-popover) is called to show the `<select>` popover. This includes firing a `beforetoggle` event, but I don't see that happening in Chrome. Which is wrong, the spec or the implementation? (also, the spec doesn't say which element to fire the event on)

It gets fired on the picker element which is inside the selects UA shadow root. So isn't accessible to JS.

https://github.com/whatwg/html/issues/11564 - this proposes exposing it to the select itself.

Good point that it's missing a target currently.

[05:08:48.0922] <Jake Archibald>
Luke Warlow: Cheers! I ran into this when looking for a way to prevent the picker going into top-layer https://github.com/w3c/csswg-drafts/issues/13467

[05:12:16.0644] <Luke Warlow>
Would listbox select cover this use case? e.g. `<select size="3">`

[05:13:20.0528] <Jake Archibald>
Luke Warlow: yeah, I guess. I was trying to come up with a pure CSS way.

[05:14:41.0148] <Luke Warlow>
We played around with it a while back and there's some ways to get something like that but they all had issues, and I think were problematic for accessibility reasons too. Fwiw customisable listbox select (including multiple) will be in Chrome 145 I think.

[05:15:03.0878] <Jake Archibald>
nice, yeah, that's fair

[06:28:27.0665] <Noam Rosenthal>
No worries. If you are still around, can you Agenda- the things that were already discussed please?


2026-02-10
[05:58:40.0178] <Noam Rosenthal>
Done based on the minutes