2024-04-01
[18:39:33.0718] <Adam Rice>
Sorry, yes, Chrome's behaviour for non-special URLs is currently incorrect, but we're working on it. You can star this bug https://issues.chromium.org/issues/40063064 to be notified when there are updates.

[02:04:42.0027] <evilpie>
https://github.com/whatwg/url/issues/815

[02:39:38.0636] <sideshowbarker>
When trying to build the HTML spec in my macOS (Sonoma 14.4.1) environment, I was getting the following error:
>   = note: ld: library 'System' not found
>          clang: error: linker command failed with exit code 1 (use -v to see invocation)

To fix it I needed to do this:

> export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"

I wonder if we should document this


2024-04-02
[02:39:41.0523] <zcorpan>
Looking for mathml content in httparchive but it's almost entirely this: https://github.com/facebook/react/blob/6e650109999e5f483fcb910ff20fe8148a566cb2/packages/react-dom-bindings/src/server/ReactFizzConfigDOM.js#L3934 (cc bkardell )

[02:49:16.0391] <zcorpan>
https://chromestatus.com/metrics/feature/timeline/popularity/4403 might be better. Maybe mathml on the web usually isn't in markup but generated from script?

[04:15:42.0871] <annevk>
I really only know one website: https://golem.ph.utexas.edu/~distler/blog/

[04:16:17.0353] <annevk>
There used to be a website that collected all of them, but I don't remember that one

[05:44:46.0639] <bkardell>
> <@zcorpan:mozilla.org> Looking for mathml content in httparchive but it's almost entirely this: https://github.com/facebook/react/blob/6e650109999e5f483fcb910ff20fe8148a566cb2/packages/react-dom-bindings/src/server/ReactFizzConfigDOM.js#L3934 (cc bkardell )

yeah not surprising since the http archive is mainly getting home pages and even sites dedicated to math and science don't usually put math on the home page :). There are sites like https://ar5iv.labs.arxiv.org/, for example..

[05:48:13.0531] <bkardell>
and wikipedia has many millions but currently (because of core interop issues - that's why we're here) still doesn't use it for rendering, only for a11y -- so like https://en.wikipedia.org/wiki/Mass%E2%80%93energy_equivalence has 30 mathml instances related to images of math - ick

[05:51:20.0669] <bkardell>
zcorpan: we have a few very rich sources - is there something you're trying to answer specifically that I can help with or just generally poking around?

[05:53:51.0827] <zcorpan>
bkardell: trying to get a sense of how much content uses `href` and on which elements

[05:56:18.0066] <bkardell>
> <@zcorpan:mozilla.org> bkardell: trying to get a sense of how much content uses `href` and on which elements

ah well you can see _some_ discussion in that issue (there are some related emails or issues with more on this same topic, but it's pretty generally aligned with this) https://github.com/w3c/mathml-core/issues/142#issuecomment-1082772082

[05:56:37.0224] <bkardell>
> in the full collection there, there are 30 <mrow with href as opposed 97549 <mi and 3226 <mn

[05:58:06.0090] <bkardell>
the thing is most of the corpuses are in XML toolchains that they are open to some transforms on - many things have been adapted for mathml-core already

[06:00:10.0306] <bkardell>
That's why I am saying if the group is like "we should prefer mrow because then links still work" I am like, well, only a tiny tiny fraction and the rest you have to transform anyways - let's just fix it properly

[06:03:51.0929] <zcorpan>
Right

[06:58:31.0946] <bkardell>
> <@zcorpan:mozilla.org> Right

 I do think the a11y tools might be a pretty compelling argument (many are already fine so we'd have to see how difficult the other two are I guess)  - I am just trying to make sure `<a>` gets a fair shot is all because i think it is clearly the best answer if possible...But I can also accept if it is not, it's not a hill I want to get seriously injured on

[08:00:30.0271] <bkardell>
zcorpan: do you have all you need or can I help you find more?

[08:01:54.0598] <zcorpan>
bkardell: a separate use counter for every mathml element in a document with an href attribute, maybe? :)

[08:02:33.0185] <zcorpan>
For now my conclusion is that href at all is very rare

[08:10:02.0157] <bkardell>
hmm, idk - in some sets it is not rare at all. In a few almost every token has an href, but in those cases that is to do a toolip about what it represents or something and would be better maybe as a popover :)

[08:12:48.0775] <bkardell>
but yeah I guess there are many many docs with no links too

[08:16:12.0339] <bkardell>
there are also potentially false positives depending on how you count.. like `document.querySelectorAll('math [href]').length` is too naieve because it will give you positives of links that are in foreign content inside the tokens (which is fine, it's just HTML), and also stuff inside `<annotation-xml>` which isn't displayed 

[08:17:10.0360] <zcorpan>
I looked at like 50 that match the chromium use counter and not one had `math [href]` on a presentation-math element. There was one with a href attribute inside `annotation-xml` but that was not a rendered element

[08:23:05.0110] <bkardell>
emilio: had some counters in moz, not sure if they are still there or if they're counting this, but you could check? I mean, he is the one that opened the issue we're all pointing at even - so it's possible :)

[15:36:15.0382] <Timo Tijhof>
I'm trying to preload requests for `<script type=module src=…>` via the HTTP Link header.

I'm aware of, and have read, the past discussions around why `rel=modulepreload` was introduced separately instead of within rel=preload. As I understand it, module requests are made with a different CORS setting, plus by signalling the module type this way, browsers can do additional optimizations (e.g. look for indirect imports and preload those as well, and honouring import maps).

I'm also aware that at this time, there is no way to apply an import map to preloaded resources, which is fine, since the server-side in my case knows the flat and full list of "real" requests that will be made.

All that having been said, I can't seem to find in the spec what rel=preload incantation will result in the preloaded result being used by `<script type=module>`.

In Chrome, if I use `Link: </static/foo.js>;rel=preload;as=script;crossorigin` it will correctly result in the later demand for `<script type=module src=foo.js>` using this request (I can tell by the timing, the initiator, the order, and there not being a duplicat req).

In Firefox, it doesn't and there's instead a duplicate request made later on.

[15:37:40.0186] <Timo Tijhof>
 * I'm trying to preload requests for `<script type=module src=…>` via the HTTP Link header.

I'm aware of, and have read, the past discussions around why `rel=modulepreload` was introduced separately instead of within rel=preload. As I understand it, module requests are made with a different CORS setting, plus by signalling the module type this way, browsers can do additional optimizations (e.g. look for indirect imports and preload those as well, and honouring import maps).

I'm also aware that at this time, there is no way to apply an import map to preloaded resources, which is fine, since the server-side in my case knows the flat and full list of "real" requests that will be made.

All that having been said, I can't seem to find in the spec what rel=preload incantation will result in the preloaded result being used by `<script type=module>`.

In Chrome, if I use `Link: </static/foo.js>;rel=preload;as=script;crossorigin` it will correctly satisfy the later demand for `<script type=module src=foo.js>` by re-using the preload response (I can tell by the timing, the initiator, the order, and there not being a duplicat req).

In Firefox, it doesn't and there's instead a duplicate request made later on.

[15:52:02.0171] <Timo Tijhof>
Hm.. so via [Bugzilla search](https://bugzilla.mozilla.org/buglist.cgi?product=Core&short_desc=preload%20crossorigin&classification=Components&query_format=advanced&short_desc_type=allwordssubstr) I'm finding a related change https://hg.mozilla.org/mozilla-central/rev/72570ac420f0, where I see in the diff context that Gecko apparently considers an (unspecified?) `type=module` attribute for `preload as=script` and discards those. This was done last year for https://bugzilla.mozilla.org/show_bug.cgi?id=1803744 which implemented support for the (also unspecified) ability for `rel=modulepreload` to be used in a Link header.. this despite the standard still saying at https://html.spec.whatwg.org/multipage/links.html#linkTypes:link-type-preload that `modulepreload` does not have "Link processing".

[15:57:43.0109] <Timo Tijhof>
While that sounds cool (and Firefox-only today, Chrome discards it with a console warning for invalid `rel=modulepreload` in HTTP), it's actually unusable for my use case because if I use `rel=preload` with foo.js?v=1, bar.js?v=1 and baz.js?v=1. It ends up doing its recursive logic on each of them, and attempts to preload the unversioned URLs of the discovered dependencies (since the import map isn't known at this time).

[15:58:27.0228] <Timo Tijhof>
 * While that sounds cool (and Firefox-only today, Chrome discards it with a console warning for invalid `rel=modulepreload` in HTTP), it's actually unusable for my use case because if I use `rel=modulepreload` in Firefox for all (or even one) of foo.js?v=1, bar.js?v=1 and baz.js?v=1. It ends up doing its recursive logic, and attempt to preload the unversioned dependency URLs of the discovered imports (since the import map isn't known at this time).


2024-04-03
[18:18:06.0193] <Timo Tijhof>
> <@timotijhof:matrix.org> I'm trying to preload requests for `<script type=module src=…>` via the HTTP Link header.
> 
> I'm aware of, and have read, the past discussions around why `rel=modulepreload` was introduced separately instead of within rel=preload. As I understand it, module requests are made with a different CORS setting, plus by signalling the module type this way, browsers can do additional optimizations (e.g. look for indirect imports and preload those as well, and honouring import maps).
> 
> I'm also aware that at this time, there is no way to apply an import map to preloaded resources, which is fine, since the server-side in my case knows the flat and full list of "real" requests that will be made.
> 
> All that having been said, I can't seem to find in the spec what rel=preload incantation will result in the preloaded result being used by `<script type=module>`.
> 
> In Chrome, if I use `Link: </static/foo.js>;rel=preload;as=script;crossorigin` it will correctly satisfy the later demand for `<script type=module src=foo.js>` by re-using the preload response (I can tell by the timing, the initiator, the order, and there not being a duplicat req).
> 
> In Firefox, it doesn't and there's instead a duplicate request made later on.

I've comment at https://github.com/whatwg/html/issues/7854#issuecomment-2033368873 instead. Hoping I've missed something and that there is at least a way to do these "manually".

[22:21:02.0830] <annevk>
Timo Tijhof: we were just discussing this case earlier in this channel; however, with the `crossorigin` attribute set it should in theory match up. Thinking about it again there's another thing however that set module scripts apart and maybe that's why Gecko doesn't reuse the cache. And that would make sense. Module scripts parse differently and so if you eagerly parse and don't store the original text you couldn't reuse the script as both classic and module script.

[22:23:14.0448] <Domenic>
It felt like that thread had several good implementation bugs that should be filed. Although I can understand that discriminating between impl bugs vs impls following the spec could take some work.

[22:23:18.0335] <annevk>
I guess that makes me lean towards only endorsing `modulepreload` for this, but I see you also need import maps at that level for that to be an okay solution. It's a bit unclear whether that should be prioritized or we should try to make `rel=preload type=module` be a thing as some kind of inbetweeny solution as well.

[22:25:24.0709] <annevk>
Domenic: I only saw this Chrome/Firefox mismatch and if anything that's probably a specification bug for suggesting `rel=preload as=script` works for `type=module`. At least I'm quite convinced now that shouldn't work as it would rule out pre-parsing.

[22:27:27.0818] <Domenic>
Firefox downloading bare imports seems bad. Safari not using module map to dedupe requests seems bad. Chrome downloading bare imports seems bad.

[22:28:58.0379] <Domenic>
rel=preload as=script crossorigin seems like it should not work, although it might populate the HTTP cache. Maybe Chrome has some general request deduping happening; I suspect that's not a module specific problem. "Memory cache"??

[22:30:23.0518] <Domenic>
That said I'm not sure the description is accurate since it includes the <script>. Some of the things Timo Tijhof ascribes to preload/modulepreload are almost certainly due to the <script>

[22:31:30.0809] <Domenic>
Safari behavior also looks so strange that I wonder if it's a DevTools issue.

[23:50:58.0406] <annevk>
Oh, I guess I should have read the Observations section more carefully.

[23:56:48.0446] <Domenic>
 * That said I'm not sure the description is accurate since it includes the `<script>`. Some of the things \<a href="https://matrix.to/#/@timotijhof:matrix.org">Timo Tijhof\</a> ascribes to preload/modulepreload are almost certainly due to the `<script>`

[00:41:27.0098] <zcorpan>
Oooh another browser engine https://github.com/Wuelle/Stormlicht

[05:08:09.0164] <annevk>
PSA: Now would be good time to do a thorough review of https://github.com/WICG/sanitizer-api if that kind of API interests you. We're trying to settle the remaining details so if there's anything you don't like please raise it.

[08:30:24.0988] <bkardell>
annevk: 
> We discussed and agreed we should do what @zcorpan said above for MathML.

Just curious where was that discussion?

[08:38:28.0252] <annevk>
bkardell: Sanitizer API meeting

