2024-10-01
[23:15:42.0759] <annevk>
Domenic: https://github.com/whatwg/html/commit/65ef915fbfa347928d5ab946cc5df372c44262cd is missing a comma

[23:15:58.0398] <Domenic>
Oops :(

[23:18:03.0914] <annevk>
Domenic: if you're editing, https://github.com/whatwg/html/commit/5db3fd041f6afd0d6c73f0e4bba21360b59b9267 did indentation incorrectly

[23:19:59.0626] <Domenic>
Sigh, my bad...

[15:05:25.0651] <TabAtkins>
Hm, question. If I were to define a new URL format, similar in principle to data: urls but for generating a specific type of image (QR codes, in this case), would I still want to lean on the "opaque origin" concepts that data: urls use? Or is that overkill and I could rely on something simpler since it's just a raster image?


2024-10-02
[23:10:12.0201] <annevk>
Domenic: what prevents you from having a scripting relationship with a bfcache'd document? I guess there's some unspecified(?) magic that might kick it out of bfcache, but you can hold a reference just fine right?

[23:11:11.0241] <Domenic>
annevk: right, I guess it's the fact that no browser bfcaches iframes or windows with openers. (Not a matter of kicking you out; they just never get bfcached in the first place.) Allowing that would probably break tons of specs that are not prepared for it. We offered to add this to the spec in the past but I think there wasn't appetite.

[23:11:57.0385] <annevk>
Domenic: you don't need an opener to hold a reference to a nested document though

[23:12:33.0740] <Domenic>
No browser bfcaches iframes

[23:13:44.0817] <annevk>
Oh, that's new to me

[23:13:56.0939] <Domenic>
So much stuff would break

[23:14:55.0946] <annevk>
TabAtkins: why would you define them as a new URL scheme and not a particular MIME type?

[03:00:31.0644] <Luke Warlow>
Stuff like the otpauth (/apple-otpauth) scheme can already be used for generating a specific type of qr code. In case of otpauth it's a scheme so it can be used in links. I guess the design might depend on whether it makes sense to linkify this new type of data? Is that the sort of thing you were after Tab? is it something more generic?

[04:23:26.0896] <annevk>
Panos Astithas: maybe we should cancel WHATNOT tomorrow. It's a German holiday and currently only Mu-An Chiou @muan, Domenic, and you are confirmed. We also just had TPAC.

[05:45:41.0170] <annevk>
I wonder if https://x.com/Mike_DiDomizio/status/1839692898670879128 is the direct result of encoding the state in an attribute or if there would be some way to avoid this. I guess the only way would be some kind of parser hack?

[05:51:31.0113] <Luke Warlow>
> <@annevk:matrix.org> I wonder if https://x.com/Mike_DiDomizio/status/1839692898670879128 is the direct result of encoding the state in an attribute or if there would be some way to avoid this. I guess the only way would be some kind of parser hack?

Could potentially only fire the event if there's been user activation on the page? But I guess that only helps on first load not subsequently parsed details 

[06:21:48.0356] <Domenic>
I mean we could thread through "did the parser set this" to the attribute changed steps. It'd just be a lot of annoying work for unclear gain.

[06:23:37.0811] <Domenic>
A new MIME type is more elegant than a new URL scheme but it does come with extra baggage. E.g. you'd expect that if the server served an image/qr-code file then that would also work, which maybe is not what Tab is going for. Unsure.

[07:57:45.0537] <Panos Astithas>
Agreed, I will cancel it.

[08:12:12.0370] <annevk>
A new URL scheme also comes with a lot of baggage though. Is it local, when is it same origin, what if you navigate to it, etc. But yeah, I guess it depends a bit on what you want.

[08:52:19.0416] <keithamus>
I noticed someone tweeting about a pain point of custom elements; https://x.com/Rich_Harris/status/1841494391346590072. In which they point out `cloneNode()` clones the element with the `synchronous custom elements flag unset`. 

I know this was raised before in https://github.com/whatwg/dom/issues/922 where annevk said:

> We don't want to execute JavaScript during those operations as that leads to all kinds of complexity. I'm going to close this as this is working-as-designed.

While I obviously respect that position I'm wondering if there's any possibility of movement on this? It seems unfortunate that this is the only place where elements can be created without a definition, but I guess this would mean a performance hit regardless? 

[09:01:31.0479] <Ms2ger>
Probably not just perf, but masses of CVEs

[09:16:34.0838] <annevk>
keithamus: I actually forgot how cloning works. Is the main issue that it does not happen synchronously or that you do not get any information at all? CER timing could maybe allow for something here, but I don't actually know what we have today. I'm also surprised there hasn't been more noise about this since 2020, but Rich Harris usually knows what's up so it's worth looking into I think.

[09:17:45.0215] <Luke Warlow>
> <@keithamus:matrix.org> I noticed someone tweeting about a pain point of custom elements; https://x.com/Rich_Harris/status/1841494391346590072. In which they point out `cloneNode()` clones the element with the `synchronous custom elements flag unset`. 
> 
> I know this was raised before in https://github.com/whatwg/dom/issues/922 where annevk said:
> 
> > We don't want to execute JavaScript during those operations as that leads to all kinds of complexity. I'm going to close this as this is working-as-designed.
> 
> While I obviously respect that position I'm wondering if there's any possibility of movement on this? It seems unfortunate that this is the only place where elements can be created without a definition, but I guess this would mean a performance hit regardless? 

The perhaps more interesting bit to me is the alternative being so much slower?

[09:18:18.0406] <keithamus>
I was wondering if we could do something with CEReactions. The main issue is that cloneNode won't construct custom elements until they're connecting which is somewhat incongruent with the rest of the platform (importNode retains the definition for example)

[09:18:30.0043] <keithamus>
I imagine importNode is slower because it steps into scripting?

[09:19:46.0450] <keithamus>
`cloneNode` is the only method which calls `creating an element` with `synchronous custom elements flag unset AFAICT.

[09:19:54.0334] <keithamus>
 * `cloneNode` is the only method which calls `creating an element` with `synchronous custom elements flag unset` AFAICT.

[09:20:27.0879] <annevk>
Hmm, `importNode()` and `cloneNode()` are almost identical underneath. If they have serious perf differences that should be fixable.

[09:22:16.0411] <keithamus>
Yes I wonder if we should test the perf disparity claims. The vibe I get from this post was that it was a while ago and maybe that no longer holds true?

[09:23:12.0266] <annevk>
Also, "creating an element" is invoked with that flag unset from the HTML parser at times I think. HTML calls it and that flag value is a variable.

[09:23:29.0086] <keithamus>
ah apologies I missed that

[09:24:38.0622] <keithamus>
oh yeah so https://html.spec.whatwg.org/#create-an-element-for-the-token also explicitly calls out the flag which is sometimes set.

[16:37:34.0767] <TabAtkins>
> <@domenicdenicola:matrix.org> A new MIME type is more elegant than a new URL scheme but it does come with extra baggage. E.g. you'd expect that if the server served an image/qr-code file then that would also work, which maybe is not what Tab is going for. Unsure.

Yeah, y'all are right, just having a new mime type is probably the best way to go. My use-case is just to make it possible to hand-author QR codes easily, given that QRs "won" the barcode wars. They don't need to be linkable or anything, just "fetchable", and a data: URL works for that.

[16:39:44.0051] <TabAtkins>
And the ability for a server to *return* a QR code image using this MIME type wasn't in my initial use-cases, but does seem reasonable imo; the server could generate an appropriate response from cookie data, for instance, and not have to go to the effort (and additional bandwidth) of actually *generating* the QR code as a PNG or something and returning that. Seems useful.


2024-10-03
[05:58:40.0858] <zcorpan>
TabAtkins: will you use a sniffable signature at the start of the body?

[07:02:21.0967] <TabAtkins>
I'd considered it, like starting the body with QRCODE. It means a little bit more boilerplate for hand authoring, tho. Is it really recommended?

[09:35:08.0705] <zcorpan>
TabAtkins: I don't know if there's a recommendation, though images are usually sniffed so I think it could make the format more robust


2024-10-04
[18:38:36.0231] <Domenic>
We'd like to move away from sniffing, and have tried to require new formats to not be sniffed, but implementations have not agreed. I believe their objections have been non-technical ("why should my format be slightly harder to adopt than all the old formats?") but maybe there are technical reasons too.

[00:21:00.0204] <annevk>
For SVG implementations already check the MIME type I believe so introducing another such MIME type seems good.

[00:47:55.0780] <annevk>
keithamus: could you give feedback somewhere that I'd love to enable the two-factor authentication requirement for WHATWG if only it gave the option to give everyone impacted a two weeks heads up? It seems like the current checkbox will just kick everyone out which at this point might well be acceptable given the limited number of people impacted, but it still seems preferable to give everyone a bit of wiggle room. (This lack of clarity around how the requirement is communicated has already delayed our adoption by two years or so.)

[01:28:34.0698] <keithamus>
Thanks, I'll pass it on to the team responsible for 2fa enforcement

[02:34:37.0299] <annevk>
Adam Rice: I revived and cleaned up https://github.com/whatwg/encoding/pull/309 as it still seems worth doing

[02:40:07.0354] <annevk>
Yagiz N: what does https://x.com/yagiznizipli/status/1841855393481302338 mean?

[04:18:16.0636] <Yoav Weiss>
Hey folks! Question about URLs.
If I'm [parsing](https://url.spec.whatwg.org/#concept-url-parser) "https://example.com/foo//bar", I wouldn't expect it to be identical to a parsed "https://example.com/foo/bar", right?

[04:20:17.0632] <Adam Rice>
I don't know what you'd expect, but https://www.ada-url.com/playground?url=https%3A%2F%2Fexample.com%2Ffoo%2F%2Fbar says they are different.

[04:21:10.0018] <Yoav Weiss>
yeah, that's what I figured

[04:21:44.0486] <Yoav Weiss>
for some reason I thought the URL parser would remove spurious '/' in the path, but I was wrong

[04:23:34.0251] <Yoav Weiss>
yeah, the spurious slashes even go out on the network

[04:23:44.0347] <Yoav Weiss>
I guess it's on the server to dedup them

[04:50:30.0992] <annevk>
Yoav Weiss: we only ignore infinite slashes after special URL schemes (and a colon), to much chagrin of the curl maintainer

[07:05:44.0765] <mikedidomizio>
Hey group,

Has there at any time been examples of a feature released in browsers where the decision on behaviour has been revisited and revised?

I'm wondering the process behind how that works?
This is all related to the `<design>` element and the `ontoggle` event paired with `open` attribute and how it automatically fires.

In this [GitHub issue](https://github.com/whatwg/html/issues/4500) there was some discussion around if people would misunderstand how it's used, and if it should be changed.

This all stemmed from my current place of employment recognizing a bug in our code, that fortunately wasn't too bad, but nonetheless a bug due to our misunderstanding of the behaviour.  We went ahead and decided to use React to build a layer on top to change the behaviour, replaced current implementations, and forbid all future usages of `<details>` (via ESLint).

So far every person I've explained this current behaviour to gave me the same response in that it behaves differently than they would expect.
I think a part of me worries that leaving it as is means an eternity of devs bug fixing, simply because something behaves differently than most would expect.

So to close this out, I think helping me understand the process, previous examples, and other statistics you would use to make a decision, would help me understand if it's worth to continue to pursue this or not.  

I'm hoping I'm not coming off as a nuisance.  It's not my intention, I'm focused on respecting developers' time and reducing the likelihood of future bugs.

[07:47:01.0371] <annevk>
r? https://github.com/whatwg/meta/pull/332

[07:50:33.0382] <annevk>
We did briefly discuss your xweet on Wednesday and special casing the parser case would actually be quite a bit of work.

I think to me it does signify that tracking state through an attribute was a mistake, but changing it for this existing element would be quite the undertaking.

[08:41:27.0436] <mikedidomizio>
Thanks annevk .  I appreciate you guys taking the time to discuss it further.  I assume it's not an easy decision.  I'm just learning that the WHATNOT meetings are open to the public (I think), and I see transcripts inside the GitHub issues.  Can someone link me the discussion on this?

More so out of curiosity. A lot of what you guys do intrigues me.

[10:19:40.0312] <TabAtkins>
Does anyone have any memory of why the specific list of codepoints were allowed in custom element names? <https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name> The list excludes emoji like ✨, but allows others, so I'm a little confused by it.

[10:21:40.0402] <TabAtkins>
(For example, `a-🥔` is a valid custom element name, but `a-✨` isn't.)

[10:23:28.0712] <TabAtkins>
This is relevant to CSS, because the Syntax spec just copied HTML's set of allowed characters, but that means `--✨` is an invalid custom property name. We at least want to be a *superset* of HTML's allowed characters, so authors don't have to use escapes to write selectors targeting their custom elements; I'm just checking if there's a good reason for this *exact* set of restrictions, or if I can relax CSS a bit.


2024-10-05
[18:47:59.0177] <joshua.shaw>
Hello guys !!!!! ,…….WE POST ALL PRODUCTS AND REVIEWS ON OUR MAIN CHANNEL AND GROUP. WE WON'T BE POSTING ANY PRODUCTS ON THIS CHANNEL.MAIN GROUP AND CHANNEL LINKS BELOW ⬇⬇⬇

SUBSCRIBE HERE CHANNEL :           https://t.me/+ioqje81ziAYyYTc0 https://t.me/+ioqje81ziAYyYTc0 https://t.me/+ioqje81ziAYyYTc0 https://t.me/+ioqje81ziAYyYTc0 https://t.me/+ioqje81ziAYyYTc0

1) ( GBP DOLLARS, EURO), PROP NOTES, WHITE CARDS, PAYPAL TRANSFER 

2) ✅Cloned Card 

3)✅Cashapp

4)✅Apple Pay

5)✅ PayPal 

6)✅Venmo 

7)✅Test run 

8)✅Linkable  

9)✅CC’s drop  

JOIN OUR MAIN TELEGRAM CHANNEL NOW

[00:54:17.0095] <Domenic>
(For the record, Anne answered Tab's question at https://github.com/w3c/csswg-drafts/issues/11005#issuecomment-2394293590 )

[09:46:54.0553] <annevk>
It wasn't discussed in WHATNOT. It was discussed in this channel, but only two messages or so.

[13:38:23.0807] <Jay Madden>
Hello, I am working on fixing some wpt tests for ladybird and am working on the following suite http://wpt.live/html/semantics/interactive-elements/the-details-element/toggleEvent.html

I have run into an issue on the last test however. For the following code 

```
<input id="clickMe" type="button" value="clickme" onclick="doFunction();" />
<script>
function doFunction() {
    new DOMParser().parseFromString("<h1><details open></h1>", "text/html").querySelector("details").ontoggle = function(e) {
      console.log(e.target.open);
    };
}
</script>``` Chrome will send the event even tho. from reading the spec on navigables that document should never be marked as true https://html.spec.whatwg.org/multipage/document-sequences.html#node-navigable

So basically my question is, why do documents parsed with DOMParser() trigger events?

[13:38:31.0539] <Jay Madden>
 * Hello, I am working on fixing some wpt tests for ladybird and am working on the following suite http://wpt.live/html/semantics/interactive-elements/the-details-element/toggleEvent.html

I have run into an issue on the last test however. For the following code

````
<input id="clickMe" type="button" value="clickme" onclick="doFunction();" />
<script>
function doFunction() {
    new DOMParser().parseFromString("<h1><details open></h1>", "text/html").querySelector("details").ontoggle = function(e) {
      console.log(e.target.open);
    };
}
</script>
``` 
Chrome will send the event even tho. from reading the spec on navigables that document should never be marked as true https://html.spec.whatwg.org/multipage/document-sequences.html#node-navigable

So basically my question is, why do documents parsed with DOMParser() trigger events?
````

[13:38:38.0462] <Jay Madden>
 * Hello, I am working on fixing some wpt tests for ladybird and am working on the following suite http://wpt.live/html/semantics/interactive-elements/the-details-element/toggleEvent.html

I have run into an issue on the last test however. For the following code

```
<input id="clickMe" type="button" value="clickme" onclick="doFunction();" />
<script>
function doFunction() {
    new DOMParser().parseFromString("<h1><details open></h1>", "text/html").querySelector("details").ontoggle = function(e) {
      console.log(e.target.open);
    };
}
</script>
``` 
Chrome will send the event even tho. from reading the spec on navigables that document should never be marked as true https://html.spec.whatwg.org/multipage/document-sequences.html#node-navigable

So basically my question is, why do documents parsed with DOMParser() trigger events?
````

[13:40:55.0556] <Jay Madden>
 * Hello, I am working on fixing some wpt tests for ladybird and am working on the following suite http://wpt.live/html/semantics/interactive-elements/the-details-element/toggleEvent.html

I have run into an issue on the last test however. For the following code

```
<input id="clickMe" type="button" value="clickme" onclick="doFunction();" />
<script>
function doFunction() {
    new DOMParser().parseFromString("<h1><details open></h1>", "text/html").querySelector("details").ontoggle = function(e) {
      console.log(e.target.open);
    };
}
</script>
```

Chrome will send the event even tho. from reading the spec on navigables that document should never be marked as true https://html.spec.whatwg.org/multipage/document-sequences.html#node-navigable

Which means the tasks from that DOM should never be runnable right? https://html.spec.whatwg.org/#concept-task-runnable

So basically my question is, why do documents parsed with DOMParser() trigger events?


2024-10-06
[23:32:20.0480] <annevk>
This used to fire an event just fine: https://github.com/whatwg/html/issues/4500. This seems like a potential regression from the introduction of navigables.

[23:32:41.0024] <annevk>
Please file an issue? Thanks for finding it!

[23:34:07.0212] <annevk>
Grmbl, Hacktoberfest is back: https://github.com/whatwg/html/issues/10679

[08:14:23.0603] <Jay Madden>
annevk it does fire the event, thats what i was confused about, where in the spec that would happen.

What i figured out yesterday from more reading was that the element task for the event SHOULD fire the event because the associated global document is null due to it it not being attached to a window. So the task is marked runnable

[08:57:15.0921] <Oluwafemi Franchis>
Hello guys 🥰🥰 I wanted to let you know that I have a Telegram channel where I share some amazing Verified sauce and soft cashout
Here are some of the things you can find on my channel 💯💯💯

I promise you that all the methods are real and legit. No scams here! And please don't worry about how much money you have. Just be honest and I'll try my best to help you out.
So, if you're interested, please join my channel through the link below. See you there ✅✅

🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇
💸💸💸💸

https://t.me/+oGahmYblRPU4NjE0

[09:01:07.0498] <Oluwafemi Franchis>
Hello guys 🥰🥰 I wanted to let you know that I have a Telegram channel where I share some amazing Verified sauce and soft cashout
Here are some of the things you can find on my channel 💯💯💯

I promise you that all the methods are real and legit. No scams here! And please don't worry about how much money you have. Just be honest and I'll try my best to help you out.
So, if you're interested, please join my channel through the link below. See you there ✅✅

🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇
💸💸💸💸

https://t.me/+oGahmYblRPU4NjE0

[09:52:43.0076] <nicolo-ribaudo>
We should have a bot that auto-bans whoever mentions Telegram

[09:53:07.0025] <Colin Alworth>
User was banned for this message


2024-10-07
[23:16:43.0680] <annevk>
Okay, so there's no issue?

[01:11:57.0227] <annevk>
smaug: final call for Mozilla input on https://github.com/whatwg/html/pull/10394. If you want to take a look please let me know by how many days I should delay landing it

[01:13:36.0798] <annevk>
(Same for everyone else seeing that message and wanting to review I suppose, but Olli did weigh in previously.)

[01:22:02.0951] <annevk>
Yoav Weiss: ^^

[01:36:57.0702] <annevk>
Luke Warlow: I think you're correct about the `<input type=color>` issue. I guess either we need to instrument serialization even more or we need to direct the user agent to only use the `color()` function in either srgb or display-p3 fashion. But that would not prevent web developers from writing into `value` themselves at which point it depends on what color space conversion ends up doing...

[01:54:51.0540] <Luke Warlow>
> <@annevk:matrix.org> Luke Warlow: I think you're correct about the `<input type=color>` issue. I guess either we need to instrument serialization even more or we need to direct the user agent to only use the `color()` function in either srgb or display-p3 fashion. But that would not prevent web developers from writing into `value` themselves at which point it depends on what color space conversion ends up doing...

I reckon we should update the the CSS spec to have a way to call into that serialisation specifically?

[01:56:51.0317] <annevk>
Yeah, agreed, that would give the most consistent results. I'll open an issue. Though I should also see what primitives existing implementations have on offer maybe. Don't want to add too many novel concepts. Hopefully Sam Weinig can double check that.

[02:50:27.0717] <annevk>
smaug: https://github.com/whatwg/html/pull/10528 also looks pretty close. WebKit hasn't determined a position yet, but I'm checking on that now. Leaning positive myself.

[02:50:52.0821] <annevk>
Yoav Weiss: maybe file the MDN issue so that's out of the way for that one too?

[02:51:04.0407] <smaug>
I'll ping jonco for that module stuff

[02:52:11.0524] <annevk>
 * Yeah, agreed, that would give the most consistent results. Filed an issue: https://github.com/w3c/csswg-drafts/issues/11008. Though I should also see what primitives existing implementations have on offer maybe. Don't want to add too many novel concepts. Hopefully Sam Weinig can double check that.

[03:26:11.0011] <Yoav Weiss>
Will do!

[03:54:01.0097] <annevk>
Yoav Weiss: how do determine Chromium's position on Dynamic Import Maps actually? In particular with regards to eventually shipping it. Any Chromium API Owners said something somewhere?

[03:55:32.0525] <annevk>
Also, I still think Dynamic Import Maps is confusing given Dynamic Import, but since it's not actually a web-exposed name I guess I'll let other people handle that.

[03:55:50.0491] <annevk>
 * Yoav Weiss: how do we determine Chromium's position on Dynamic Import Maps actually? In particular with regards to eventually shipping it. Any Chromium API Owners said something somewhere?

[03:58:30.0752] <Yoav Weiss>
annevk: that's a great question! There's no official way to ask for a position from Chromium unfortunately. The decisions there have typically been delegated to the relevant Chrome teams. In this particular case, the relevant folks are Domenic and Hiroshige, who both reviewed and are supportive.

[03:59:13.0207] <Yoav Weiss>
^^ Jeffrey Yasskin on the Chrome positions question, as it's not the first time and probably not the last

[04:06:36.0183] <annevk>
Yoav Weiss: I think that's fine, but in that case maybe say so in the line item instead of just saying you prototyped in Chromium?

[04:08:14.0032] <Yoav Weiss>
Will do! regarding "dynamic import maps" as the PR name, happy to rename it to whatever works


2024-10-08
[17:36:45.0944] <Domenic>
Yoav Weiss: annevk: if it's not too much trouble, I tend to agree a renaming of the feature would be nice, to enhance clarity in e.g. ChromeStatus and any blog posts or web developer documentation that gets produced. "Multiple import maps" or "Updateable import maps" maybe.

[23:56:49.0039] <Yoav Weiss>
Domenic: annevk renamed everywhere I could think of (PR, TAG review, positions, chrome feature, relevant bugs)

[14:40:37.0484] <Dominic Farolino>
Does anyone know what https://w3c.github.io/selection-api/#dom-window-getselection is actually supposed to do / point to?


2024-10-09
[17:25:10.0660] <Domenic>
> <@domfarolino:matrix.org> Does anyone know what https://w3c.github.io/selection-api/#dom-window-getselection is actually supposed to do / point to?

The section right above it, right?

[07:13:50.0279] <Dominic Farolino>
Just a quick sanity check around shadows: a node is not considered "inserted into a document" if it is appended to a node inside a shadow tree. That is, its "inserted into" hook won't run, right? https://html.spec.whatwg.org/C#insert-an-element-into-a-document

[08:26:29.0837] <annevk>
Dominic Farolino: "node is inserted into a document" won't run, the "insertion steps" will

[08:26:45.0605] <annevk>
(because the node's root won't be a document)

[10:19:52.0774] <Dominic Farolino>
Right, OK. That's what I thought but I wanted to check because I'm seeing at least two instances of those steps running upon insertion into a shadow tree (in implementations)


2024-10-10
[23:19:17.0267] <annevk>
Dominic Farolino: shadow tree integration with the wider web platform was never really fully finished and I doubt we actually have tests covering all these scenarios, so that seems plausible unfortunately

[23:21:48.0030] <annevk>
Dominic Farolino: in particular when you see something say "in a document" it hasn't been looked at yet, but a lot of these things could do with more review and tests: https://dom.spec.whatwg.org/#document-trees 

[00:06:45.0125] <annevk>
Domenic: look at what you made me do: https://github.com/w3c/csswg-drafts/issues/11008 (Luke Warlow shares some of the blame, but the suggestion for fancy serialization was yours alone)

[00:08:57.0971] <Domenic>
Fun times...

[00:18:03.0909] <annevk>
To be fair, it has been fun figuring out all the C++ primitives in WebKit. The APIs are not always as straightforward as one might like, but there is a way.

[00:44:30.0541] <Luke Warlow>
> <@annevk:matrix.org> To be fair, it has been fun figuring out all the C++ primitives in WebKit. The APIs are not always as straightforward as one might like, but there is a way.

Out of interest do you have a draft PR for this prototype I was looking at the available APIs for parsing and serialising CSS colours in 4 engines and was stumped a bit in all of them. WebKit and chrome both seemed to have stub functions for the parsing for example.

[01:51:27.0242] <annevk>
I'm planning to put it up later today. I wanted to make sure modifications to the colorspace and alpha attributes were properly reflected, but it seems that `::value()` already does the correct thing. (I suppose there is a case to consider about what to do when the picker is open, but I'm not quite there yet.)