[08:41:15.0125] <bkardell>
what is the meeting organized under? Igalia is interetest in the Sanitizer API but we weren't aware of the meeting

[08:41:23.0691] <bkardell>
 * what is the meeting organized under? Igalia is interetest in the Sanitizer API but we weren't aware of the meeting annevk 

[08:42:28.0089] <bkardell>
 * what is the meeting organized under? Igalia is interetested in the Sanitizer API but we weren't aware of the meeting annevk

[08:43:27.0713] <bkardell>
we'd like to attend future meetings, and obviously would have liked to have been at that one given the whole mathml thing :)

[08:43:55.0826] <annevk>
freddy: ^^

[08:56:32.0342] <bkardell>
for the record, we're not unhappy with that decision or anything - we just would like to be involved and have interests

[09:17:09.0319] <freddy>
Oh yeah, happy to send invites. Which timezone do you have folks? We're currently very EMEA friendly ;-)

[09:35:31.0735] <Luke Warlow>
> <@fbraun:mozilla.org> Oh yeah, happy to send invites. Which timezone do you have folks? We're currently very EMEA friendly ;-)

Off the top of my head it'd probably be me and Brian most interested, I'm on BST (Europe) so EMEA is perfect for me.

[10:23:06.0996] <bkardell>
I'm in ET 

[10:44:48.0095] <annevk>
It's at 4AM ET.

[10:50:41.0290] <bkardell>
🤷 unfortunate, but I can't expect the world to bend to my schedule.  Luke will be there at least. If I need to be there I will 

[10:51:00.0952] <bkardell>
 * 🤷 unfortunate, but I guess I can't expect the world to bend to my schedule :)  Luke will be there at least. If I need to be there I will 


2024-04-04
[23:09:58.0774] <freddy>
Invites sent

[03:25:21.0360] <zcorpan>
Who remembers this gem? https://www.youtube.com/watch?v=zoInPRApZcc (the original site is no longer functional, and it was Flash - https://web.archive.org/web/20110415095516/http://www.xtranormal.com/watch/7991991/web-sockets-we-are-the-first )

[03:29:03.0391] <annevk>
Have you heard about the IndexDB? 😂

[05:11:33.0842] <peterv>
Luke Warlow: the PR for `StringContext` doesn't have any changes for distinguishability, but I wonder if that's ok. Strings and objects are distinguishable in general, but I'm not sure that that's going to work with `StringContext` annotated strings.

[05:11:57.0291] <peterv>
since that can take a trusted type object

[05:13:41.0176] <Luke Warlow>
Generally speaking we don't need overloading for the use case of StringContext, and I think that's why the PR has kinda skirted around that issue. Given StringContext has side effects I'm not sure how it could work to resolve the overloads

[05:15:02.0613] <peterv>
right, so we might need to make `StringContext`-annotated strings not distinguishable from `object`, or anything that object is not distinguishable from

[05:15:15.0314] <peterv>
this also affects unions iirc

[05:17:44.0146] <Luke Warlow>
The approach TT has taken for where it needs unions is to just use the Trusted type directly and handle the enforcement in the specific algorithm for that call site. So we also don't need to "support" that case. The only thing we do need to support is shadowing an IDL attribute on a subtype, I'm not sure how that works spec wise?

[05:22:26.0071] <peterv>
that just adds a property on the derived interface's interface prototype object

[05:23:24.0685] <peterv>
I assume the shadowing adds a `StringContext` annotation?

[05:24:21.0474] <peterv>
hmm, but the base interface also has a property for that attribute that would just accept a string

[05:24:38.0377] <peterv>
and you can call that property's setter directly

[05:25:04.0043] <Luke Warlow>
In this specific case that's fine as there's another fallback mechanism to protect against it

[05:25:09.0455] <peterv>
ok

[05:25:27.0665] <peterv>
that should just work as is I think (for attributes)

[05:26:11.0242] <Luke Warlow>
Yeah that was my impression too (it does in practice in my implementation). Just wondered if that came into the overloading stuff at all.

[05:27:00.0091] <peterv>
shouldn't that's for operations

[05:27:07.0381] <peterv>
 * shouldn't, that's for operations

[05:53:45.0086] <peterv>
annevk: is the idea that none of the arguments that have an index >= distinguishing argument index can have a `[StringContext]` extended attribute on their type?

[06:41:06.0520] <annevk>
peterv: I hadn't really considered that yet. It seems weird that [StringContext] only works some of the time and the remainder you have to patch the specification algorithm directly. Why not just patch the specification algorithm in all cases then?

[06:48:07.0893] <peterv>
It almost feels like we should treat `[StringContext]`-annotated strings as a different string type from non-`[StringContext]`-annotated, that way all string types for index < distinguishing argument index must all either have `[StringContext]` or not

[06:48:16.0134] <peterv>
since they must have the same type

[06:48:42.0741] <Luke Warlow>
> <@annevk:matrix.org> peterv: I hadn't really considered that yet. It seems weird that [StringContext] only works some of the time and the remainder you have to patch the specification algorithm directly. Why not just patch the specification algorithm in all cases then?

Because that's much more intrusive in specs and in implementations.

[06:48:57.0868] <peterv>
if they're in the same position in the argument list that is

[06:48:58.0703] <Luke Warlow>
With this attribute we can avoid touching most callsites and spec algorithms

[06:50:46.0983] <peterv>
but for index >= distinguishing argument index it's unclear to me what we want

[06:51:21.0927] <peterv>
where does that come up in practice?

[06:52:13.0736] <annevk>
I think it doesn't come up currently because it's sparsely used. Which makes me wonder how many call sites we are worried about here.

[06:52:47.0730] <annevk>
But it's also becoming clear that as a generic IDL utility there's quite a few issues with it which makes me wonder if it will ever see usage beyond Trusted Types.

[06:52:58.0880] <peterv>
hmm, can we cop out then and disallow that?

[06:53:36.0227] <annevk>
We could or we could not add this to IDL and instead have the various specification algorithms deal with it directly. As the more complicated cases are already doing.

[06:56:22.0434] <peterv>
so they would all take `TrustedType or DOM/USVString`?

[06:57:09.0086] <peterv>
a bit messy for attributes, since they'll only return a string ever

[06:57:40.0685] <annevk>
Yeah and the first step of their algorithm does something to turn that into an Infra string. Presumably that matches what we do for the more complicated cases Luke Warlow?

[06:58:09.0953] <annevk>
Yeah, I guess this brings up attributes really needing to be separated into setters and getters again.

[06:58:45.0240] <Luke Warlow>
> <@annevk:matrix.org> Yeah and the first step of their algorithm does something to turn that into an Infra string. Presumably that matches what we do for the more complicated cases Luke Warlow?

Yeah pretty much, https://pr-preview.s3.amazonaws.com/lukewarlow/trusted-types/pull/484.html#the-textContent-idl-attribute shows a good example.

[06:59:25.0424] <Luke Warlow>
> <@annevk:matrix.org> Yeah and the first step of their algorithm does something to turn that into an Infra string. Presumably that matches what we do for the more complicated cases Luke Warlow?

 * Yeah pretty much, https://pr-preview.s3.amazonaws.com/lukewarlow/trusted-types/pull/484.html#the-textContent-idl-attribute shows a good example.

It uses a union (so we don't have to deal with nullable types with StringContext) and then step 1 is just to call the algorithm that handles converting to a string (with enforcement)

[07:00:17.0920] <Luke Warlow>
Fwiw at least in WebKit if you have an attribute with a union type the function can just return one of the types directly and it'll handle it further up. So at least the getters don't need to worry about variants

[07:01:19.0456] <Luke Warlow>
> <@annevk:matrix.org> I think it doesn't come up currently because it's sparsely used. Which makes me wonder how many call sites we are worried about here.

I'm counting the callsites we'd have to change now

[07:01:28.0126] <annevk>
To me that doesn't seem so bad and preferable over this StringContext business. Especially if there's only a dozen or so callers that use StringContext currently. Or are there many more?

[07:08:49.0214] <Luke Warlow>
```
Element innerHTML
Element outerHTML
Element insertAdjacentHTML
Element setHTMLUnsafe

ShadowRoot innerHTML
ShadowRoot setHTMLUnsafe

Document parseHTMLUnsafe
Document parseFromString

Range createContextualFragment

HTMLIframeElement srcdoc

Window/Worker setTimeout
Window/Worker setInterval


HTMLScriptElement innerText
HTMLScriptElement src
HTMLScriptElement text

ServiceWorkerContainer register

WorkerGlobalScope importScripts
```



[07:09:28.0570] <Luke Warlow>
I think that's the full list (unless we find anymore missing ones 🙈), so just shy of 20.

[07:11:29.0635] <Ms2ger>
Where does HTMLScriptElement innerText come from?

[07:11:58.0652] <Luke Warlow>
https://pr-preview.s3.amazonaws.com/lukewarlow/trusted-types/pull/484.html#the-textContent-idl-attribute This PR which partially fixes the TT specs script handling

[07:12:23.0925] <Luke Warlow>
 * https://pr-preview.s3.amazonaws.com/lukewarlow/trusted-types/pull/484.html#dom-htmlscriptelement-innertext This PR which partially fixes the TT specs script handling

[07:14:48.0822] <Luke Warlow>
> <@annevk:matrix.org> To me that doesn't seem so bad and preferable over this StringContext business. Especially if there's only a dozen or so callers that use StringContext currently. Or are there many more?

My gut feeling is this attribute probably won't get used outside of TT. And that the changes to algorithms are probably unintrusive enough (exactly because they're the simple cases) that it's probably fine to just go with union IDL types everywhere. Obviously it will require changes to implementations, but its entirely an implementation detail (not an observable difference in behaviour) so it's not too much of a hassle?

[07:15:24.0344] <Ms2ger>
Implementations will need work anyway :)

[07:16:42.0481] <Luke Warlow>
> <@ms2ger:igalia.com> Implementations will need work anyway :)

I mean yeah exactly, it's not even implemented in Gecko yet (I don't think), I can do the webkit change easily enough, so it's really Chrome that it would be extra work for but even then they'll have to make changes to their implementation in various places anyway.

[07:18:09.0736] <peterv>
I'm wondering, why doesn't `Element setAttribute` need to be changed too?

[07:18:19.0854] <Luke Warlow>
It uses a union type

[07:18:25.0037] <zcorpan>
Luke Warlow: https://source.chromium.org/search?q=(scripturlstring%20OR%20htmlstring%20OR%20scriptstring%20OR%20trustedtype)%20file:.idl&ss=chromium

[07:19:03.0093] <Luke Warlow>
 * It uses a union type, the list above is just ones currently using the IDL attribute

[07:19:26.0477] <peterv>
> <@lwarlow:igalia.com> It uses a union type, the list above is just ones currently using the IDL attribute

as in, it will use a union type?

[07:19:33.0786] <Ms2ger>
peterv: there's an "attribute change steps" override

[07:19:51.0767] <peterv>
sure, but WebIDL takes a `DOMString`

[07:19:53.0131] <Ms2ger>
Though that doesn't answer your question

[07:19:54.0049] <Luke Warlow>
> <@pvanderbeken:mozilla.org> as in, it will use a union type?

It already does per the spec. there's a few more complicated call sites already setup that way

[07:20:07.0644] <Luke Warlow>
> <@pvanderbeken:mozilla.org> as in, it will use a union type?

 * It already does per the spec (that one is in a PR to DOM still). there's a few more complicated call sites already setup that way

[07:20:19.0830] <peterv>
ah, ok, so that change still needs to happen

[07:20:39.0122] <peterv>
I didn't see it in the TT spec as one of the changes that need to be done to other specs

[07:21:04.0637] <Luke Warlow>
> <@pvanderbeken:mozilla.org> I didn't see it in the TT spec as one of the changes that need to be done to other specs

Yeah that particular one is in an odd state, I should probably add a note to TT to point to the PRs

[07:21:40.0595] <peterv>
I'm fine with not having the extended attribute given that we have a mix now

[07:22:16.0867] <peterv>
the extended attribute is nice because it documents what happens, but if it's not used everywhere that isn't exactly true

[07:22:35.0710] <Luke Warlow>
All the DOM APIs (of which a several are changed), execCommand, SVGAnimatedString baseVal, HTMLScriptElement textContent all already use union types (potentially others too)

[07:22:57.0427] <Luke Warlow>
 * All the DOM APIs (of which a several are changed), execCommand, SVGAnimatedString baseVal, HTMLScriptElement textContent all already use (or are planned to) union types (potentially others too)

[07:23:35.0228] <peterv>
well, the union also documents but it's more complicated to understand in that the end result is still a string value

[07:24:07.0251] <Luke Warlow>
> <@pvanderbeken:mozilla.org> well, the union also documents but it's more complicated to understand in that the end result is still a string value

Yeah I think ultimately TT complicates things no matter what form it's in. So it's probably fine?

[07:26:30.0772] <peterv>
in terms of implementation, the extended attribute might be easier for adding special treatment in the binding code itself (with the union you'd have to detect these special unions)

[07:27:11.0326] <Luke Warlow>
So I think the binding code would treat it as any other union and you'd just update the callsite directly

[07:27:27.0087] <peterv>
but I don't have implementation experience 🙂

[07:27:45.0620] <Luke Warlow>
Bit messier having to unpack a variant, but it's pretty fine, and we already have to do it in a number of places :)

[07:28:04.0686] <peterv>
hmm, I think I would advocate doing it in the generated code in Gecko 🙂

[07:28:28.0626] <peterv>
there's all kinds of complications with the exceptions etc that I'd rather centralize

[07:29:32.0075] <Luke Warlow>
Mirko was working on that recently and as I understand it the binding code is quite custom in gecko already, so probably something nice that can be done there.

[07:34:14.0894] <Luke Warlow>
Next steps are to close that PR out and update the spec to use unions instead? Should we wait to hear from Googlers?

[07:42:48.0000] <peterv>
I think we should wait a bit 🙂

[09:07:20.0189] <keithamus>
Is there a meeting happening? I requested to join but I don't know if I'm in the wrong one or what.

[09:10:55.0017] <annevk>
keithamus: my calendar says there's a meeting at 1AM Berlin time.

[09:11:45.0099] <keithamus>
Ah, odd. Mine says there's one during this hour. I guess that's in error, and I'll delete. Thanks annevk 

[09:12:53.0214] <annevk>
Yeah, looks like it's in error: https://github.com/whatwg/html/issues/10229

[16:15:13.0560] <Domenic>
> <@lwarlow:igalia.com> My gut feeling is this attribute probably won't get used outside of TT. And that the changes to algorithms are probably unintrusive enough (exactly because they're the simple cases) that it's probably fine to just go with union IDL types everywhere. Obviously it will require changes to implementations, but its entirely an implementation detail (not an observable difference in behaviour) so it's not too much of a hassle?

I think it's observable via exception order and other side effects during argument processing. (x, y, z) where right now doing TT conversions on y would throw an exception. Now we'd convert z before doing TT conversions.


2024-04-05
[23:18:47.0685] <annevk>
Yeah, that aspect would be observable with this change. I think if we had to preserve that I'd favor some kind of [VerifyArgument] annotation over attempting to change the type. So you'd have to write `[VerifyArgument] (TrustedHTML or DOMString) input` and `[VerifyArgument]` would take care of running some kind of callback based on the type of argument. Maybe that's a reasonable middle ground even that would also allow the more complicated cases to rely on IDL.

[23:19:32.0763] <annevk>
 * Yeah, that aspect would be observable with this change. I think if we had to preserve that I'd favor some kind of \[VerifyArgument\] annotation over attempting to change the type. So you'd have to write `[VerifyArgument] (TrustedHTML or DOMString) input` and `[VerifyArgument]` would take care of running the "verify/validate" algorithm based on the type of argument. Maybe that's a reasonable middle ground that would also allow the more complicated cases to rely on IDL.

[00:36:15.0386] <Ms2ger>
I'm not sure if running arbitrary validation code in the middle of IDL conversion excites me all that much. Is changing the order of operations a blocker?

[01:48:18.0429] <Luke Warlow>
We're already changing the ordering for some things (script element properties) so I don't think that's gonna be a blocker personally. It would be odd if people are relying on that ordering. And as we already use unions in some places its not consistently ordered already.

[01:59:58.0790] <dprz>
> <@ricea:matrix.org> Sorry, yes, Chrome's behaviour for non-special URLs is currently incorrect, but we're working on it. You can star this bug https://issues.chromium.org/issues/40063064 to be notified when there are updates.

thanks for confirming, and thank you for the work done on the Chrome project :)

[07:32:25.0876] <Domenic>
I think the question is do implementations want to code-gen in their bindings or write custom per-method C++.

If they want to code-gen in their bindings then I think it should be handled with an IDL extended attribute or type. I think this IDL construct should be very trusted types specific; I don't understand why we'd want something generic like [StringContext] or [VerifyArgument].

[07:58:11.0617] <Luke Warlow>
My two cents are that implementations already have to write custom c++ in a number of cases (I count at least 11 separate places), so it's probably not particularly worse to have to do it for the 19 or so new places. That being said it's ultimately up to WebKit, Gecko and Chromium projects to decide if they're comfortable with that.

[07:59:05.0878] <annevk>
Given what CEReactions does I don't think the timing has to depend on where it's solved. Although I guess there's an interesting question as to whether CEReactions or this goes first? Also the fact that there's a number of cases that are not solved through bindings makes me rather wary about having a complete special case for a subset.

[08:01:25.0069] <Luke Warlow>
> <@lwarlow:igalia.com> My two cents are that implementations already have to write custom c++ in a number of cases (I count at least 11 separate places), so it's probably not particularly worse to have to do it for the 19 or so new places. That being said it's ultimately up to WebKit, Gecko and Chromium projects to decide if they're comfortable with that.

Worth noting it's realistically actually more than 11 places that need custom c++ because of various of ways that TT integrate into browsers, e.g csp pre navigation checks, and the DOM attribute handling both have similar enforcement code.


[08:14:55.0949] <smaug>
Looks like the image around https://html.spec.whatwg.org/#attr-script-async isn't working too well in dark mode

[09:49:25.0303] <sideshowbarker>
jarhar: Can you remind me what setup you’re using with vim to get auto-completion when working on the Chromium sources?

[09:54:45.0846] <jarhar>
i dont use auto completion in vim. for browsing the code and figuring out what to write i just use source.chromium.org

[10:02:20.0640] <sideshowbarker>
ah OK (I vaguely recall now that’s what you’d already actually told me before…)

[10:14:52.0711] <annevk>
bakkot: I'm postponing merging Float16Array till Monday. Not feeling great and want to make sure it happens correctly.

[10:15:03.0587] <annevk>
 * bakkot: I'm postponing merging Float16Array into IDL/WPT till Monday. Not feeling great and want to make sure it happens correctly.

[10:15:33.0141] <bakkot>
√, no rush at all given that it's only barely implemented in one engine

[11:07:44.0067] <hacknorris>
okay, this might be offtopic but better here than nowhere. someone knows any cool tutorial for writing xsd schemas? i'm that dumb i don't understand even from w3schools…