[02:35:09.0214] <annevk>
Luke Warlow: https://github.com/WebKit/WebKit/pull/34970

[04:45:20.0122] <zcorpan>
jarhar: for reconstructing formatting elements, the interesting cases are
- <select><div><i></div><option>
- <div><i></div><option>
The not-in-select case should reconstruct to match what happens today. I know I suggested not doing that for option-in-select, but maybe it should also reconstruct so that handling of option is a bit more consistent between the two cases. (Same deal for optgroup)

[04:45:54.0082] <zcorpan>
 * jarhar: for reconstructing formatting elements, the interesting cases are

- \<select>\<div>\<i>\</div>\<option>
- \<div>\<i>\</div>\<option>

The not-in-select case should reconstruct to match what happens today. I know I suggested not doing that for option-in-select, but maybe it should also reconstruct so that handling of option is a bit more consistent between the two cases. (Same deal for optgroup)

[05:43:06.0498] <sauceee>
Yall tapn
https://t.me/+32cFzLuOiacxZmM0


[06:32:55.0038] <Dominic Farolino>
> <@annevk:matrix.org> Dominic Farolino: in particular when you see something say "in a document" it hasn't been looked at yet, but a lot of these things could do with more review and tests: https://dom.spec.whatwg.org/#document-trees

Right, I knew "in a document" usages were pretty suspicious; I had assumed that "in a document tree" usages were fully vetted though. Oh well