[11:11:52.0952] <hacknorris>
like i wanted to make something like sitemap.xml but for "bookmarks" of sites people like (idk how it's named. webring? maybe…)

[12:05:11.0136] <hacknorris>
?

[12:05:20.0318] <hacknorris>
 * so any tutorial?

[13:33:18.0803] <hacknorris>
nvm. manually downloaded sitemap.xsd from origin and learning from there 😕

[15:19:34.0223] <TabAtkins>
> <@smaug:mozilla.org> Looks like the image around https://html.spec.whatwg.org/#attr-script-async isn't working too well in dark mode

https://github.com/whatwg/html/pull/10257

[15:19:40.0578] <TabAtkins>
annevk or Domenic ^^^

[15:21:09.0382] <smaug>
superb. Will there be a preview of that all?

[15:22:16.0056] <smaug>
ah, it is there now, I think

[15:24:28.0528] <smaug>
but looks like the new diagrams aren't there

[15:26:11.0097] <TabAtkins>
Yeah, I suspect it's still linking to the ones on whatwg.org, not the local files from the PR

[15:27:49.0648] <TabAtkins>
but if you drop in a `.render-shell img { background: none !important; }` into your inspector and look at the files-changed tab, you'll see the files against a dark background.

[15:29:27.0214] <TabAtkins>
you'll have to do it per-file, since they're in separate iframes, unfortuantely.

[15:29:49.0227] <TabAtkins>
oh, also need `.render-shell { color-scheme: dark; background: #222; }`

[15:30:01.0962] <TabAtkins>
then you can properly see the old image failing and the new one succeeding

[16:07:27.0195] <TabAtkins>
https://github.com/whatwg/whatwg.org/pull/439 as well, to cover the same problem cases across the rest of WHATWG specs. I'll review their usage of SVGs later, but for now just giving them a white background will ensure they're readable.


2024-04-08
[04:09:06.0794] <hsivonen>
annevk: Intentional or accidental that the URL Standard supports full-width characters for IPv4 but not for IPv6?

[04:18:18.0162] <annevk>
hsivonen: Intentional. Supporting them for IPv4 is not desired, but it's the outcome of only being able to distinguish between domains and IPv4 addresses late. For the same reason IPv4 supports %31 and such, but IPv6 does not.

[04:19:04.0969] <hsivonen>
> <@annevk:matrix.org> hsivonen: Intentional. Supporting them for IPv4 is not desired, but it's the outcome of only being able to distinguish between domains and IPv4 addresses late. For the same reason IPv4 supports %31 and such, but IPv6 does not.

OK. Thanks. Let's see what I break by removing full-width IPv6 support from Gecko...

[04:42:01.0107] <Adam Eisenreich>
Hi I would like to create a proposal form HTML, `<input mask="0000-0000-0000-0000">`. Sadly I am not sure how to do so. Do I create a repository? Is there a template for proposal repository?

[04:45:48.0725] <Ms2ger>
https://whatwg.org/faq#adding-new-features

[05:01:00.0728] <Adam Eisenreich>
> <@ms2ger:igalia.com> https://whatwg.org/faq#adding-new-features

According to this, My work is done :D https://github.com/whatwg/html/issues/7794. Realistically is there anything I should do?

[05:42:16.0754] <Luke Warlow>
Does anyone know off the top of their head whether an element's children changed steps (https://dom.spec.whatwg.org/#concept-node-children-changed-ext) are called by the HTML parser? In Chromium and WebKit the function receives an argument to differentiate between parser and API (JS) but the DOM spec doesn't pass an argument.

[05:42:52.0465] <Luke Warlow>
 * Does anyone know off the top of their head whether an element's children changed steps (https://dom.spec.whatwg.org/#concept-node-children-changed-ext) are called by the HTML parser? In Chromium and WebKit the function receives an argument to differentiate between parser and API (JS) but the DOM spec doesn't pass an argument. So I'm wondering if this distinction isn't needed in the spec because it's not actually called by the parser?

[05:47:52.0318] <annevk>
Luke Warlow: it's called by the parser as things stand today

[05:48:28.0382] <Luke Warlow>
> <@annevk:matrix.org> Luke Warlow: it's called by the parser as things stand today

Okay thanks. Time to work out a plan B for detecting JS changes.

[07:32:12.0629] <Luke Warlow>
 * ```
Element innerHTML
Element outerHTML
Element insertAdjacentHTML
Element setHTMLUnsafe

ShadowRoot innerHTML
ShadowRoot setHTMLUnsafe

Document parseHTMLUnsafe
DOMParser parseFromString

Range createContextualFragment

HTMLIframeElement srcdoc

Window/Worker setTimeout
Window/Worker setInterval


HTMLScriptElement innerText
HTMLScriptElement src
HTMLScriptElement text

ServiceWorkerContainer register

WorkerGlobalScope importScripts
```

[13:19:52.0391] <Luke Warlow>
If I put some work into upstreaming DOM Parser to the HTML spec would it be prefered as one larger PR, or multiple smaller ones?

[13:20:08.0359] <Luke Warlow>
 * If I put some work into upstreaming [DOM Parsing](https://w3c.github.io/DOM-Parsing/) to the HTML spec would it be prefered as one larger PR, or multiple smaller ones?

[14:18:57.0806] <zcorpan>
Luke Warlow: either way wfm

[16:12:43.0813] <zcorpan>
Hmmm, on markup injection attack mitigation. Maybe we can drop all attributes if one of the attribute names contain `<` or `' ` or `"`


2024-04-09
[00:46:03.0558] <freddy>
That'd be nice. Do you want to add use counters?

[00:52:12.0143] <zcorpan>
I can check httparchive first

[00:54:12.0432] <zcorpan>
Though regexping this will be ... tricky

[01:21:52.0334] <sideshowbarker>
I could add a use counter for it in the HTML checker. Probably could even hack the checker’s HTML parser instance to do the “< or ' ” check (rather than trying to check for those post-parsing).

[01:26:53.0440] <zcorpan>
sideshowbarker: nice, thanks!

[10:23:25.0557] <Luke Warlow>
Should we add a warning about unsafe parsing to the existing parser APIs in the html spec? Currently there's only a warning on the newer setHTMLUnsafe (and parseHTMLUnsafe).

[10:26:17.0469] <Luke Warlow>
* Should we add a warning about ~unsafe~ unsanitised parsing to the existing parser APIs in the html spec? Currently there's only a warning on the newer setHTMLUnsafe (and parseHTMLUnsafe).

[11:34:07.0573] <annevk>
Luke Warlow: seems reasonable; maybe even centralized and linked from all over

[12:10:22.0785] <Luke Warlow>
https://whatpr.org/html/10267/11ea4a2...67b03f2/dynamic-markup-insertion.html - chucked together a quick PR to add them. for now I've just done the warning paragraphs in the various places. (Not sure exactly where in the markup is best). Not sure what a link to a centralised place would look like


2024-04-10
[19:14:32.0582] <sideshowbarker>
emilio: (or anybody else who might remember) Do you recall how we ended up with the W3C being the home for the Intersection Observer work/spec — rather than WHATWG? 

[23:24:02.0058] <annevk>
Domenic: zcorpan: either of you around to rs https://github.com/whatwg/html/pull/10260?

[23:45:37.0404] <emilio>
> <@sideshowbarker:matrix.org> emilio: (or anybody else who might remember) Do you recall how we ended up with the W3C being the home for the Intersection Observer work/spec — rather than WHATWG? 

I think it predates my involvement with that spec. I assume because it's very css-related? But then arguably it should move to csswg-drafts, like resizeobserver

[07:28:59.0721] <zcorpan>
Does `location.reload()` end up calling "navigate" somewhere? Or no?

[07:42:34.0664] <Noam Rosenthal>
it does not I believe, navigate is only for regular push/replace navigations

[07:43:13.0730] <Noam Rosenthal>
 * it does not I believe, navigate is only for regular push/replace navigations ^ zcorpan 

[07:43:45.0576] <Noam Rosenthal>
https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate 20.9 populates the history entry with type "navigate". when you traverse/reload you wouldn't do that

[07:44:10.0842] <zcorpan>
Noam Rosenthal: thanks. Yeah that's my conclusion as well, but stepping through the spec from `reload()` is not easy :)

[07:45:18.0826] <Noam Rosenthal>
zcorpan: yea, the "session history traversal queue" (aka the browser process in some implementations) is a very technical part of the spec. I get lost in it a lot

[07:49:42.0652] <zcorpan>
I'm working on tests for https://github.com/whatwg/html/pull/10226 - so reload or history traversal would not cancel the lazy load

[07:55:58.0591] <Noam Rosenthal>
zcorpan: that iframe will always be on the initial about:blank page, no? since it's lazy and hasn't been loaded yet?

[07:56:48.0379] <zcorpan>
Noam Rosenthal: I believe so

[07:58:45.0668] <Noam Rosenthal>
zcorpan: wondering what should be the behavior with same-document navigations. e.g. you `pushState` in that `about:blank` page before it's lazy-loaded

[07:59:24.0534] <Noam Rosenthal>
perhaps a safe-ish way to look at this is to cancel those steps when the about:blank page is about to be unloaded

[07:59:52.0657] <Noam Rosenthal>
though maybe that's too late for the replace case

[08:02:31.0583] <zcorpan>
Noam Rosenthal: the spec change only cancels lazy-load in "navigate", which should match Chromium. I think it's a sufficient fix.

[08:03:15.0278] <Noam Rosenthal>
zcorpan: This particular `navigate` in the PR is also for e.g. fragment navigations

[08:04:02.0740] <zcorpan>
Noam Rosenthal: yeah

[08:05:56.0287] <zcorpan>
My test for fragment navigation seems flaky in chromium, so maybe it doesn't exactly match

[08:07:21.0438] <Noam Rosenthal>
zcorpan: looking at the code for this in chromium I'm pretty sure we cancel lazy loading on *any* cross-doc navigation

[08:15:46.0627] <Noam Rosenthal>
yea I guess you'd want to do this whenever you abort a regular navigation

[08:18:09.0936] <zcorpan>
Noam Rosenthal: PR for my tests at https://github.com/web-platform-tests/wpt/pull/45650

[08:22:28.0899] <Noam Rosenthal>
zcorpan: would be interesting to test also what happens when the iframe receives lazy steps after a navigation is started but before it's committed. e.g. you have an about:blank with `lazy` and without a `src`, you navigate it with a link, and the new document is ready to commit before the lazy steps are run

[08:23:04.0839] <Noam Rosenthal>
I think what chromium does here would differ from your spec PR (not saying here what the "right" solution is)

[08:23:30.0761] <Noam Rosenthal>
 * zcorpan: would be interesting to test also what happens when the iframe receives lazy steps after a navigation is started but before it's committed. e.g. you have an about:blank with `lazy` and without a `src`, you navigate it with a link, then set a src, and the new document is ready to commit before the lazy steps are run

[08:25:03.0317] <zcorpan>
Noam Rosenthal: hmm ok, can you comment that in the PR? I can add such a test tomorrow

[09:06:00.0820] <Jake Archibald>
Does anyone have background on why `slot.assign(...nodes)` only works with nodes that are direct children of the host?

[09:45:40.0147] <Noam Rosenthal>
Jake Archibald: sounds like https://github.com/WICG/webcomponents/issues/574, lots of discussion there

[09:58:21.0428] <Jake Archibald>
Noam Rosenthal: yeah, that's it, thanks

[09:58:22.0447] <Jake Archibald>
ugh

[09:58:36.0777] <Jake Archibald>
That's a shame

[09:59:00.0364] <Noam Rosenthal>
yea I would probably use the same utterance

[10:01:21.0332] <Noam Rosenthal>
there are good/complex points there, hopefully we can revisit this in the future

[10:01:25.0720] <annevk>
I don't think that's it. We had the discussion again for the imperative API (which that issue is not about) and I recall we were open to revisiting that at some point.

[10:03:21.0800] <Noam Rosenthal>
there's some openness about revisiting it in the future also in the #574 discussion

[10:06:56.0051] <annevk>
It was initially a goal of the imperative API to allow that. I kinda forgot why it ended up with the same restriction.

[10:09:57.0930] <annevk>
https://github.com/whatwg/html/issues/3534#issuecomment-371392184 is the more relevant discussion I think.

[10:10:51.0918] <Jake Archibald>
> Still unclear why the proposal does not state that though or why assign() succeeds despite failing.

[10:10:56.0643] <Jake Archibald>
Yeah, that was a real gotcha for me

[10:10:59.0967] <Jake Archibald>
not even a warning

[10:13:13.0393] <Jake Archibald>
oh well. I hope it gets revisited at some point

[10:14:38.0963] <annevk>
It seems like Google and Mozilla blocked it.

[15:00:42.0951] <Dominic Farolino>
Suppose I have a spec variable that is "initially null", and I set it to an {{any}} return value of [=invoking=] a JS callback.

[15:01:21.0101] <Dominic Farolino>
If that callback returns "null" in JS, is my spec variable still "null" (i.e., indicating that it was never set), or is it some special "Web IDL {{null}}" value or something?

[15:01:45.0644] <Dominic Farolino>
(I know {{null}} does not exist in WebIDL, but I'm trying to understand if spec prose "null" is the same as null that goes through WebIDL)

[15:08:37.0093] <Jeffrey Yasskin>
I think folks reading that will assume the two "null"s are the same, so you should write the spec so that assumption doesn't cause problems.

[15:11:10.0334] <Andreu Botella>
Infra's definition of null treats it as interchangeable with the JS `null` value, but WebIDL's `any` conversion converts JS `null` to the null nullable `object`, which is not explicitly said to be the same as Infra's null.

[15:11:21.0512] <Andreu Botella>
 * Infra's definition of null treats it as interchangeable with the JS `null` value, but WebIDL's `any` conversion converts JS `null` to the null `object?`, which is not explicitly said to be the same as Infra's null.

[15:14:12.0045] <Jeffrey Yasskin>
WebIDL 'any' is a weird beast, in that "one value of the any type is the unsigned long 150, while another is the long 150. These are distinct values." Specs often implicitly convert all those contained values into a common spec type, but that's not really justified by WebIDL.

[15:17:22.0919] <Jeffrey Yasskin>
I do think the `null` `object?` value is the same as the Infra null: https://webidl.spec.whatwg.org/#idl-object talks about `object?` adding "the null value" to the type, and it's no more distinguished from Infra than "true" and "false" are in https://webidl.spec.whatwg.org/#idl-boolean.


2024-04-11
[17:46:13.0183] <Domenic>
I am in favor of treating all nulls the same... the platform has enough null-ish things.

[22:28:36.0270] <annevk>
I think if you need to distinguish two nullish values in those cases you should start out with your variable being undefined. If you really need the equivalent of any-or-nothing I'm not sure. Maybe a side boolean? But maybe also reconsider the general API shape.

[01:56:19.0596] <Jake Archibald>
> <@annevk:matrix.org> It seems like Google and Mozilla blocked it.

That's sad. I filed an issue for it. I'll see if it's something Shopify would let me spend time on https://github.com/whatwg/html/issues/10273

[03:12:40.0707] <Noam Rosenthal>
Looking at the term "similar-origin window agent" (https://html.spec.whatwg.org/multipage/webappapis.html#similar-origin-window-agent). 
In a nested cross-origin iframe case like `A1 -> B -> A2`, is there a way where `A1` can get script access to A2's window?

[03:15:42.0263] <Noam Rosenthal>
oh I guess `window[name]`. Weird old stuff I forgot about

[03:19:44.0617] <Ms2ger>
annevk: what, are you holding me responsible for bugs I introduced now? :)

[03:33:32.0032] <annevk>
Ms2ger: git blame is a wonderful thing.

[08:09:22.0216] <Domenic>
> <@noamr:matrix.org> Looking at the term "similar-origin window agent" (https://html.spec.whatwg.org/multipage/webappapis.html#similar-origin-window-agent). 
> In a nested cross-origin iframe case like `A1 -> B -> A2`, is there a way where `A1` can get script access to A2's window?

I would do `window[0][0]` so you don't even have to know the names, just enumerate over integers until you find something that doesn't throw when calling `.document`

[09:00:27.0139] <Noam Rosenthal>
Domenic: yea, I meant in general the `window[...]` feature... thanks

[09:35:05.0667] <Noam Rosenthal>
smaug: see https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/frame_loader.cc;l=388?q=frame_loader.c

[09:36:04.0669] <Noam Rosenthal>
We're unloading the document with `will_commit_new_document_in_this_frame === false`

[09:36:13.0570] <smaug>
Noam Rosenthal: and that gets called at what point when iframe is removed from DOM

[09:37:59.0449] <Noam Rosenthal>
smaug: that would happen in https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=642;bpv=1;bpt=1?q=container_node.cc

[09:38:11.0375] <smaug>
thanks!

[09:38:52.0058] <Noam Rosenthal>
so it's right *before* doing the actual DOM remove. the iframe would still appear connected if you query the parent's DOM during the `pagehide` event listener

[09:40:06.0474] <smaug>
looks like the code is pretty much as hacky as in Gecko 😛 

[09:41:41.0814] <smaug>
/me vaguely recalls fixing some crashes around iframe removal...maybe 15 years ago

[09:42:23.0681] <Noam Rosenthal>
yea this synchronous removal stuff is nasty. For the synchronous blur event firing we have so much special-case code

[10:00:54.0546] <Luke Warlow>
Sorry for dropping out there my headset ran out of battery right as I was going to speak

[10:01:27.0639] <smaug>
I'll need to check all the callers of AddScriptRunner. Gecko has > 100 of those

[10:01:49.0256] <smaug>
(many of them don't affect anything on the web though)

[12:53:35.0640] <smaug>
Dominic Farolino: actually, I don't know how the insertion step model works in case of mutations. Say, you have an element and it has 3 child elements.  That subtree root element is inserted to document tree. Now child 1  has insertion steps which run some script which removes the child and adds it to be the last of the child nodes. So child list is now 2, 3, 1.  Do the insertion steps get run on 1 again, because it is now after 2 and 3?

[12:53:43.0882] <smaug>
The pr doesn't explain this

[13:14:31.0081] <smaug>
I mean, the insertion step would certainly run when 1 is added back to DOM, but would insertion step run again when iterating through the children of the subtree root.


2024-04-12
[06:20:52.0374] <freddy>
is there a way to style a popover (or a popover's children) that they become visible? I guess overriding the user-agent sheet "display: none" makes it not so?

[06:21:15.0574] <freddy>
 * is there a way to style a popover (or a popover's children) that they become visible? I guess overriding the user-agent sheet "display: none" for a popover isn't possible. But not even for the children?

[07:08:26.0047] <Luke Warlow>
> <@fbraun:mozilla.org> is there a way to style a popover (or a popover's children) that they become visible? I guess overriding the user-agent sheet "display: none" for a popover isn't possible. But not even for the children?

Why is that not possible? I thought you could just say "display: block" and it would show?

[07:12:36.0429] <freddy>
Mh, not for the children. `<div popover style="display:block"><h1>test` shows the div with the h1 child but `<div popover><h1 style="display:block;">test` doesnt.  I guess that's sort of intentional and I get it. I just wonder what kind of override there is

[07:12:54.0881] <freddy>
I tried adding `!important` and `visibility: visible` for good measure ;)

[07:21:29.0195] <annevk>
freddy: that would still put display:none at the top of the subtree and that wins

[07:21:50.0067] <annevk>
freddy: so you need to change that too, perhaps display:contents is what you're after?

[07:28:54.0196] <freddy>
<small>perhaps I don't get CSS specificity </small>

[07:42:18.0415] <annevk>
It's not about specificity, it's cascade

[07:42:53.0466] <annevk>
Maybe not even that, as I guess it's not really inherited

[07:49:03.0034] <emilio>
Yeah is just that display: none is not overridable on descendants 

[12:01:58.0413] <TabAtkins>
Yup, nothing about popover is special here. `display: none` on a container prevents the container and all of its contents from generating boxes *at all*, with no override possible on the descendants. (After all, what would that mean?)

[14:19:37.0950] <Dominic Farolino>
> <@smaug:mozilla.org> Dominic Farolino: actually, I don't know how the insertion step model works in case of mutations. Say, you have an element and it has 3 child elements.  That subtree root element is inserted to document tree. Now child 1  has insertion steps which run some script which removes the child and adds it to be the last of the child nodes. So child list is now 2, 3, 1.  Do the insertion steps get run on 1 again, because it is now after 2 and 3?

I'm just seeing this now because this website was unloaded in my Chrome and the freaking favicon didn't give me updates that I had a ping, sorry!

[14:20:02.0716] <Dominic Farolino>
> Now child 1 has insertion steps which run some script

Do you mean post-insertion steps?

[14:46:38.0254] <Dominic Farolino>
> Do the insertion steps get run on 1 again, because it is now after 2 and 3?

Yes they do, and the PR answers this.

I'll assume every instance of "insertion step" in your message is "post-insertion step". With that edit, here's what happens:

1. Insertion steps would run for the root, and its three children, in tree order, never running script.
2. Post-insertion steps would run for the root, and its three children, in the same order.
3. Say the first child is an about:blank iframe with an `onload` handler. This handler is synchronously invoked (for child 1) during its post-insertion steps (that's how iframes work; the initial about:blank iframe fires load syncly).
4. The event handler removes the iframe from the DOM, and re-inserts it after its siblings.
5. This re-enters the DOM insertion algorithm, which synchronously re-enters its post-insertion steps, and re-invokes the `onload` event for the same iframe element. This runs the event handler re-entrantly.

Please see https://gist.github.com/domfarolino/83b1a436c5ad4fc68b04aa0092985f58 and run this in the console in Chrome (Firefox does not synchronously fire `onload` for about:blank iframes IIRC).

Note that post-insertion steps do not intend to solve re-entrant event handlers by forcing their order to be broken or anything. They _only_ ensure that by the time script runs in them, the batch of relevant DOM mutations (associated with the insertion) are all complete.

[14:47:02.0231] <Dominic Farolino>
smaug for above

[14:49:45.0530] <smaug>
2 is unclear

[14:50:26.0547] <smaug>
why it iterates them in 1, 2, 3 and not 1, 2, 3, 1 ?

[14:51:44.0744] <smaug>
(Note, script runners don't have this issue, since the post-insertion steps is just a queue )

[14:53:00.0201] <smaug>
 * why it iterates them in 1, 2, 3 and not 1, 2, 3, 1 ? (since step (3) moves 1 to be after 3)

[14:54:34.0617] <smaug>
In other words, how does the PR ensures that post-insertion steps aren't run 3 times for the child element, which is inserted to document only twice? 

[14:55:27.0655] <smaug>
(Script runners avoid this issue by queuing the post-insertion operations)

[14:59:51.0762] <smaug>
 * step (2) is unclear

[15:17:31.0965] <smaug>
Isn't the PR missing https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=430?q=container_node.cc 

[15:19:02.0824] <smaug>
and https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=363;drc=0ebe2cf9f3f6544ba582473c5b9b8e3506f29708?q=container_node.cc

[15:19:37.0748] <smaug>
(seems complicated and less flexible vs script runners)


2024-04-14
[21:28:12.0140] <Thad Guidry>
Hello,  I'm using ReSpec and trying to reference the 2 concepts that I thought would already be part of Webref (xref) indexing and/or even Infra.
MUST - aka REQUIRED
MAY - aka OPTIONAL

I know from RFC2119 that these have been around forever.  But I was honestly surprised that even with those terms used in Infra docs itself and 1000's of other standards, that those 2 concepts are not indexed?  

The reason I would have thought they would already be part Webref was that they come into play when describing parameters or arguments that are either REQUIRED or OPTIONAL.

How can I help make the concepts of RFC2119 (and the concepts aliases) as part of Webref or Infra , so that in ReSpec I could simply refer to them via the Shorthand syntax of `[=OPTIONAL=]` and [=REQUIRED=]` ?

[21:29:19.0196] <Thad Guidry>
 * Hello,  I'm using ReSpec and trying to reference the 2 concepts that I thought would already be part of Webref (xref) indexing and/or even Infra.
MUST - aka REQUIRED
MAY - aka OPTIONAL

I know from RFC2119 that these have been around forever.  But I was honestly surprised that even with those terms used in Infra docs itself and 1000's of other standards, that those 2 concepts are not indexed?

The reason I would have thought they would already be part Webref was that they come into play when describing parameters or arguments that are either REQUIRED or OPTIONAL.

How can I help make the concepts of RFC2119 (and the concepts aliases) as part of Webref or Infra , so that in ReSpec I could simply refer to them via the Shorthand syntax of `[=OPTIONAL=]` and `[=REQUIRED=]` ?

[22:28:49.0508] <sideshowbarker>
Thad Guidry: Seems like you can do that by using the English prose words _must_ and _should_ — rather than needing to type an `[=OPTIONAL=]` and `[=REQUIRED=]` macro thing

[22:28:59.0820] <sideshowbarker>
 * Thad Guidry: Seems like you can do that already by using the English prose words _must_ and _should_ — rather than needing to type an `[=OPTIONAL=]` and `[=REQUIRED=]` macro thing

[23:23:19.0823] <By Sineks>
hi

[23:23:54.0454] <By Sineks>
css3 için "backroung-opacity" özelliği gelecekmi?

[23:24:05.0526] <By Sineks>
Will the "backroung-opacity" feature come to css3?

[13:52:09.0385] <Andreu Botella>
I'm looking at custom element reactions. Is my understanding correct that every time that JS code could trigger a CE reaction, it is through a `[CEReaction]` WebIDL method? And the only times where the reactions are run in a microtask are when they're caused by user interaction with no JS code in sight?

[13:52:26.0656] <Andreu Botella>
 * I'm looking at custom element reactions. Is my understanding correct that every time that JS code could trigger a CE reaction, it is through a `[CEReactions]` WebIDL method? And the only times where the reactions are run in a microtask are when they're caused by user interaction with no JS code in sight?


2024-04-15
[18:05:56.0595] <sideshowbarker>
A couple of questions for the room:

1. Are any of y’all still using HTML Tidy?
2. If you are still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?

I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, what would be helpful is know if people in our community here are actually using HTML Tidy and would find a replacement useful.

[18:06:36.0826] <sideshowbarker>
 * A couple of questions for the room:

1. Are any of y’all still using HTML Tidy?
2. If you are still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?

I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.

[18:06:51.0462] <sideshowbarker>
 * A couple of questions for the room:

1. Are any of y’all still using HTML Tidy?
2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?

I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.

[18:08:35.0366] <sideshowbarker>
 * A couple of questions for the room:

1. Are any of y’all still using HTML Tidy?
2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?

I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.

So if you have interest, please **+1** this message — and if you have specific details to share, please comment too.

[18:10:06.0317] <sideshowbarker>
 * A couple of questions for the room:

1. Are any of y’all still using HTML Tidy?
2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?

I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.

So if you have interest, please click the **+1** on this message, or add some other emoji — and if you have specific details to share, please comment too.

[18:10:18.0707] <sideshowbarker>
 * A couple of questions for the room:

1. Are any of y’all still using HTML Tidy?
2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?

I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.

So if you have interest, please click the **+1** emoji on this message, or add some other emoji — and if you have specific details to share, please comment too.

[19:11:38.0350] <Timo Tijhof>
> <@sideshowbarker:matrix.org> A couple of questions for the room:
> 
> 1. Are any of y’all still using HTML Tidy?
> 2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?
> 
> I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.
> 
> So if you have interest, please click the **+1** emoji on this message, or add some other emoji — and if you have specific details to share, please comment too.

At Wikimedia, we depended on Tidy and its exact implementation details for well over a decade within the defacto MediaWiki wikitext parser for all article markup. However we finished a long migration a few years ago from php-tidy to our own standalone RemexHtml library which is more standards based. https://www.mediawiki.org/wiki/RemexHtml

[19:13:15.0510] <Timo Tijhof>
> <@timotijhof:matrix.org> At Wikimedia, we depended on Tidy and its exact implementation details for well over a decade within the defacto MediaWiki wikitext parser for all article markup. However we finished a long migration a few years ago from php-tidy to our own standalone RemexHtml library which is more standards based. https://www.mediawiki.org/wiki/RemexHtml

It'd probably be fairly straight forward to put that up in a web app of sorts.

[19:18:11.0358] <Timo Tijhof>
> <@sideshowbarker:matrix.org> A couple of questions for the room:
> 
> 1. Are any of y’all still using HTML Tidy?
> 2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?
> 
> I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.
> 
> So if you have interest, please click the **+1** emoji on this message, or add some other emoji — and if you have specific details to share, please comment too.

* At Wikimedia, we depended on Tidy and its exact implementation details for well over a decade within the defacto MediaWiki wikitext parser for all article markup. However we finished a long migration a few years ago from php-tidy to our own standalone RemexHtml library which is more standards based. https://www.mediawiki.org/wiki/RemexHtml

https://github.com/wikimedia/remex-html/

[19:18:21.0827] <Timo Tijhof>
> <@sideshowbarker:matrix.org> A couple of questions for the room:
> 
> 1. Are any of y’all still using HTML Tidy?
> 2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?
> 
> I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.
> 
> So if you have interest, please click the **+1** emoji on this message, or add some other emoji — and if you have specific details to share, please comment too.

* At Wikimedia, we depended on Tidy and its exact implementation details for well over a decade within the defacto MediaWiki wikitext parser for all article markup. However we finished a long migration a few years ago from php-tidy to our own standalone RemexHtml library which is more standards based.

https://www.mediawiki.org/wiki/RemexHtml

https://github.com/wikimedia/remex-html/

[19:18:58.0452] <Timo Tijhof>
> <@sideshowbarker:matrix.org> A couple of questions for the room:
> 
> 1. Are any of y’all still using HTML Tidy?
> 2. If you _are_ still using HTML Tidy, would you find it useful to have a replacement for it that uses an actual up-to-date spec-conforming HTML parser, rather than the ancient ad-hoc parser that HTML Tidy uses?
> 
> I think it should be possible to create an HTML Tidy replacement from the validator.nu HTML parser (Java) code. And I’m certain _some_ people in the wider developer community would find it useful — but for prioritizing any potential work to make it, it’d be helpful to know if people in our community here are actually using HTML Tidy and would find a replacement useful.
> 
> So if you have interest, please click the **+1** emoji on this message, or add some other emoji — and if you have specific details to share, please comment too.

* At Wikimedia Foundation, we depended on Tidy and its exact implementation details for well over a decade within the defacto MediaWiki wikitext parser for all article markup. However we finished a long migration a few years ago from php-tidy to our own standalone RemexHtml library which is more standards based.

https://www.mediawiki.org/wiki/RemexHtml

https://github.com/wikimedia/remex-html/

[14:09:35.0568] <TabAtkins>
Hm. My mind's blanking on what sort of APIs might already exist that expose user preferences directly to JS.

[14:09:58.0779] <TabAtkins>
(That is, not MQs, but some function you'd call that actually returns some preference value.)

[16:03:34.0797] <Luke Warlow>
Depends on if you count it as a preference but the network information API has a property related to save data mode which is the backing for prefers-reduced-data iirc

[16:04:32.0924] <Luke Warlow>
Other than that matchMedia is all I know of but that doesn't return the underlying value.

[16:42:30.0862] <Kaiido>
Maybe not what you are after but to some extents CSS `<system-color>` values with `getComputedStyle` can give you some insights on some users's preferences.


2024-04-16
[00:20:27.0509] <zcorpan>
TabAtkins: navigator.language and navigator.languages (but these might not match the preference exactly to reduce fingerprinting)

[00:28:44.0031] <zcorpan>
TabAtkins:  devicePixelRatio takes page zoom into account (but not in WebKit it seems)

[00:36:23.0757] <zcorpan>
TabAtkins: timezone in `Date`

[11:27:24.0355] <TabAtkins>
Thanks, y'all.

[11:27:58.0254] <TabAtkins>
Also, sigh, <https://github.com/whatwg/html/issues/10206> is just a dumpster fire of people not reading and then talking past each other. :/ We just need to restart with a fresh issue at this point, there's too much confusion.

[11:46:13.0391] <Luke Warlow>
We need to separate the conventional aria-pressed toggle button, which is its own thing which should exist without aria and scripting, from the cycle button idea.

[11:46:46.0637] <Luke Warlow>
That's one part of the confusion but then there's also the issue that different people have different use cases that I think we're trying to all call a cycle button.

[11:47:41.0648] <Luke Warlow>
If it sounds like a select it probably should be a select. If it sounds like a button then that is what I would consider fair game for this cycle button idea.

[11:49:51.0397] <Luke Warlow>
It might also work better if we can discuss some of this in OpenUI and come back with a more concrete proposal based on a wider array of use cases

[11:51:58.0390] <Jeffrey Yasskin>
<rant>2/3 of the ideas in this space are just bad UI: confusing to users and difficult to use even when they're understood. Yes, the platform could support many of them, but it'd be better to try to focus on the ones that make pages easier to use.</rant>

[13:16:11.0232] <TabAtkins>
Luke Warlow: Right, on/off toggle button (aka a checkbox with a button UI) is a separate idea that really needs to be separated from this thread.

[13:16:43.0396] <TabAtkins>
But yeah, OpenUI discussion on what use-cases are most valuable to solve, and how, is probably going to be a lot more productive.


2024-04-17
[17:15:08.0746] <Luke Warlow>
Do we need a getHTML function on the document interface? We can parse to a document but can't currently serialise from one (not preserving shadow Dom anyway). You can call getHTML on the documentElement but that loses the html element in the output (because that's effectively innerHTML and we'd need outerHTML)

[17:17:52.0210] <Luke Warlow>
 * Do we need a getHTML function on the document interface? We can parse to a document but can't currently serialise from one (not preserving shadow Dom anyway). You can call getHTML on the documentElement but that loses the html element in the output (because that's effectively innerHTML and we'd need outerHTML). A getHTML on the document object itself could also serialise the compat mode back to the doctype? Which feels like it could be useful if you're trying to ensure lossless round tripping of parsing and serialisation?

[18:31:52.0178] <Domenic>
That issue just feels like an area where the community needs to go off and get a widely-used custom element (or React component, I'm not picky) before spending all this time in standards space...

[18:32:41.0234] <Domenic>
> <@lwarlow:igalia.com> Do we need a getHTML function on the document interface? We can parse to a document but can't currently serialise from one (not preserving shadow Dom anyway). You can call getHTML on the documentElement but that loses the html element in the output (because that's effectively innerHTML and we'd need outerHTML). A getHTML on the document object itself could also serialise the compat mode back to the doctype? Which feels like it could be useful if you're trying to ensure lossless round tripping of parsing and serialisation?

I would like that. Serializing the DOCTYPE in particular is nice. jsdom has its own serialization function just for that, because documentElement.outerHTML misses it.

[00:08:46.0198] <annevk>
It might be a little weird that `parseHTMLUnsafe()` is a static method then and not just `document.setHTMLUnsafe()`.

[00:10:06.0342] <annevk>
But I guess it's fine. Serializing the doctype seems good, but we should be opinionated about it and not support all inputs as-is.

[00:22:55.0916] <Luke Warlow>
> <@annevk:matrix.org> But I guess it's fine. Serializing the doctype seems good, but we should be opinionated about it and not support all inputs as-is.

Yeah okay maybe lossless was the wrong choice of word. I think the compatMode should serialise to the presence or lack of a standard Doctype

[00:24:47.0425] <Luke Warlow>
> <@annevk:matrix.org> It might be a little weird that `parseHTMLUnsafe()` is a static method then and not just `document.setHTMLUnsafe()`.

I guess that's fine though because it ensures the state of the document object is consistent when parsing?

[00:29:53.0781] <annevk>
Hmm, the state for non-document nodes is not. But in theory we could also add `setHTMLUnsafe()` to document if we ever wanted to parse without allocation. Prolly not worth it for the foreseeable future though.

[00:33:44.0794] <Luke Warlow>
I got thinking on this because if we had document getHTML, you could use trusted types and the sanitizer APIs to always safely set the srcdoc attribute on an iframe without needing any dependencies (unless there's some missing issues I've not thought of).

[00:35:00.0762] <Luke Warlow>
* I got thinking on this because if we had document getHTML, you could use trusted types and the sanitizer APIs to always safely set the srcdoc attribute on an iframe without needing any dependencies (unless there's some missing issues I've not thought of).

And also just because it does feel like a missing piece to the serialization puzzle.

[00:41:50.0874] <Domenic>
> <@lwarlow:igalia.com> Yeah okay maybe lossless was the wrong choice of word. I think the compatMode should serialise to the presence or lack of a standard Doctype

I don't think compatmode should impact it. It should be whether the Document has a DocumentType node. And then it should serialize according to https://html.spec.whatwg.org/#html-fragment-serialisation-algorithm .

[00:43:29.0441] <Luke Warlow>
> <@domenicdenicola:matrix.org> I don't think compatmode should impact it. It should be whether the Document has a DocumentType node. And then it should serialize according to https://html.spec.whatwg.org/#html-fragment-serialisation-algorithm .

I was thinking back to how we used to do it where I worked before but maybe we were doing it badly 😅

[00:44:15.0211] <Domenic>
Interesting that the parser preserves name, system ID, and public ID, but the serializer only keeps the name.

[00:45:28.0483] <Luke Warlow>
I'll open an issue on the html spec proposing this idea and we can discuss further the details there. Just wanted to guage if we thought it was any good or not.

[00:52:00.0092] <Domenic>
I can't find any way to trigger the HTML fragment serializing algorithm with a doctype, sad.

[00:53:29.0534] <Domenic>
I also either found a bug or am blind https://github.com/whatwg/dom/issues/1278

[00:54:18.0305] <freddy>
Huh, I learned there is `document.doctype` but it doesn't serialize to a doctype string?

[00:54:23.0671] <freddy>
(testing in Firefox)

[00:55:02.0548] <freddy>
I've used `document.body.parentElement.outerHTML` in the past, but you'd have to guess and attach the right doctype. Either way. I think there's value in a getter for the document.

[00:55:04.0289] <Domenic>
It doesn't have any serializing methods or properties

[01:39:13.0791] <Ms2ger>
Did we manage to remove the getters on doctype?

[01:57:33.0597] <freddy>
There were some? Well, then apparently...yes? :)

[02:16:22.0995] <annevk>
I guess I disagree with Domenic. I like the idea of serializing based on quirks mode a lot better. That way we either have no doctype, an almost doctype, or the doctype in the output.

[02:25:02.0544] <Luke Warlow>
I raised https://github.com/whatwg/html/issues/10280 

[02:26:31.0092] <freddy>
We also discussed this in our Sanitizer issue triage and thought that a `document.setHTML` might be neat, such that one could do `iframe.contentDocument.setHTML()` and without doing a parsing/serialization roundtrip between for that specific use case. https://github.com/WICG/sanitizer-api/issues/117#issuecomment-2060735167 has more.

[04:55:42.0106] <annevk>
freddy: note that it would require quite a number of downstream changes (none too hard I suspect) as we currently only consider possible element children

[07:42:52.0505] <Luke Warlow>
> <@domenicdenicola:matrix.org> It doesn't have any serializing methods or properties

`new XMLSerializer().serializeToString(document.doctype)` this will give you a string representation back

[07:49:23.0384] <Luke Warlow>
 * I got thinking on this because if we had document getHTML, you could use trusted types and the sanitizer APIs to always safely set the srcdoc attribute on an iframe without needing any dependencies (unless there's some missing issues I've not thought of).

mXSS is what I was missing.

And also just because it does feel like a missing piece to the serialization puzzle.

[07:55:04.0271] <Luke Warlow>
> <@domenicdenicola:matrix.org> It doesn't have any serializing methods or properties

 * `new XMLSerializer().serializeToString(document.doctype)` this will give you a string representation back. But to your point this obviously goes via XML serialisation rather than HTML.

[16:23:47.0596] <zcorpan>
Why did we use labels and not milestones for Stages?


2024-04-18
[17:29:20.0984] <Domenic>
> <@zcorpan:mozilla.org> Why did we use labels and not milestones for Stages?

Milestones are generally pretty inflexible in my experience. E.g. you are encouraged to give them dates, "close" them when they have no issues, things like that. It might work but it doesn't seem like what the system was defined for.

[17:33:18.0638] <zcorpan>
Domenic: ok, thanks. Yeah thinking about this again, milestones isn't a good match for Stages... Changing milestone for a single issue as it progresses isn't how you normally use milestones

[00:56:21.0482] <Andreu Botella>
Hey, it's 5 minutes before the WHATNOT meeting, right? I don't have a link to the call

[01:00:37.0763] <sideshowbarker>
Andreu Botella: https://meet.google.com/hfm-ttah-hfh

[01:01:09.0530] <sideshowbarker>
I think, at least — I am there now, but nobody else is…

Anyway, that’s the link I had in my calendar at least

[01:02:24.0687] <sideshowbarker>
Who usuall chairs the WHATNOT meetings in this time slot?

[01:02:28.0985] <sideshowbarker>
 * Who usually chairs the WHATNOT meetings in this time slot?

[01:02:56.0437] <Domenic>
Either me or Chris Wilson... I'm a bit late but I thought Chris RSVPed

[01:03:48.0156] <Domenic>
Be there in 2

[01:06:07.0250] <Andreu Botella>
I'm in the "asking to be let in" screen, btw

[04:33:58.0276] <annevk>
Noam Rosenthal: do you remember what https://fetch.spec.whatwg.org/#concept-request-replaces-client-id is? I don't really follow the note below. Because target browsing context is a field on an environment, so if that environment's target browsing context has an active document which is associated with an environment, isn't the same environment as you got the target browsing context from?

[04:35:08.0982] <annevk>
Also unclear if that's still correct in a world with navigables I suppose.

[04:38:41.0387] <Noam Rosenthal>
annevk: IIRC it’s for service workers, to let you keep track of a same origin nav. Afk but will double check in a bit

[04:39:40.0627] <annevk>
Noam Rosenthal: yeah that rings a bell. I have doubts this setup works as intended. It seems like we don't have to look at this for our new cookie work fortunately.

[05:41:06.0628] <Noam Rosenthal>
annevk: yea it's read at: https://w3c.github.io/ServiceWorker/#dom-fetchevent-replacesclientid


[05:42:15.0957] <Noam Rosenthal>
... and set https://html.spec.whatwg.org/multipage/browsing-the-web.html#create-navigation-params-by-fetching
The note can probably be updated to use the newer terms

[05:44:42.0562] <Noam Rosenthal>
... not sure what it means in terms of the new cookie work, I'm not familiar with it

[06:52:04.0143] <annevk>
Luke Warlow: for your node conversion PR, is it okay if I push to it, or would you prefer to continue with getting reviews?

[06:52:17.0586] <Luke Warlow>
That's absolutely fine

[06:52:43.0039] <Luke Warlow>
It's "done" as far as I'm concerned so if there's fix ups where I've misunderstood or done something wrong go ahead :)

[07:07:25.0655] <annevk>
Luke Warlow: when you have a moment please review my changes and leave a comment in the PR

[07:13:15.0882] <annevk>
Oh hmm, some more Oxford commas to add I just realized

[12:20:06.0696] <sefeng>
Noam Rosenthal: I think this is an editorial thing - It looks like the "items" for fetch param got batched into two separate groups https://fetch.spec.whatwg.org/#infrastructure and things like `To reporting timing...` got injected in between?

[12:20:46.0880] <sefeng>
oh sorry nvm, I misread


2024-04-19
[21:52:48.0079] <Eric Portis (he/him)>
zcorpan: Could I ask you for a review of https://github.com/WICG/responsive-image-client-hints/pull/33 ? Please ignore whether or not you think client hints and/or the responsive image client hints are a good idea, and – assuming they are – let me know if the way I'm integrating with HTML and the "parse a sizes attribute" algorithm makes sense..

[03:40:04.0051] <sideshowbarker>
zcorpan: (and/or others with insight) I’m trying to get a sense of the developer impact of https://github.com/whatwg/html/pull/7839 and https://github.com/w3c/csswg-drafts/pull/7224 and the related tests in https://wpt.fyi/results/css/css-ui/compute-kind-widget-generated — that is, what problems or developer pain points it fixes for developers, how important it is to developers

[03:48:38.0759] <zcorpan>
Eric Portis (he/him): I left a comment

[03:50:45.0704] <zcorpan>
sideshowbarker: https://docs.google.com/spreadsheets/d/1-EGzSxgFrGihArz0ZuZiZ2krrN_KhUYrSzdOhQi-zrI/edit#gid=1344512220&range=A1

[03:51:15.0375] <zcorpan>
sideshowbarker: e.g. "-webkit-appearance: none needed in iOS Safari" and "-webkit-appearance: none doesn't work on submit buttons in iOS Safari"

[03:54:56.0840] <sideshowbarker>
Love the name of that spreadsheet tab: **webdev pain points**

[03:56:21.0016] <zcorpan>
Yeah, it's a good way to improve a legacy feature, find out what the pain points are and then try to fix them

[06:38:21.0541] <annevk>
Form controls is I think one of the biggest complaints web developers have?

[07:07:54.0284] <Luke Warlow>
> <@zcorpan:mozilla.org> sideshowbarker: https://docs.google.com/spreadsheets/d/1-EGzSxgFrGihArz0ZuZiZ2krrN_KhUYrSzdOhQi-zrI/edit#gid=1344512220&range=A1

The one about height and width am I right in thinking "field-sizing: content" fixes that?


2024-04-22
[08:51:25.0373] <annevk>
Luke Warlow: I recommend doing a quick read through https://github.com/whatwg/dom/pull/1268/files as it seems to me it still contains changes you didn't mean to make

[08:51:40.0271] <Luke Warlow>
Yeah sorry I've just spotted those too

[08:51:44.0865] <Luke Warlow>
 * Yeah sorry I've just spotted those too, fixing now

[08:53:14.0169] <Luke Warlow>
Okay I think that's all done now. Apologies.


2024-04-23
[00:23:43.0939] <zcorpan>
> <@lwarlow:igalia.com> The one about height and width am I right in thinking "field-sizing: content" fixes that?

I think so

[00:25:04.0650] <zcorpan>
Still no solution to inline buttons afaik https://twitter.com/ned/status/1051798190951940096

[04:36:17.0365] <Luke Warlow>
Does anyone happen to know if the sanitizer API has a list of all event handler attribute names? Or is it piggy backing off some other mechanism?

[08:41:06.0153] <annevk>
Luke Warlow: that part isn't written down yet. They will prolly end up being part of a larger list of attributes in the end, but could be made reusable. However, they would not include event handler attributes of XMLHttpRequest and the like.

[08:42:36.0454] <Luke Warlow>
> <@annevk:matrix.org> Luke Warlow: that part isn't written down yet. They will prolly end up being part of a larger list of attributes in the end, but could be made reusable. However, they would not include event handler attributes of XMLHttpRequest and the like.

If they could be a separate list that's merged into the other than that would be useful. Trusted Types could piggy back of that list in that case?

[08:42:50.0042] <annevk>
This should probably be discussed with more people, but it doesn't seem unreasonable to me to blocklist all attributes starting with "on" for this purpose.

[08:44:31.0560] <Luke Warlow>
Interestingly that is how I had the spec originally (it's still implemented that way in WebKit for now). Where do you think is best to raise an issue? I think it makes sense to align TT and the sanitizer in this regard

[08:56:32.0417] <annevk>
Luke Warlow: I think it would make sense to raise an issue against the Sanitizer API suggesting that and then flag it for discussion during WHATNOT to see what people think as it would essentially enshrine the "on*" pattern. Both that we shouldn't use "on*" attributes for other things and that things that don't start with "on" should not be event handlers.

The small bit of complexity with the Sanitizer API is that it aims to standardize a safelist, but it will rely on "known attributes/elements" as well so there's a blocklist underneath, which might as well use "on*" for future proofing.

[09:06:25.0239] <Luke Warlow>
> <@annevk:matrix.org> Luke Warlow: I think it would make sense to raise an issue against the Sanitizer API suggesting that and then flag it for discussion during WHATNOT to see what people think as it would essentially enshrine the "on*" pattern. Both that we shouldn't use "on*" attributes for other things and that things that don't start with "on" should not be event handlers.
> 
> The small bit of complexity with the Sanitizer API is that it aims to standardize a safelist, but it will rely on "known attributes/elements" as well so there's a blocklist underneath, which might as well use "on*" for future proofing.

https://github.com/WICG/sanitizer-api/issues/226 - hopefully it's worded in a way that makes sense

[09:06:44.0654] <Luke Warlow>
 * https://github.com/WICG/sanitizer-api/issues/226 - hopefully it's worded in a way that makes sense, I'll link to it on the WHATNOT meeting issue


2024-04-24
[17:26:27.0244] <clean pest>
Hello

[00:55:36.0767] <Yoav Weiss>
Hey folks! I'd appreciate ideas as to why WATTSI is choking on me in the PR preview of https://github.com/whatwg/html/pull/10269 

[00:55:44.0407] <Yoav Weiss>
(doesn't happen locally)

[01:14:26.0277] <Luke Warlow>
> <@yoavweiss:matrix.org> Hey folks! I'd appreciate ideas as to why WATTSI is choking on me in the PR preview of https://github.com/whatwg/html/pull/10269

That error is normally due to mismatched start and end tags. But having said that the line it mentions is a `</ol>` and from a quick scan I don't see a dangling open `<ol>`

[01:31:07.0947] <annevk>
Yoav Weiss: "</p</li>" looks bogus

[01:31:45.0948] <annevk>
You're also removing some newlines which seems suspicious

[02:17:09.0397] <Yoav Weiss>
Thanks, looking!

[02:26:53.0754] <Yoav Weiss>
That was indeed the issue, thanks annevk !!


2024-04-25
[19:23:44.0446] <Domenic>
I'm just gonna merge https://github.com/whatwg/html-build/pull/291 . I was hoping to get more Rust reviewers but I think waiting is the wrong tradeoff.

[06:03:16.0700] <annevk>
I wonder if GitHub would benefit from having the equivalent of (Mozilla) Bugzilla's needinfo feature. There's quite a few threads where someone is asked a question and there's no answer. Presumably because the person asked got busy and has lost track of their notifications. And although needinfo can get problematic as well, it might improve a bunch of these cases?

[06:33:22.0707] <sideshowbarker>
I guess one imaginable way to hack around it in GitHub for now would be to add a label with the username of the needsinfo person. For some projects at least, the set of likely needsinfo people isn’t very large. and you could just create the labels as you need them.

[06:37:01.0753] <annevk>
sideshowbarker: I mean we can assign people and people can look up all the issues that have been assigned to them, but it's not quite the same.

[06:39:26.0400] <sideshowbarker>
hmm yeah I suppose the ability to assign people already kind of obviates the usefulness of using labels for it

[06:42:25.0720] <sideshowbarker>
I guess the reality is that for some people and some projects, they may be in an almost constant state of getting so many GH notifications that they have stopped being able to pay attention to them. And in those cases, you have to fall back to some other means of getting their attention when you really need it. Pinging on chat channels or DMing directly

[07:39:31.0954] <Dominic Farolino>
WHATWG working mode documentation has the definition of an "editor", but standards contain both "editors" and "authors". My understanding is it is generally accepted that the four HTML "authors" are all seen as "editors" of HTML though, is that right? https://github.com/whatwg/sg/blob/main/db.json#L214-L235

[07:40:39.0186] <Dominic Farolino>
Is it the case that all "authors" really have editor powers over the standard, but one of them is deemed "editor", and is responsible for answering for the whole standard overall?

[07:40:53.0962] <Dominic Farolino>
If there is a definition of "author" that I'm missing, let me know.

[07:41:40.0831] <Dominic Farolino>
 * WHATWG working mode documentation has the definition of an "editor" (https://whatwg.org/working-mode#editor), but standards contain both "editors" and "authors": https://github.com/whatwg/sg/blob/main/db.json#L214-L235. My understanding is it is generally accepted that the four HTML "authors" are all seen as "editors" of HTML though, is that right?

[07:41:55.0654] <Dominic Farolino>
 * Is it the case that all "authors" really have editor powers over the standard, but one of them is deemed the official "editor", and is responsible for answering for the whole standard overall?

[07:52:13.0830] <annevk>
Dominic Farolino: https://whatwg.org/workstream-policy Domenic is the Editor. Everyone else is a deputy editor, technically.

[07:52:32.0040] <annevk>
That's for the HTML Workstream, which includes the HTML and WebSockets Standards, iirc.

[07:53:36.0751] <annevk>
Although historically WHATWG editors were more like authors, today they are more like maintainers, maybe, although it varies a lot per standard and chapter within that standard.

[07:54:27.0564] <annevk>
(Clarifying all of this more might be worthwhile, but doing so in a consistent fashion would require studying a number of documents.)

[08:02:28.0614] <Dominic Farolino>
I see. I wonder if we could at least formalize the definition of "deputy editor" and its relationship with "author" in the db.json file, without too much extra study, since that's how things are behaving today already.

[08:05:06.0210] <Dominic Farolino>
At least I've heard a good bit of confusion internally about what "author" means in db.json, and questions around whether those people are editors or not. If authors in db.json are really deputy editors, that relationship could probably be cleared up relatively easily without too much archaeology. Do you agree Anne?

[09:04:06.0054] <annevk>
Dominic Farolino: that sounds reasonable. I guess I'd like to figure out why we went with "authors" there in the first place, but that should be straightforward.

[15:08:46.0457] <smaug>
keithamus: remind me - is there some magic to disable the behavior where github hides items/comments in issues?

[16:04:03.0001] <keithamus>
> <@smaug:mozilla.org> keithamus: remind me - is there some magic to disable the behavior where github hides items/comments in issues?

Sadly no. I think some people have built extensions to unfurl these but there’s no built in way. 

[16:27:35.0611] <bkardell>
Eric Meyer made a bookmarklet

[16:28:01.0308] <bkardell>
https://meyerweb.com/eric/thoughts/2024/02/05/bookmarklet-load-all-github-comments/

[16:28:14.0337] <bkardell>
smaug: ^


2024-04-26
[18:11:05.0041] <Domenic>
Dominic Farolino: annevk: I think my recollection is a bit different. Workstreams have editors which have some theoretical powers (which rarely, if ever, get exercised). For some policy-adjacent reason we thought it'd be best to stick to one editor per workstream, although there are a few exceptions. Standards have authors. In practice authors are the core contributors to the spec. Also in some cases people who have contributed significantly historically but not currently are listed as authors.

[21:08:47.0593] <Dominic Farolino>
Domenic: I see, so when we colloquially refer to someone being the editor of a standard, we really mean "author"? I imagine we rarely ever mean "Workstream Editor", because that role-specific duty is probably rarely relevant to casual conversation around the maintenance of standards, i.e., people who review and can click merge (as evidenced by your "have some theoretical powers (which rarely, if ever, get exercise)..."

[21:12:31.0333] <Dominic Farolino>
And where do deputy editors fit into this? Are those just the other Workstream Editors besides the first person listed there? Or are they the _authors_? It sounds like they are the authors, since deputy editor is a per-Standard thing, per https://whatwg.org/working-mode#standard at least.

[21:12:45.0387] <Domenic>
Yeah that's my understanding. Although re-reading the policy I guess workstream editors are theoretically the ones who are "authorized" to modify the spec. https://whatwg.org/workstream-policy#modifying-the-living-standard

[21:12:51.0515] <Dominic Farolino>
 * And where do deputy editors fit into this? Are those just the other Workstream Editors besides the first person listed there? Or are they the _authors_? It sounds like they are the authors, since deputy editor is a per-Standard thing, see https://whatwg.org/working-mode#standard at least) not a per-Workstream thing.

[21:13:10.0450] <Dominic Farolino>
And deputy editors that they delegate too I think

[21:13:17.0776] <Domenic>
So maybe biblio.json author == deputy editor

[21:13:26.0488] <Dominic Farolino>
I think that's right

[21:13:51.0112] <Dominic Farolino>
Or... db.json you mean?

[21:14:39.0115] <Domenic>
Yeah

[21:20:31.0022] <Dominic Farolino>
Filed https://github.com/whatwg/sg/issues/232

[21:21:11.0149] <Dominic Farolino>
I don't really know how the machinery of that repo works but I can take a look tomorrow maybe if nobody gets to it first.

[00:36:52.0208] <annevk>
Dominic Farolino: the main thing you'll have to do is to look at whatwg/whatwg.org's Python scripts to see if they need the same change; there's probably something there that has "authors" in it

[01:33:33.0219] <iamfernando>
Greetings!

[01:33:57.0545] <iamfernando>
I saw a "This list can be changed. If there are schemes that ought to be added, please send feedback." and was wondering where should I send the feedback?

[01:35:14.0682] <iamfernando>
more specifically about https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers 

[02:05:14.0400] <iamfernando>
Could we have handlers for nostr?

[02:58:13.0357] <sideshowbarker>
About expected behavior for `document.execCommand("Paste")` with `contentEditable` elements: Looking at text expectations in https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L106, I’m trying to figure out why in the `contentEditable`, the expectation for the result of the paste is the empty string (rather than the source/input string being pasted).

…whereas in the case of the `textarea` element and `input` element, the expectation is that the source/input string does get pasted as expected.

[02:58:28.0028] <sideshowbarker>
 * About expected behavior for `document.execCommand("Paste")` with `contentEditable` elements: Looking at test expectations in https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L106, I’m trying to figure out why in the `contentEditable`, the expectation for the result of the paste is the empty string (rather than the source/input string being pasted).

…whereas in the case of the `textarea` element and `input` element, the expectation is that the source/input string does get pasted as expected.

[02:58:38.0038] <sideshowbarker>
 * About expected behavior for `document.execCommand("Paste")` with `contentEditable` elements: Looking at test expectations in https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L106, I’m trying to figure out why in the `contentEditable` case, the expectation for the result of the paste is the empty string (rather than the source/input string being pasted).

…whereas in the case of the `textarea` element and `input` element, the expectation is that the source/input string does get pasted as expected.

[03:06:12.0396] <sideshowbarker>
zcorpan: about the test at https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L25, calling `preventDefault()`with a `textInput` event for a `document.execCommand("Paste")` operation should not actually case the paste operation to fail, right?

[03:07:05.0851] <sideshowbarker>
 * zcorpan: about the test at https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L25, calling `preventDefault()`with a `textInput` event for a `document.execCommand("Paste")` operation should not actually cause the paste operation to fail, right?


2024-04-27
[04:51:48.0612] <zcorpan>
sideshowbarker: what happens in browsers?


2024-04-29
[01:13:41.0090] <annevk>
r? https://github.com/whatwg/whatwg.org/pull/440 & https://github.com/whatwg/whatwg.org/pull/441

[01:41:39.0689] <annevk>
krosylight: I think you can go ahead with https://github.com/whatwg/sg/issues/231 given that Tantek is presumably aware and okay with this?

[04:19:31.0941] <Jake Archibald>
Is there any guidance on when events should bubble? (for making platform-consistent events)

[04:28:14.0566] <annevk>
Jake Archibald: not that I know of. One consideration would be whether you want onX on a parent to get invoked.

[04:32:52.0820] <Jake Archibald>
annevk: yeah. I guess bubbling makes sense for 'click', since parent elements were also clicked. Whereas with the `img` `load` event, it's the image that loaded, none of the parents did.

[04:32:55.0771] <Jake Archibald>
cheers!

[04:48:59.0421] <sideshowbarker>
> <@zcorpan:mozilla.org> sideshowbarker: what happens in browsers?

I ended up rewriting the tests to remove the part that attempts to test “cancellation” of an edit operation — because as far as I can see, there is nothing in the spec to support that calling _any_ event’s `preventDefault()` should cause any edit operation to be cancelled. And I couldn’t find that there was any way at all to cancel an edit operation.

And anyway, the test as written had not even been calling the edit operations themselves, but was instead just firing a `textInput` event with a particular input type, and relying on the fact that the implementation happened to be written to expect to get all the necessary data from that event.

The implementation of the `textInput` event had other properties beyond just what’s in the IDL and required by the spec. So the implementation had sort of just been using the event as a convenience to hang those other properties on. And that worked OK as long as the `textInput` event got fired prior to `beforeinput` — but not if the firing order of those events were changed.

But the event-firing order needed changing.

So I rewrote it all such that the code now instead passes on the actual data directly, and only puts what’s actually necessary into the `textInput` event (when it eventually gets fired later).

[06:31:24.0647] <zcorpan>
Jake Archibald: events fired on document generally bubble. UI events generally bubble, but not always (e.g. `scroll` on an element doesn't bubble)

[06:32:46.0425] <Jake Archibald>
zcorpan: It feels like that fits with what I said before. You're not scrolling parent elements, you're just scrolling that one element, so bubbling doesn't fit

[06:39:35.0568] <annevk>
Jake Archibald: you'll also have to consider if it gets retargeted on a shadow host, which is generally yes for UI events

[07:34:01.0205] <zcorpan>
Jake Archibald: yep, but then `form` `submit` bubbles, which doesn't seem to fit in. Also `formdata`, `change`, `reset`

[07:35:07.0433] <Jake Archibald>
zcorpan: hm, yeah. Are those seen as a historical mistake? Or is there just no real consistency?

[07:40:29.0950] <TabAtkins>
(I think most events should default to bubbling for ease of use, personally.)

[07:40:49.0180] <TabAtkins>
Every time I write a focus handler I have to cuss it for not working until I remember I have to capture it

[07:56:48.0216] <annevk>
Jake Archibald: in all my many years working in this space, I don't think anyone has ever articulated a coherent story around it

[07:57:07.0434] <annevk>
Jake Archibald: smaug or peterv might know one though

[07:59:46.0182] <smaug>
In some sense events which are expected to be used on the target itself shouldn't bubble. But yeah, it is all very inconsistent.

[09:50:26.0259] <annevk>
I wish more platforms had a nod reaction. At least to me that's quite different from thumbs up / +1 and nice to express.

[09:51:09.0944] <Domenic>
I can't remember why bubbling is even necessary, given that capturing exists...

[09:53:37.0555] <annevk>
In theory it's for post-target actions. And capture is for pre-target actions. It might have been interesting if where an event flows was entirely a function of listeners and not dispatch. (There was a semi-serious proposal for that at one point that I made, but it didn't gain traction.)

[09:55:11.0160] <annevk>
It's still up: https://github.com/whatwg/dom/issues/215

[13:48:05.0647] <smaug>
There used to be also the concept of event groups https://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Event-groups

[13:51:14.0663] <smaug>
from which Gecko get the concept of default and system groups. System group event listeners are in some cases used to implement activation behavior. (But system group gets its separate event phases after default group - so it is a bit different to the old event groups)

[13:51:31.0636] <smaug>
 * from which Gecko got the concept of default and system groups. System group event listeners are in some cases used to implement activation behavior. (But system group gets its separate event phases after default group - so it is a bit different to the old event groups)


2024-04-30
[22:03:27.0945] <dubzer>
haiii. is this step missing an explicit return statement? since state machine would not move after it

[22:06:55.0503] <dubzer>
oh, sorry, it'll just check the next character with the same state 

[00:19:45.0107] <hsivonen>
Are there general principles for how the `input` element is meant to behave in terms of user-entered values, `.value` values, and submitted values? Notably, the spec text for `email` very much goes in the direction of non-Punycode forms of the domain being an UI presentation issue only. Dates and times clearly are supposed to submit in the ISO format. Yet, `url` seems to submit what the user entered instead of submitting serialization after URL parsing.

[00:29:28.0957] <annevk>
hsivonen: I think the more we can move towards submitting and exposing (to script) a normalized form, the better

[00:33:51.0184] <hsivonen>
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12675

[00:34:54.0095] <hsivonen>
Looks like in Chrome setting email value via JS doesn't immediately normalize the value, but attempting to submit still catches a prohibited value.

[00:35:46.0323] <hsivonen>
smaug: ^

[00:37:32.0086] <hsivonen>
When editing email manually (not via JS), if the entered value is failing constraint validation, the `.value` is unnormalized. If the value passes constraint validation, the `.value` is normalized.

[00:37:35.0784] <hsivonen>
in Chrome that is.

[00:40:31.0945] <hsivonen>
Sigh. Chrome uses UTS 46 transitional=true for `input type=email` despite using transitional=false for URL handling.

[00:40:44.0945] <hsivonen>
Bugs. Bugs everywhere.

[00:43:59.0878] <annevk>
Yeah, I wouldn't want to enshrine what is shipped today and I think we have some room for changes here.

[01:40:46.0511] <hsivonen>
I tried to be as brief as I could while still covering all the points, and I still ended up with a megacomment: https://github.com/whatwg/html/issues/4562#issuecomment-2084725431

[01:41:42.0776] <hsivonen>
(I think we need to list the questions that need answering, because without specific questions that issue doesn't appear to be converging.)

[04:43:32.0098] <annevk>
Thanks for writing that Henri. Hopefully you're more successful in getting people to make constructive comments in that issue.

[16:05:31.0999] <christianmx>
Hi! Is there an official site for the latest updates of the HTML standard? Or how do I find out the latest changes that are being included in the HTML living standard? Please don't tell me to read GitHub commits because it's not a good idea. I'm looking for a site that tells me something like this: "24/4: the following changes were added..." Thanks

[16:10:07.0693] <TabAtkins>
> <@christianmx:matrix.org> Hi! Is there an official site for the latest updates of the HTML standard? Or how do I find out the latest changes that are being included in the HTML living standard? Please don't tell me to read GitHub commits because it's not a good idea. I'm looking for a site that tells me something like this: "24/4: the following changes were added..." Thanks

There used to be a "Last Week in HTML..." blog post series, but that stopped being maintained years ago. Nowadays reading the commit history is indeed the only way to track things.

[16:13:34.0075] <bkardell>
Do you want specifically that or are you looking for what's new to the web platform more generally, and maybe even specifically has multiple implementations?

[16:18:47.0522] <christianmx>
> <@bkardell:igalia.com> Do you want specifically that or are you looking for what's new to the web platform more generally, and maybe even specifically has multiple implementations?

I'm looking for that: some site that shows the latest changes added to the living standard

[16:19:11.0719] <TabAtkins>
Well wait, what bkardell just described is very different from what you just described.

[16:19:34.0605] <TabAtkins>
"Latest changes to the specs" and "new things in browsers, perhaps with multiple impls" can be distinct by quite a large amount of time

[16:20:40.0577] <bkardell>
In some rare cases things will leave the HTML standard after a long long time of failing to get that even

[16:21:04.0641] <bkardell>
The process should now prevent that but, it still can happen

[16:23:57.0560] <christianmx>
> <@tabatkins:matrix.org> Well wait, what bkardell just described is very different from what you just described.

You're right, sorry for my confusion, it's "Latest changes to the specs"

[16:25:30.0256] <bkardell>
And your looking for like.. the evening news version that summarizes that for in prose and not just some diffs or something?

[16:25:39.0439] <bkardell>
* And you're looking for like.. the evening news version that summarizes that for in prose and not just some diffs or something?

[16:31:26.0457] <christianmx>
Yes, and if it does not exist, then some help to read the GitHub commits that tells me what were the last changes added to the standard, avoiding commits that belong to bugs or other things

[16:31:44.0534] <christianmx>
 * Yes, and if it doesn't exist, then some help to read the GitHub commits that tells me what were the last changes added to the standard, avoiding commits that belong to bugs or other things

[16:39:59.0482] <bkardell>
Hmmm yeah I'm not aware of anything like that. I know Rachel Andrew has been doing a nice monthly recap for devs at web.dev but it's wider than the HTML standard. It also gets mixed a little with chrome stuff that's somewhat unfortunate, but it's very good for keeping up. There are a few newsletters like that too. I've been developing a thing with Eric Meyer: that's not that either but of similar use - but it summarizes some things in bcd which is also wider than the html spec 

[16:41:04.0459] <bkardell>
I think specifically what you're looking for, asTabAtkins I'm not sure exists anywhere at the moment

[16:41:16.0909] <bkardell>
* I think specifically what you're looking for, as
TabAtkins said I'm not sure exists anywhere at the moment

[16:43:43.0352] <christianmx>
> <@bkardell:igalia.com> Hmmm yeah I'm not aware of anything like that. I know Rachel Andrew has been doing a nice monthly recap for devs at web.dev but it's wider than the HTML standard. It also gets mixed a little with chrome stuff that's somewhat unfortunate, but it's very good for keeping up. There are a few newsletters like that too. I've been developing a thing with Eric Meyer: that's not that either but of similar use - but it summarizes some things in bcd which is also wider than the html spec

Ok, thank you for the info, I'll look that

[16:46:03.0745] <christianmx>
Returning to GitHub commits: are the latest changes added to the standard that appear on Github only those that say Upstream? Or should I see other commits?

[16:49:14.0319] <bkardell>
Idk if it were me i would probably follow things merged in the last week in PRs https://github.com/whatwg/html/pulls?q=is%3Apr+is%3Aclosed

[16:49:53.0162] <bkardell>
That'll be a relatively small list and there's previews generated which highlight the diffs

[16:51:30.0492] <bkardell>
Unless for some reason you want the stuff that is being worked on actively, rather than what's actually made it into the spec, or you care about individual commits (a pr can have tons of commits before it's merged)