[08:08:13.0044] <annevk>
Dominic Farolino: we might have decided, but it also predated writing tests for all changes I suspect

[08:08:24.0372] <annevk>
Dominic Farolino: please do file issues if you spot mismatches

[09:01:39.0619] <Dominic Farolino>
Yep, will do!

[10:05:49.0252] <smaug>
oh, HTML spec doesn't even define focusin? It has only blur and focus. And per UI event, focusout/in are basically just bubbling variants of blur/focus. But what implementations actually do...

[10:08:11.0984] <smaug>
 * oh, HTML spec doesn't even define focusin? It has only blur and focus. And per UI events, focusout/in are basically just bubbling variants of blur/focus. But what implementations actually do...

[10:10:39.0309] <annevk>
smaug: there's an issue on adding them, as well as FocusEvent

[10:11:00.0175] <annevk>
smaug: it was unfortunately not as easy as I hoped, but I last looked at that many years ago, so maybe it's easier today

[10:11:34.0174] <Luke Warlow>
https://github.com/whatwg/html/pull/10235

[10:12:37.0465] <annevk>
Ah I forgot about that patch. Hopefully Joey didn't

[10:15:41.0665] <smaug>
There's been some implementation differences, https://searchfox.org/mozilla-central/rev/9f49f28c3b7f53b1a1f47350ed38437d113d1aa6/dom/base/nsFocusManager.cpp#2848-2849 Not sure if webkit still differs 

[10:21:44.0505] <Luke Warlow>
> <@smaug:mozilla.org> There's been some implementation differences, https://searchfox.org/mozilla-central/rev/9f49f28c3b7f53b1a1f47350ed38437d113d1aa6/dom/base/nsFocusManager.cpp#2848-2849 Not sure if webkit still differs 

Iirc not all browsers offer the IDL attributes for the event listeners either. Which I believe has actively caused issues in Preact. (https://github.com/preactjs/preact/issues/4314)

[10:23:53.0664] <smaug>
ah, Gecko doesn't have event handlers. And webkit has some unusual kinds of event handlers, https://searchfox.org/wubkat/rev/1146c56cb9208244b769da6dc2b7b708a8c4fb5b/Source/WebCore/dom/Element.idl#77-78

[10:30:57.0026] <smaug>
I don't see onfocusin webidl attribute in Chrome

[10:50:34.0937] <Luke Warlow>
Yeah there isn't one yet Joey has a patch to add it which I guess is waiting on the spec pr.

[15:39:51.0030] <jarhar>
thanks! i used this as an example and asked here: https://github.com/whatwg/html/pull/10557#discussion_r1796173325

[15:40:10.0495] <jarhar>
i don't have strong opinions on this, but yeah doing the same thing in both cases sounds like a good justification


2024-10-11
[17:59:27.0863] <Domenic>
Yeah https://github.com/whatwg/html/pull/10235 concluded with us realizing that a straightforward spec wouldn't necessarily match Chrome's implementation, so, we wanted to do more investigation and write more tests. I suspect jarhar got pulled into other things though. I also heard Dominic Farolino might help with the investigation/spec work.


2024-10-12
[13:47:45.0309] <Pascal Vos>
hello 👋


2024-10-14
[01:31:04.0300] <quadristan>
Hello! I think i've spotted a typo in `nooopener-allow-popups`. there is an additional o in https://html.spec.whatwg.org/multipage/browsers.html#coop-noopener-allow-popups . I'm opening n MR to fix this

[01:32:44.0131] <smaug>
keithamus:  Hmm, doesn't the step 4 assert in https://html.spec.whatwg.org/#show-popover fail if beforetoggle (once:true) listener doesn't call preventDefault() but calls showPopover()

[01:33:14.0278] <smaug>
(happened to read that algorithm while looking at the other relevant stuff)

[01:49:54.0694] <Noam Rosenthal>
keithamus: looping back on https://github.com/whatwg/html/issues/10666#issuecomment-2408260094 (keeping focus for moving elements during `moveBefore` from the last WHATNOT). You've raised concerns about a11y with focused elements. Is w3c/aria the right place to open an issue about this or somewhere else? https://www.w3.org/WAI/about/groups/ariawg/contribute/ is kinda confusing in that regard.

[01:51:29.0213] <Noam Rosenthal>
> <@noamr:matrix.org> keithamus: looping back on https://github.com/whatwg/html/issues/10666#issuecomment-2408260094 (keeping focus for moving elements during `moveBefore` from the last WHATNOT). You've raised concerns about a11y with focused elements. Is w3c/aria the right place to open an issue about this or somewhere else? https://www.w3.org/WAI/about/groups/ariawg/contribute/ is kinda confusing in that regard.

We did have an internal a11y review specifically for this, and there were no concerned raised. That's because elements can already stay in place and everything else move around them, and the developer can call `focus()` programatically anyway as well. So `moveBefore` doesn't add anything new here as long as we make sure the AT is up to date

[01:52:10.0562] <keithamus>
> <@smaug:mozilla.org> keithamus:  Hmm, doesn't the step 4 assert in https://html.spec.whatwg.org/#show-popover fail if beforetoggle (once:true) listener doesn't call preventDefault() but calls showPopover()

Step `9` prevents going further though right?

[01:54:12.0822] <smaug>
Ah

[01:55:35.0039] <keithamus>
> <@noamr:matrix.org> keithamus: looping back on https://github.com/whatwg/html/issues/10666#issuecomment-2408260094 (keeping focus for moving elements during `moveBefore` from the last WHATNOT). You've raised concerns about a11y with focused elements. Is w3c/aria the right place to open an issue about this or somewhere else? https://www.w3.org/WAI/about/groups/ariawg/contribute/ is kinda confusing in that regard.

if you've had an internal review and it was deemed okay then I won't raise any further objections. I'm not an expert by any means but it seemed perhaps not-ideal IMO to move focus, because - yes while the user retains focus - their position relative to the page may have moved which may be very confusing as the traverse onward.

I think it is perhaps analogous to talk about `remove()` than to talk about `focus()`. If a developer calls `remove()` then browsers try to traverse the hole up to a nearest container to set the sequential focus start point, no? I'd perhaps offer that _might_ be more preferable than moving their focus, because the position in the page hasn't change but there is also an acknowledgement that something on the page has changed.

[01:56:36.0059] <Noam Rosenthal>
keithamus: on remove, the focus is simply lost. Frameworks today sometimes compensate by calling `focus` programatically

[01:56:41.0629] <keithamus>
> <@keithamus:matrix.org> if you've had an internal review and it was deemed okay then I won't raise any further objections. I'm not an expert by any means but it seemed perhaps not-ideal IMO to move focus, because - yes while the user retains focus - their position relative to the page may have moved which may be very confusing as the traverse onward.
> 
> I think it is perhaps analogous to talk about `remove()` than to talk about `focus()`. If a developer calls `remove()` then browsers try to traverse the hole up to a nearest container to set the sequential focus start point, no? I'd perhaps offer that _might_ be more preferable than moving their focus, because the position in the page hasn't change but there is also an acknowledgement that something on the page has changed.

IME the biggest pitfall and biggest source of complaints we have when building out accessible interfaces is the user getting no acknowledgement of the page changing. Calling `.focus()` _is_ an acknowledgement (because AT potentially re-reads the content).

[01:57:44.0863] <Noam Rosenthal>
> <@keithamus:matrix.org> IME the biggest pitfall and biggest source of complaints we have when building out accessible interfaces is the user getting no acknowledgement of the page changing. Calling `.focus()` _is_ an acknowledgement (because AT potentially re-reads the content).

AT is a different story, we have to update AT after calling `moveBefore` to account for the focused element perhaps moving, or regardless because the tree could change in many ways when the DOM hierarchy is modified

[01:58:58.0440] <keithamus>
> <@noamr:matrix.org> AT is a different story, we have to update AT after calling `moveBefore` to account for the focused element perhaps moving, or regardless because the tree could change in many ways when the DOM hierarchy is modified

That makes sense. I wonder if the move operations should cause explicit announcements in AT?

[01:59:34.0756] <Noam Rosenthal>
> <@keithamus:matrix.org> That makes sense. I wonder if the move operations should cause explicit announcements in AT?

They do in blink; Not sure how that translates to spec-land

[01:59:49.0784] <keithamus>
> <@keithamus:matrix.org> That makes sense. I wonder if the move operations should cause explicit announcements in AT?

Though that might be too noisy. This is why I encouraged y'all reaching out to ARIA WG btw, I don't intend to throw spanners I am just _unsure_ what should happen here and would rather hear from the experts. 

[02:00:00.0093] <Noam Rosenthal>
oh you mean that the user will get notifications that something changed? I don't think sdo

[02:00:47.0737] <Noam Rosenthal>
You could be e.g. removing an intermediate layout container that has no content significance

[02:01:01.0649] <Noam Rosenthal>
(we've discussed this with our internal a11y experts as I said)

[02:03:17.0801] <keithamus>
> <@noamr:matrix.org> You could be e.g. removing an intermediate layout container that has no content significance

Yep, makes sense to me 👍️


2024-10-16
[21:22:45.0081] <sideshowbarker>
I’m noticing some unexpected percent-encoding happening with the HTML checker service, and I’m wondering if it’s just some quirk unique to that, or if there’s something about percent-encoding that I’m misunderstanding

[21:23:44.0202] <sideshowbarker>
If you go to https://validator.w3.org/nu/ and this:
`data:text/html;charset=utf-8,<%3Fxml-stylesheet type="text/css" href="style.css"?>`
into the **Check by address** text input

[21:24:34.0796] <sideshowbarker>
…then the request URL that the HTML checker uses is this:
`https://validator.w3.org/nu/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%253Fxml-stylesheet+type%3D%22text%2Fcss%22+href%3D%22style.css%22%3F%3E`

[21:24:49.0872] <sideshowbarker>
Notice the `%253F`

[21:25:57.0195] <sideshowbarker>
If I manually alter that part of the request URL to `%253F`, the HTML checker seems to fail to parse that data URI value as expected

[21:28:05.0356] <sideshowbarker>
 * If you go to https://validator.w3.org/nu/ and enter this:
`data:text/html;charset=utf-8,<%3Fxml-stylesheet type="text/css" href="style.css"?>`
into the **Check by address** text input

[21:29:22.0156] <sideshowbarker>
 * If you go to https://validator.w3.org/nu/ and enter this data URI:
`data:text/html;charset=utf-8,<%3Fxml-stylesheet type="text/css" href="style.css"?>`
into the **Check by address** text input

[21:30:39.0630] <sideshowbarker>
 * If I manually alter that part of the request URL to `%25%3F`, the HTML checker seems to fail to parse that data URI value as expected

[21:32:11.0573] <arai>
`%253F` is valid.  that's `%3F` in the original URI, where the `%` itself is encoded as `%25`

[21:36:44.0135] <sideshowbarker>
oh

[21:37:24.0042] <sideshowbarker>
d’oh of course — I see now


2024-10-17
[01:46:27.0757] <gamicord>
Normally, we teach kids HTML, CSS and JavaScript, using just NotePad, Notepad++ and a Web browser.

And most times, we do this without an internet connection, without having a server, and without having a backend like NodeJS, WAMP, or XAMPP.

The challenge I have, is that I want to teach these kids the Download Functionality.

But when we add the "Download Attribute" to the href of our Anchor Tag, the file doesn't download.

Rather, it opens up in a new Tab or window.

What I found out, is that, the "Download Attribute" doesn't work on the Local file system.

This is the same issue here on GitHub---https://github.com/mozilla-mobile/firefox-ios/issues/13299

Since we are moving some things into HTML and CSS according to this talk-- https://youtu.be/IP_rtWEMR0o

In which case, things like Dialog (modal) are now tags in HTML.

MY REQUEST
Add parameters to the "Download Attribute" --- where we can specify the source of the downloadable file.

Parameters like "localfile", "server", "domain", "filesystem".

These parameters to the Download Attribute, makes it more versatile and capable.

--"localfile" -- means that the fie is in the same root as the index.html file.

-- "server" -- -- means that the file is hosted on a Web Server. In this case, it will only allow for absolute URL in the href.

--  "domain"-- means that the file is hosted on a Web Server of same-origin. In this case, it can allow for relative URL in the href.

-- "filesystem"---- means that the file is hosted on a Laptop or Personal Computer(PC).

This should allow the Download Attribute to still download the file, using relative URL in the href.

THE CHALLENGE
I am not able to download from my Local File system, not able to download within my PC with the Download Attribute, and I have raised it on Microsoft Forum -- https://answers.microsoft.com/en-us/microsoftedge/forum/all/html5-download-attribute-is-not-working-at-all-on/6f0681ee-05b6-49f8-a0f2-9ef6b6e27460

And also on W3Schools Forum --- https://w3schools.invisionzone.com/topic/63572-html5-download-attribute-is-not-working-at-all-on-all-browsers/

MOVING FORWARD
If WHATWG can add parameters as specified, or parameters that they see fit, which can allow us use the Download Attribute to natively download files from the Local File System of my Laptop or PC, I will be the most glad and grateful to WHATWG.

Special Regards, as I keenly await your positive response.

[06:18:12.0780] <annevk>
Did anyone try to reproduce that by chance? This person also emailed `sg@`. My suspicion is that these are browser bugs and no new feature is needed.

[15:37:43.0529] <jamescobban>
I am a little surprised that you do not have a web server for your course, containing the course documentation.  Designing web sites is intrinsically a cooperative group activity.  To some extent the whole point of the Web is that it is NOT contained on your own computer.  Why teach your students something they will never use outside of the class?  You do not need connectivity to the outside world, just a WiFi node that all of the student's devices are connected to that also includes a workstation running a web server.

[16:16:05.0195] <akaster>
I'm a little confused trying to implement the Update algorithm from the service workers spec. It seems like the spec hasn't been updated to reflect the latest changes to perform the fetch hook from the HTML spec? Specifically the concept of the processCustomFetchResponse algorithm

[16:16:38.0669] <akaster>
For example, steps 4, 5, and 6 say this:
> 4. If the isTopLevel flag is unset, then return the result of fetching request.
> 5. Set request’s redirect mode to "error".
> 6. Fetch request, and asynchronously wait to run the remaining steps as part of fetch’s processResponse for the response response.


[16:18:00.0487] <akaster>
but in the steps for dedicated workers, https://html.spec.whatwg.org/multipage/workers.html#run-a-worker, it is quite a bit clearer...

> 1. If isTopLevel is false, fetch request with processResponseConsumeBody set to processCustomFetchResponse, and abort these steps.
> 2. Set request's reserved client to inside settings.
> 3. Fetch request with processResponseConsumeBody set to the following steps given response response and null, failure, or a byte sequence bodyBytes:

[16:18:50.0620] <akaster>
Should I just be assuming that steps 4,5,and 6 from service workers Update AO are written with the same language as run a worker and open a spec issue?

[16:28:14.0158] <akaster>
or does the service worker spec here actually want me to fetch request with `processResponse` set to the following steps?

[16:28:33.0656] <akaster>
(rather than processResponseConsumeBody like for shared/dedicated workers)

[16:30:43.0353] <Kaiido>
> <@annevk:matrix.org> Did anyone try to reproduce that by chance? This person also emailed `sg@`. My suspicion is that these are browser bugs and no new feature is needed.

All browsers seem to allow `download` using an in-memory source, i.e. `blob:` or `data:`. What they block is the downloading of cross-origin resources, just like when served from an actual server. The thing might be that browsers do consider `file:` as an opaque origin, and thus block even "same-folder" downloads.


2024-10-18
[17:46:18.0036] <akaster>
> <@akaster:serenityos.org> or does the service worker spec here actually want me to fetch request with `processResponse` set to the following steps?

I also don't know what "Asynchronously complete these steps with a network error." means. Is that supposed to mean to abort the fetch controller?

[17:46:26.0870] <akaster>
> <@akaster:serenityos.org> or does the service worker spec here actually want me to fetch request with `processResponse` set to the following steps?

 * I also don't know what "Asynchronously complete these steps with a network error." means. Is that supposed to mean to abort the fetch controller with a network error?

[17:46:38.0686] <Domenic>
> <@akaster:serenityos.org> I'm a little confused trying to implement the Update algorithm from the service workers spec. It seems like the spec hasn't been updated to reflect the latest changes to perform the fetch hook from the HTML spec? Specifically the concept of the processCustomFetchResponse algorithm

Indeed I don't think the service worker spec has been updated very much recently at all. A PR updating it would be very welcome.

[17:52:18.0228] <akaster>
Maybe I'm supposed to run `processCustomFetchResponse` with response and a network error failure 🤔


2024-10-20
[12:46:45.0052] <Noam Rosenthal>
> <@akaster:serenityos.org> Maybe I'm supposed to run `processCustomFetchResponse` with response and a network error failure 🤔

I'm reading this as you're supposed to run `processCustomFetchResponse` with a network error and null

[12:48:21.0092] <Noam Rosenthal>
Ah actually not. It's supposed to return a network error instead of the actual response

[12:49:03.0360] <Noam Rosenthal>
those "fetch hooks" are like a post-processor to whatever fetch gave you

[12:49:52.0222] <Noam Rosenthal>
you fetch the script like you do for a normal worker, and then run the "perform a fetch hook" as defined in the service worker spec on the response

[12:51:47.0892] <Noam Rosenthal>
(Sorry, I mean it's a processor that replaces what fetch gives you)

[12:52:09.0441] <akaster>
Yeah I think I have it correct here <https://github.com/LadybirdBrowser/ladybird/pull/1866/files#diff-ae24ad31836c730f2992e34539836a76a794aa52041ac31ac00d4c96dd1bf53dR213> or at least , correct-ish. The thing I don't like is waiting in perform the fetch hook for the processResponse for the fetch to trigger. I feel like I should be back-propogating the fetch controller so it can be aborted or something 

[12:53:57.0944] <akaster>
I'm grabbing the perform custom fetch response in my fetch hook and using it as the process response consume body hook in the fetch algorithm input, same as what the worker impl does. Just, causing my fetch hook to return a network error to influence how the algorithm from "fetch a worker script" behaves

[12:54:26.0258] <akaster>
... Definitely in need of a spec update here once I actually create a service worker process and prove that the script runs as an MVP

[12:56:32.0552] <Noam Rosenthal>
> <@akaster:serenityos.org> Yeah I think I have it correct here <https://github.com/LadybirdBrowser/ladybird/pull/1866/files#diff-ae24ad31836c730f2992e34539836a76a794aa52041ac31ac00d4c96dd1bf53dR213> or at least , correct-ish. The thing I don't like is waiting in perform the fetch hook for the processResponse for the fetch to trigger. I feel like I should be back-propogating the fetch controller so it can be aborted or something

In most script fetches we don't abort, but rather get all the data in advance (`processResponseConsumeBody`). I'm not sure if aborting in this case is web-observable

[12:58:26.0485] <akaster>
Makes sense. I think if it was to be consistent with "run a worker" the steps should say that we do all these checks in process response consume body, and then run the process custom fetch response passed in by "fetch a classic worker script" afterwards (still in process response consume body)

[12:59:53.0397] <Noam Rosenthal>
Yea I have a faint memory of refactoring scripts to use `processResponseConsumeBody` myself a few years ago, and I probably neglected service-worker fetching

[13:01:44.0201] <akaster>
I'm still a bit confused about the time traveling environment settings object I'm supposed to invent. I guess I'll have to create some faked-out ESO once I implement setting up the service worker global and environment settings and understand what priorities are relevant

[13:02:08.0598] <akaster>
* I'm still a bit confused about the time traveling environment settings object I'm supposed to invent. I guess I'll have to create some faked-out ESO once I implement setting up the service worker global and environment settings and understand what properties are relevant

[13:04:35.0900] <Noam Rosenthal>
Ah you mean https://w3c.github.io/ServiceWorker/#issue-02e2fe82 I think

[13:05:50.0638] <akaster>
Yeah both of those issues correspond to fixmes in my PR there 🤔

[13:06:57.0705] <akaster>
They're basically saying that fetch wants the context for who will run the script, but we don't have the context yet because we haven't started the service worker process yet. So, hand wave and hax incoming

[13:08:07.0863] <Noam Rosenthal>
hehe gotcha. I think this can be similar to the environment created for yet-to-be-navigated-to documents but it would require a lot of care to spec correctly

[16:33:18.0580] <gingeh_>
Hello, how should isomorphic decoding handle non-ASCII bytes (>0x7F)?


2024-10-21
[17:37:44.0510] <gingeh_>
Specifically, http://wpt.live/mimesniff/mime-types/charset-parameter.window.html seems to expect the charset from `text/html;test=ÿ;charset=gbk` to be successfully parsed. Should the test field be ignored, re-encoded or set to the replacement character?

[19:00:16.0007] <Domenic>
> <@gingeh_:matrix.org> Hello, how should isomorphic decoding handle non-ASCII bytes (>0x7F)?

There's no special handling for ASCII vs. non-ASCII bytes. Bytes greater than 0x7F also go to their corresponding code point.

[19:00:53.0208] <Domenic>
0xFF -> the code point U+00FF (ÿ), in particular.

[19:01:04.0548] <Domenic>
 * 0xFF <-> the code point U+00FF (ÿ), in particular.

[20:00:10.0230] <gingeh_>
I see my mistake now, I had misinterpreted it as meaning "interpret bytes as UTF-8 bytes" not "interpret bytes as unicode code point values"

[10:57:49.0367] <TabAtkins>
Yup, isomorphic as "same shape", just moving literally between the two encodings.

[11:48:10.0243] <annevk>
> Browser user agents should provide the ability to navigate, reload, and stop loading any top-level traversable in their top-level traversable set.

What is _sourceDocument_ in these cases?

[12:15:59.0834] <Noam Rosenthal>
None

[12:16:30.0646] <Noam Rosenthal>
`sourceDocument` is for when you browse from a context of another document (e.g. `window.open`, `location.replace()`, not from the browser UI

[13:28:29.0383] <annevk>
That's not a valid value though. It takes a `Document`.

[15:08:07.0217] <akaster>
We use the top level traversable's active document in this case, which is not correct. It prevents navigating from e.g. an https:// site to a file:// page from the browser UI.

[15:09:11.0554] <akaster>
well I mean it could work, if there were additional checks involving the User Navigation Involvement 

[15:58:19.0773] <annevk>
Using the active document will be very wrong to determine things like referrer and such. You could maybe first navigate to an opaque origin about:blank and then use that? But that seems like a giant hack.

[16:18:00.0249] <akaster>
Associated ladybird bug: <https://github.com/LadybirdBrowser/ladybird/issues/991>

[16:20:05.0617] <akaster>
Wait maybe that one isn't right. We might need a new one 🤔

[16:32:02.0679] <annevk>
Finding Nemo birds meme: bugs? bugs? bugs?


2024-10-22
[17:55:19.0728] <annevk>
jarhar: is there a single place where all `<select>` PRs and issues are linked?

[17:55:57.0105] <annevk>
jarhar: some kind of meta issue using the checkbox-style list might be useful here, it's a bit hard to keep it all straight

[18:26:41.0786] <Domenic>
This is an open issue

[18:26:55.0689] <Domenic>
https://github.com/whatwg/html/issues/9133

[18:27:19.0830] <Domenic>
We have a tentative proposal but were hoping you could give us a clear answer on the origin field, but you weren't sure

[18:29:29.0864] <Domenic>
Maybe Noam can put on his Fetch expert hat and give us a better answer :)

[19:35:43.0174] <jarhar>
annevk: the issue description here has them all: https://github.com/whatwg/html/issues/9799

[00:14:54.0999] <Noam Rosenthal>
sourceDocument is optional no?

[00:15:16.0104] <Noam Rosenthal>
It should be like navigating an open tab 

[00:44:57.0894] <Noam Rosenthal>
Ah some algorithms depend on it being there

[00:46:17.0264] <Noam Rosenthal>
Shouldn't this be the initial `about:blank`? You're practically navigating from nowhere

[00:46:37.0063] <Noam Rosenthal>
"from" as in "no particular document is initiating this navigation".

[00:47:04.0498] <Noam Rosenthal>
(Thinking out loud, it could be that my sense of logic here doesn't fit with some of the details)

[00:50:29.0267] <Noam Rosenthal>
Yea, it should be the same document you create in https://html.spec.whatwg.org/multipage/document-sequences.html#creating-a-new-browsing-context

[01:04:16.0834] <Noam Rosenthal>
... with a "last activation timestamp" set to now

[01:05:18.0738] <Noam Rosenthal>
(I could be missing a detail, added a comment on https://github.com/whatwg/html/issues/9133). But in general we should treat this navigation as much as possible as a navigation from `about:blank`, but with activation + uses the same traversable navigable for the purposes of history etc

[09:40:03.0786] <akaster>
"inventing" a fictional document-like object that behaves as-if it is an about:blank initial document would be an unfortunate way to spec that. hopefully there's a clearer and easier to implement way to describe the desired behavior

[10:39:48.0761] <annevk>
Alan Stearns: heya, could you add weinig to the group of people that can add labels to w3c/csswg-drafts? He is independent at the moment and does a lot of CSS value work.

[10:43:47.0139] <Alan Stearns>
annevk: I could once they get added to the W3C org by some team member with access. sideshowbarker ?


2024-10-23
[23:25:00.0659] <scott_michaud_riv>
Hello! Regarding the FS Living Standard (https://fs.spec.whatwg.org/#files-and-directories) I notice that there's no direct mention of maximum path length. Is that expected to be a non-issue? Or should app developers keep the total directories below some threshold for cross-platform compatibility? (Crossing fingers that I don't need to keep things under 256/260 chars for MAX_PATH lol.)

[23:25:15.0804] <scott_michaud_riv>
 * Hello! Regarding the FS Living Standard (https://fs.spec.whatwg.org/#files-and-directories) I notice that there's no direct mention of maximum path length. Is that expected to be a non-issue? Or should app developers keep the total nesting of directories below some threshold for cross-platform compatibility? (Crossing fingers that I don't need to keep things under 256/260 chars for MAX\_PATH lol.)

[03:38:37.0007] <Noam Rosenthal>
We're already using this fictional document when navigating a new tab... so it would be a consistent unfortunate way to spec this

[03:39:31.0736] <Noam Rosenthal>
There are probably clearer ways to describe the desired behavior but I'm not convinced about "easier"

[03:41:30.0125] <Noam Rosenthal>
We can probably create something like a reserved environment that's not a document to be the fetch client in this case, but I'm not sure it's easier in anyway (or substantially different from an `initial about:blank`)

[03:49:34.0171] <Noam Rosenthal>
In any case, the result should be equivalent in the web observable sense

[04:03:07.0106] <Noam Rosenthal>
I think the other option is actually to have a request client of `null`. It would have a `reserved client` created in https://html.spec.whatwg.org/multipage/browsing-the-web.html#create-navigation-params-by-fetching. `fetch` can work fine without a request client. 

[04:03:35.0385] <Noam Rosenthal>
Looking at chromium code for this, it's kind of more equivalent to what's happening in a UI-initiated navigation

[05:39:53.0851] <Noam Rosenthal>
Heh in `Sec-Fetch-Site`: 

"If r is a navigation request that was explicitly caused by a user’s interaction with the user agent (by typing an address into the user agent directly, for example, or by clicking a bookmark, etc.), then set header’s value to none."

https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header

[05:40:51.0482] <Noam Rosenthal>
So so far I can't see one place where it matters whether the origin of the navigation request is opaque or the new navigation URL, also service workers don't expose this

[09:14:41.0706] <annevk>
scott_michaud_riv: not sure. But https://infra.spec.whatwg.org/#algorithm-limits might help.

[14:20:59.0603] <akaster>
When WebIDL says:

N. Return PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability).

should the steps actually be:

N. PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability).
N+1. Return newCapability.

?


[14:21:49.0159] <akaster>
PerformPromiseThen will return newCapability.[[Promise]] if newCapability is not undefined. but the actual [[Promise]] slot of a PromiseCapability is kind of useless to WebIDL

[14:22:01.0194] <akaster>
you can't re-wrap it in another PromiseCapability for example

[14:30:27.0564] <annevk>
akaster: seems likely from what is done elsewhere, though not exactly an expert. You could wait for Domenic but seems reasonable to preemptively file an issue to at least get it clarified if it's intentional.

[14:32:03.0976] <akaster>
thanks! I'm looking at our implementation of converting JS values to WebIDL Promises and back, and it seems we had quite a lot of confusion about the use of a Promise vs a PromiseCapability back when we wrote that part of the code generator. Cleaning this up is requiring some hard looks at the WebIDL spec. (side yak from implementing https://webassembly.github.io/spec/web-api/#compile-a-potential-webassembly-response, which both takes and returns a Promise<T>)

[14:41:34.0527] <akaster>
https://github.com/whatwg/webidl/issues/1443


2024-10-24
[02:30:37.0473] <Ms2ger>
akaster: I make no claims that the current wasm spec is optimal or agrees with browsers in all edge cases on this point :)

[10:45:40.0675] <Sam Sneddon [:gsnedders]>
https://infra.spec.whatwg.org/#algorithm-limits would arguably cover this; I'd _hope_ this isn't a problem with major browsers given you can with modern APIs on Windows not be concerned about that.

[11:52:09.0686] <akaster>
Domenic: When implementing HostPromiseRejectionTracker, https://html.spec.whatwg.org/multipage/webappapis.html#the-hostpromiserejectiontracker-implementation, are we expecting that the `promise` object is the actual JS Promise object? or should it be converted to a WebIDL Promise<T> before doing anything with it in the algorithm per the conversion steps in https://webidl.spec.whatwg.org/#js-promise ? I'm not sure if it is observable whether we e.g. fire a PromiseRejectionEvent with "a PromiseCapability resolved with promise" vs the JS Promise object itself

[12:23:12.0327] <akaster>
hm. rephrased this question in <https://github.com/whatwg/html/issues/10721>

[14:17:34.0140] <akaster>
heh. `let e = new PromiseRejectionEvent('eventName', { promise: 42 });` only throws in Firefox. seems everyone else allows synthetic PromiseRejectionEvents to have a `promise` property of any type

[14:22:44.0326] <annevk>
WebKit has `required Promise<any> promise;` there, which seems kinda what you'd expect?

[14:24:13.0512] <annevk>
I wonder if this got changed post implementation. It does seem a little wonky that the `promise` getter can return a non-promise.

[14:54:30.0114] <akaster>
🤷I'm adding logic to our IDL generator to convert any Promise<T> properties of IDL interfaces into PromiseCapabiltiies before sending them along to our web engine

[14:55:09.0688] <akaster>
so in that case, doing so for PromiseRejectionEvent is likely incorrect (pending that issue I posted). So  it seems like copying firefox and pretending that it's supposed to be `required object promise` is easiest to keep moving fwd with the change

[15:10:34.0043] <annevk>
I would do whatever is easiest as it's just synthetic events that are impacted here and they're a rather niche use case.

[15:11:06.0434] <annevk>
Though we should also figure out what this should do longer term. :-) Maybe object is reasonable though, just seems odd.


2024-10-25
[17:11:08.0636] <Domenic>
The spec changed from `Promise<any>` to `object` in https://github.com/whatwg/html/pull/9897. Referring to my just-written comment in https://github.com/whatwg/html/issues/10721#issuecomment-2436548874 , we lost (3) but gained (2) in that change.

[03:47:25.0238] <annevk>
It seems that Chrome and Safari have 2 and 3 today.

[04:54:04.0001] <sideshowbarker>
Any chance somebody’s around who understands the https://w3c.github.io/accname/#computation-steps spec and the test at https://github.com/web-platform-tests/wpt/blob/master/accname/name/comp_embedded_control.html and https://github.com/web-platform-tests/wpt/blob/master/wai-aria/scripts/aria-utils.js#L133 ?

What I don’t understand about the test is: Given the following:

```
<label>
  <input type="checkbox" data-expectedlabel="Flash the screen 3 times" data-testname="checkbox label with embedded textfield" class="ex">
  Flash the screen
  <input value="3" aria-label="number of times" data-expectedlabel="number of times" data-testname="label of embedded textfield inside checkbox label" class="ex"> times
</label>
```
…the test expects `test_driver.get_computed_label()` for that first `input` element to be `Flash the screen 3 times`.

But I don’t understand how, from the spec, the computed label for that `input` element ends up being the concatenation of:

1. the `Flash the screen ` text node that follows that `input`
2. the value of the second `input` element
3. the value of the ` times` text node which follows the second `input` element

I mean, that all seems like what that instead would be is: the computed label would be for the `label` element that contains those other elements and those text nodes.

But that `label` element is not what the test is actually checking, as far as can see — the test is instead just checking, one by one, the computed label for each of the elements that have a `class="ex"` attribute. And not concatenating those.

But Gecko, WebKit, and Blink pass all those tests. So clearly their must be something I’m missing

[04:55:03.0447] <sideshowbarker>
 * Any chance somebody’s around who understands the https://w3c.github.io/accname/#computation-steps spec and the test at https://github.com/web-platform-tests/wpt/blob/master/accname/name/comp\_embedded\_control.html and https://github.com/web-platform-tests/wpt/blob/master/wai-aria/scripts/aria-utils.js#L133 ?

What I don’t understand about the test is: Given the following:

```
<label>
  <input type="checkbox" data-expectedlabel="Flash the screen 3 times" data-testname="checkbox label with embedded textfield" class="ex">
  Flash the screen
  <input value="3" aria-label="number of times" data-expectedlabel="number of times" data-testname="label of embedded textfield inside checkbox label" class="ex"> times
</label>
```

…the test expects `test_driver.get_computed_label()` for that first `input` element to be `Flash the screen 3 times`.

But I don’t understand how, from the spec, the computed label for that `input` element ends up being the concatenation of:

1. the `Flash the screen ` text node that follows that `input`
2. the value of the second `input` element
3. the value of the ` times` text node which follows the second `input` element

I mean, that all seems like what that instead would be is: the computed label for the `label` element that contains those other elements and those text nodes.

But that `label` element is not what the test is actually checking, as far as can see — the test is instead just checking, one by one, the computed label for each of the elements that have a `class="ex"` attribute. And not concatenating those.

But Gecko, WebKit, and Blink pass all those tests. So clearly their must be something I’m missing

[04:55:31.0454] <sideshowbarker>
 * Any chance somebody’s around who understands the https://w3c.github.io/accname/#computation-steps spec and the test at https://github.com/web-platform-tests/wpt/blob/master/accname/name/comp\_embedded\_control.html and https://github.com/web-platform-tests/wpt/blob/master/wai-aria/scripts/aria-utils.js#L133 ?

What I don’t understand about the test is: Given the following:

```
<label>
  <input type="checkbox" data-expectedlabel="Flash the screen 3 times" data-testname="checkbox label with embedded textfield" class="ex">
  Flash the screen
  <input value="3" aria-label="number of times" data-expectedlabel="number of times" data-testname="label of embedded textfield inside checkbox label" class="ex"> times
</label>
```

…the test expects `test_driver.get_computed_label()` for that first `input` element to be `Flash the screen 3 times`.

But I don’t understand how, from the spec, the computed label for that `input` element ends up being the concatenation of:

1. the `Flash the screen ` text node that follows that `input`
2. the value of the second `input` element
3. the value of the ` times` text node which follows the second `input` element

I mean, that all seems like what that instead would be is: the computed label for the `label` element that contains those other elements and those text nodes.

But that `label` element is not what the test is actually checking, as far as can see — the test is instead just checking, one by one, the computed label for each of the elements that have a `class="ex"` attribute. And not concatenating those.

But Gecko, WebKit, and Blink pass all those tests. So clearly, there must be something I’m missing

[05:03:59.0129] <sideshowbarker>
 * Any chance somebody’s around who understands the https://w3c.github.io/accname/#computation-steps spec and the test at https://github.com/web-platform-tests/wpt/blob/master/accname/name/comp\_embedded\_control.html and https://github.com/web-platform-tests/wpt/blob/master/wai-aria/scripts/aria-utils.js#L133 ?

What I don’t understand about the test is: Given the following:

```
<label>
  <input type="checkbox" data-expectedlabel="Flash the screen 3 times" data-testname="checkbox label with embedded textfield" class="ex">
  Flash the screen
  <input value="3" aria-label="number of times" data-expectedlabel="number of times" data-testname="label of embedded textfield inside checkbox label" class="ex"> times
</label>
```

…the test expects `test_driver.get_computed_label()` for that first `input` element to be `Flash the screen 3 times`.

But I don’t understand how, from the spec, the computed label for that `input` element ends up being the concatenation of:

1. the `Flash the screen ` text node that follows that `input`
2. the value of the second `input` element
3. the value of the ` times` text node which follows the second `input` element

I mean, it seems like what that all instead would be is: the computed label for the `label` element that contains those other elements and those text nodes.

But that `label` element is not what the test is actually checking, as far as can see — the test is instead just checking, one by one, the computed label for each of the elements that have a `class="ex"` attribute. And not concatenating those.

But Gecko, WebKit, and Blink pass all those tests. So clearly, there must be something I’m missing

[05:42:11.0444] <sideshowbarker>
ah nevermind, I see now I just need to implement **E. Host Language Label** from the spec correctly — https://w3c.github.io/accname/#step2E:

> if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string

since there’s a `label` wrapped around that `input`, the computed label is the that actual label textcontent

[06:13:48.0843] <zcorpan>
 sideshowbarker the integration between accname and <hostlanguage>-aam are not great

[06:18:10.0908] <zcorpan>
sideshowbarker: though where does it say to use the `value`? i.e. where does the "3" come from? https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-number-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

[08:22:52.0729] <Lea Verou>
Question: Certain elements, such as `<li>` or `<option>` are only permitted within certain element types. Should this perhaps be expanded to custom elements? Many use cases where a custom element may reasonably want to slot these, and currently they need to invent their own elements that mirror the API of these.
(I can file an issue, just wanted a sanity check)

[09:00:21.0544] <annevk>
Lea Verou: if there is no HTML parser weirdness that might be okay. Might be tricky to correctly update everything that needs to be updated (and find it all).

[10:06:48.0417] <Lea Verou>
> <@annevk:matrix.org> Lea Verou: if there is no HTML parser weirdness that might be okay. Might be tricky to correctly update everything that needs to be updated (and find it all).

No need to do all at once, it could be done one at a time

[10:11:02.0526] <Lea Verou>
> <@annevk:matrix.org> Lea Verou: if there is no HTML parser weirdness that might be okay. Might be tricky to correctly update everything that needs to be updated (and find it all).

Ok, issue filed: https://github.com/whatwg/html/issues/10722 Thanks!

[12:02:35.0197] <akaster>
Should specs be directly referencing the "promise-calling" concept in spec steps? WebDriver's Execute Script AO https://w3c.github.io/webdriver/#execute-script says:

> 8. Let scriptPromise be the result of promise-calling execute a function body, with arguments body and arguments. 

Reading into https://www.w3.org/2001/tag/doc/promises-guide#should-promise-call, which is linked from that step, it sounds like specification writers are supposed to 'achieve' promise calling, rather than telling implementers to make it happen?


2024-10-26
[14:25:15.0130] <akaster>
Am I bikeshedding wrong or is there an issue with the WebIDL spec? <https://github.com/whatwg/webidl/issues/1444>

[14:25:19.0580] <akaster>
 * Am I bikeshedding wrong or is there an issue with the WebIDL spec build? https://github.com/whatwg/webidl/issues/1444


2024-10-27
[00:01:42.0659] <annevk>
Lea Verou: well we do try to atomically update the HTML standard so I think we should try to identify all places in advance

[00:03:24.0782] <annevk>
akaster: looks like ECMAScript removed %IteratorPrototype% and nobody filed an upstream PR? (This is how we detect a subset of cross-specification "compilation" issues.)

[00:35:08.0479] <sideshowbarker>
> <@zcorpan:mozilla.org> sideshowbarker: though where does it say to use the `value`? i.e. where does the "3" come from? https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-number-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

Yeah I guess that `3` can only come from using the `input` value. If the spec doesn’t clearly require doing that, I guess it’s possible that other implementors — in order to get that test case to pass — may have just made an assumption about what the spec _intended_.


[00:40:30.0012] <sideshowbarker>
I mean, that test case is basically the same as what’s in Example 4 in the spec at https://w3c.github.io/accname/#example-4 — a `<input type="checkbox">` element — but nowhere in that algorithm can I find any step that states requirements for role=checkbox (for `<input type="checkbox">`).

I guess it’s possible that the spec _used to_ state such requirements, but then they got inadvertently dropped in a later revision.

[00:44:41.0124] <sideshowbarker>
I’m intentionally avoiding to look at the existing code for any other implementations — so I can make sure it’s actually implementable as specced (without needing to make any assumptions that aren’t actually requirements)


2024-10-28
[14:38:08.0009] <Sam Sneddon [:gsnedders]>
where are time read _from_ a session history traversal queue (https://html.spec.whatwg.org/#tn-session-history-traversal-queue)? the synchronous ones are applied in the "apply the history step" (https://html.spec.whatwg.org/#sync-navigations-jump-queue), but where are the asynchronous ones read?

[14:38:14.0744] <Sam Sneddon [:gsnedders]>
 * where are items read _from_ a session history traversal queue (https://html.spec.whatwg.org/#tn-session-history-traversal-queue)? the synchronous ones are applied in the "apply the history step" (https://html.spec.whatwg.org/#sync-navigations-jump-queue), but where are the asynchronous ones read?


2024-10-29
[18:16:55.0574] <Domenic>
> <@gsnedders:mozilla.org> where are items read _from_ a session history traversal queue (https://html.spec.whatwg.org/#tn-session-history-traversal-queue)? the synchronous ones are applied in the "apply the history step" (https://html.spec.whatwg.org/#sync-navigations-jump-queue), but where are the asynchronous ones read?

https://html.spec.whatwg.org/#starting-a-new-session-history-traversal-parallel-queue step 2

[18:33:13.0331] <Sam Sneddon [:gsnedders]>
> <@domenicdenicola:matrix.org> https://html.spec.whatwg.org/#starting-a-new-session-history-traversal-parallel-queue step 2

somehow I missed that, doh! 🙂


2024-10-30
[18:18:12.0171] <sideshowbarker>
Luke Warlow (ooo): Wondering how come you didn't also end up being the one to do the Gecko implementation for Trusted Types

[03:15:49.0324] <Noam Rosenthal>
I was thinking about the `focusin`/`focusout` thing with `moveBefore`. Perhaps the right thing to do is to fire *only* `focusin`, and *only* if the element is indeed reparented (not e.g. reordered). 
We anyway don't fire `blur`/`focusout` when an element is removed

[03:16:11.0917] <Noam Rosenthal>
annevk: keithamus smaug WDYT?

[03:31:49.0744] <keithamus>
Seems reasonable to me. 

[03:54:56.0523] <bkardell>
> <@sideshowbarker:matrix.org> Luke Warlow (ooo): Wondering how come you didn't also end up being the one to do the Gecko implementation for Trusted Types

Not to answer for him, but work began somewhat in parallel so that would've been difficult 

[03:57:57.0613] <sideshowbarker>
> <@bkardell:igalia.com> Not to answer for him, but work began somewhat in parallel so that would've been difficult 

I see. Same ultimate funding source, though?

[03:59:01.0757] <bkardell>
Yes, unless I'm mistaken 

[03:59:52.0121] <freddy>
I think "no", but this does not seem to be the right forum to discuss :)

[04:02:06.0259] <bkardell>
freddy: you'd know better i guess 😊

[04:03:11.0643] <sideshowbarker>
> <@fbraun:mozilla.org> I think "no", but this does not seem to be the right forum to discuss :)

Yeah you're right — apologies for bringing it up here

[05:19:25.0453] <sideshowbarker>
> <@zcorpan:mozilla.org> sideshowbarker: though where does it say to use the `value`? i.e. where does the "3" come from? https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-number-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

https://github.com/LadybirdBrowser/ladybird/pull/2033/files#diff-09f2556b71c3f11db8fcda94914e8207e8268c667dc63a1aa6d2e906034439abR2236 is how I ended up implementing it. It implements what seems to be what the spec intends, if not strictly what the spec states.

That only implements the computation for the “embedded controls” cases. And for that I didn’t end up needing to consult the the HTML-AAM spec at all. I will when I need to implement handling for some cases like `button`, `summary`, `fieldset`, `table` — which I think the existing code doesn’t deal with at all yet but that I’ll get to when I start looking at whatever specific existing accname WPT test cases we have for those (if any)

[05:21:11.0723] <sideshowbarker>
> <@zcorpan:mozilla.org> sideshowbarker: though where does it say to use the `value`? i.e. where does the "3" come from? https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-number-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

 * https://github.com/LadybirdBrowser/ladybird/pull/2033/files#diff-09f2556b71c3f11db8fcda94914e8207e8268c667dc63a1aa6d2e906034439abR2241-R2312 is how I ended up implementing it. It implements what seems to be what the spec intends, if not strictly what the spec states.

That only implements the computation for the “embedded controls” cases. And for that I didn’t end up needing to consult the the HTML-AAM spec at all. I will when I need to implement handling for some cases like `button`, `summary`, `fieldset`, `table` — which I think the existing code doesn’t deal with at all yet but that I’ll get to when I start looking at whatever specific existing accname WPT test cases we have for those (if any)

[06:30:00.0581] <smaug>
Noam Rosenthal: I assume you mean also focus

[06:31:19.0714] <Noam Rosenthal>
> <@smaug:mozilla.org> Noam Rosenthal: I assume you mean also focus

Not necessarily because the important bit here is the bubbling, but open to that as well

[06:31:37.0367] <smaug>
Why is bubbling important?

[06:31:44.0520] <smaug>
Events have capture phase 

[06:32:24.0137] <Noam Rosenthal>
yea I guess `capture` matters just as much

[06:32:50.0506] <Noam Rosenthal>
I was thinking of `focusin` as where you'd put your general-purpose focus tree change catchers

[06:33:27.0424] <Noam Rosenthal>
but it's not material, I think re-firing focus/focusin (but not blur/focusout) when a focused element is reparented is reasonable-ish

[06:33:58.0451] <smaug>
(I'd assume focus listener being used for that more often. But I have no data to back up my guess 🙂 )

[07:25:55.0983] <Noam Rosenthal>
smaug: regardless of focus vs. focusin, WDYT of the idea of firing only the "in" part when reparenting a focused element?

[08:05:21.0431] <smaug>
I would say that is a bit surprising, but if removing focused element doesn't fire blur, probably fine. But for consistency, should focus/focusin first always when moving?

[08:25:03.0452] <Noam Rosenthal>
> <@smaug:mozilla.org> I would say that is a bit surprising, but if removing focused element doesn't fire blur, probably fine. But for consistency, should focus/focusin first always when moving?

well only if you're moving something focused

[08:26:09.0664] <Noam Rosenthal>
or you mean when reordering but not reparenting?

[09:03:18.0550] <smaug>
Noam Rosenthal: the latter.  Certain cases might rely on the ordering. Like styling

[09:03:44.0412] <smaug>
(and just having consistency is good in general)

[09:15:37.0590] <Noam Rosenthal>
SGTM

[10:37:11.0707] <Noam Rosenthal>
OK I agree it's a bit surprising, but it's perhaps the least error prone. we fire focus/focusin for a moved element, as if we've blurred and refocused it. No blur/focusout events. Also seeking feedback from annevk about this. Other option is still to not fire these at all and rely on userland


2024-10-31
[01:37:35.0709] <Maxim Vaarwel>
Good evening. Can anyone give some examples of opaque path? The URL spec is stingy on this.

[01:38:39.0950] <Maxim Vaarwel>
 * Good evening. Can anyone give some examples of [opaque path](https://url.spec.whatwg.org/#url-opaque-path)? The URL spec is stingy on this.

[01:39:54.0889] <Domenic>
> <@dmaxim:matrix.org> Good evening. Can anyone give some examples of [opaque path](https://url.spec.whatwg.org/#url-opaque-path)? The URL spec is stingy on this.

https://url.spec.whatwg.org/#example-url-components 3rd example

[01:43:57.0600] <Maxim Vaarwel>
Thanks but, I have extra question.

Is it possible to use the `new URL` constructor to create a url that will have opaque path in the first argument and base URL in the second?

[01:44:12.0801] <Maxim Vaarwel>
 * Thanks, but I have extra question.

Is it possible to use the `new URL` constructor to create a url that will have opaque path in the first argument and base URL in the second?

[01:45:52.0141] <Domenic>
Sure. `new URL("urn:isbn:9780307476463", "https://example.com/")`.

[01:49:40.0037] <Maxim Vaarwel>
> <@domenicdenicola:matrix.org> Sure. `new URL("urn:isbn:9780307476463", "https://example.com/")`.

The result of the URL structure is funny, there is nothing left from the base URL.

In any case, thank you very much for such a quick response.

[06:00:34.0783] <Noam Rosenthal>
> <@smaug:mozilla.org> (and just having consistency is good in general)

Perhaps a cleaner take on this would be to wait to fire this event till the next focusing steps, which would be at the next frame (latest). That way we don't bombard with events during DOM ops

[06:02:01.0691] <Noam Rosenthal>
Basically we mark the element as "moved while focused" and in the next focusing steps we use this flag to determine whether the event needs to be fired.

[07:31:35.0407] <Noam Rosenthal>
we don't even have to mark the element, just mark a boolean on the document and read it in the focus fixup

[07:31:50.0137] <smaug>
Not sure which one is easier to understand. Firing asap would be easier to implement, I think (and would be closer to the model focus() has). keithamus might have an opinion. (I don't have a strong opinion)

[07:32:35.0012] <Noam Rosenthal>
I think both would be easy to implement, or at least spec... my worry was having a batch of DOM operations with `moveBefore` inside that end up firing lots of events

[07:32:42.0032] <smaug>
oh, you'd clear the boolean if some other focusing is happening?

[07:32:46.0962] <Noam Rosenthal>
yea

[07:33:05.0819] <Noam Rosenthal>
well, if some other focusing is happening, the new element would get the focus and you'll get a blur

[07:33:33.0126] <smaug>
Are there cases when you do want to know asap if activeElement has changed?

[07:33:46.0997] <Noam Rosenthal>
you can check `activeElement`

[07:34:10.0452] <smaug>
but you don't get any notification it being changed

[07:34:11.0445] <Noam Rosenthal>
I think you can't really rely on this ASAP thing because focus fixup might change things

[07:34:46.0837] <Noam Rosenthal>
and one thing we reallly don't want to do is add forced style calculations

[07:35:53.0485] <Noam Rosenthal>
if you're in frameworks etc, you most likely are doing a batch of DOM operations and then the rendering step would come, you don't need multiple events during the batch

[07:37:16.0388] <Noam Rosenthal>
so I am pretty confident that "eventually" (as in, by the next frame or earlier) having your focus events catch up with your active element is good enough for people relying on these events. But happy to hear keithamus and others of course!

[07:39:06.0203] <smaug>
So document.querySelectorAll(":focus-within") would temporarily be broken?

[07:39:26.0766] <Noam Rosenthal>
yea, but it's temporarily broken today in many cases

[07:39:52.0920] <Noam Rosenthal>
though we can move the `:focus-within` flag synchronously, it's kind of a separate question

[07:40:20.0135] <smaug>
true

[07:46:14.0720] <smaug>
would it be weird to get key events for subtree which hasn't ever gotten focus event? (That might be an issue already in the spec, I need to check in which case the focus stuff run around rendering update)

[07:46:32.0899] <smaug>
 * would it be weird to get key events for subtree which hasn't ever gotten focus event? (That might be an issue already in the spec, I need to check in which case the focus stuff runs around rendering update)

[07:52:17.0513] <Noam Rosenthal>
I think you'd need a focus fixup before you can determine who gets the keys anyway

[07:52:53.0676] <Noam Rosenthal>
it would be weird if an element got `display: none` due to a DOM change but you received key events before calculating its style

[07:54:11.0971] <Noam Rosenthal>
the intermediate unfixed focus state is really only for javascript introspection

[07:54:27.0082] <smaug>
But that update doesn't need to happen during rendering update steps 

[07:54:47.0187] <Noam Rosenthal>
it can also happen due to calling `focus()`

[07:55:17.0619] <Noam Rosenthal>
but that forces a style calculation and would trigger the focusing steps

[07:55:18.0354] <smaug>
browsers try to dispatch key events before rendering update (or I'm not sure about webkit's scheduling)

[07:55:52.0911] <Noam Rosenthal>
so that would probably need a forced style calc and focus fixup like the one done inside update the rendering

[07:56:16.0809] <Noam Rosenthal>
(we're not adding anything new to that)

[07:56:21.0080] <smaug>
and we'd dispatch focus at that point?

[07:56:26.0472] <Noam Rosenthal>
yea

[07:56:30.0555] <smaug>
that might work

[08:00:08.0542] <Noam Rosenthal>
In HTML spec land, the change would be that when we run the focusing steps, if the target focus element is the current one and we haven't focused since moving the focused element, we first reset the current focused element to the viewport (as if that element was removed). This is simple enough and should cover all the weird cases I think

[08:28:57.0726] <keithamus>
Firing the event some time later seems okay to me. I think practical cases might be for eg wanting to hide UI if focus moves out. That kind of UI change isn’t really impacted by even microtask timing IMO. But not firing at all might break it.