2025-01-02 [16:40:45.0919] https://dom.spec.whatwg.org/#:~:text=Returns%20the%20event%E2%80%99s%20timestamp%20as,relative%20to%20the%20occurrence.%20 "Returns the event’s timestamp as the number of milliseconds measured relative to the occurrence." Is this incorrect as worded? The timestamp is relative to the Unix epoch. "Occurrence" sounds like it's the event occurrence. [01:44:56.0219] It's not relative to the epoch, it's monotonic time, initialized in https://dom.spec.whatwg.org/#inner-event-creation-steps #w3c:matrix.org [01:45:06.0663] * It's not relative to the epoch, it's monotonic time, initialized in https://dom.spec.whatwg.org/#inner-event-creation-steps [01:45:48.0356] I agree that the non-normative description for `timeStamp` can be worded better [06:17:26.0111] Happy New Year, WHATWG! I would appreciate some feedback on https://github.com/whatwg/fetch/issues/1601 (and not just from Anne). 🙏 [10:16:43.0823] Hi everyone, I wonder what are the accessibility concerns that are solved by making _non-modal_ [HTML] `dialog` elements themselves focusable? I am playing with one here on Firefox 133, and a focused `dialog` shown with the `show` method, focused through keyboard navigation, seems to offer absolutely nothing in terms of being focused. To explain, I have a form that is part of the dialog, with `method="dialog"` so that the [submit] buttons in the form close the dialog, and the first button is focused initially when the dialog is shown, as expected, and I have zero issues with that. It's when I "tab" myself backwards and the focus switches to the dialog element itself, that got me thinking -- what is the use for that, and shouldn't I, in this case, add a `tabindex="-1"` to the dialog element? 2025-01-03 [08:30:23.0993] Happy new year everyone! I opened a PR to node.js to add URLPattern https://github.com/nodejs/node/pull/56452 2025-01-06 [02:06:11.0138] > <@akaster:serenityos.org> Is there a meaningful difference between an `optional any` argument being _missing_ vs being the value `undefined`? https://github.com/WebAssembly/spec/issues/1861 I explained how the spec matches the test in the issue [10:02:55.0123] Deborah Sollman: [13:19:15.0970] ?? 2025-01-07 [20:14:29.0627] Idk what the f I’m doing 😩😩 2025-01-09 [00:58:31.0539] If an HTML document is served with a `Content-Type: text/html` without a `charset` parameter, but with ``, then the spec requirements are that UAs must respect the `` — and use `shift_jis` as the character encoding, right? [00:58:45.0380] I’m specifically looking at https://www.ntt-west.co.jp/news/1504/150417a.html [01:02:24.0777] * If an HTML document is served with a `Content-Type: text/html` HTTP header — without a `charset` parameter — but with a `` element, then the spec requirements are that UAs must respect the `` element — and use `shift_jis` as the character encoding, right? [01:15:02.0881] * If an HTML document is served with a `Content-Type: text/html` HTTP header — without a `charset` parameter — but with a `` element, then the spec requirements are that UAs must respect the `` element — and use `shift_jis` as the character encoding, right? [01:15:59.0344] sideshowbarker: yup. [01:16:46.0768] A BOM can override all technically, but that website does not appear to have one. [01:19:51.0000] OK, the https://webirc.w3.org/ client (which is an instance of https://thelounge.chat) seems to not handle the encoding properly — even regardless of whether it’s set in the Content-Type header [01:20:32.0758] That client does previews of any link you post — just as Matrix does here [01:21:37.0694] https://www.w3.org/2025/tests/shift_jis-encoding.html is a demo of the same document, but with a proper `Content-Type: text/html; charset=shift_jis` HTTP header. But in TheLounge, the preview for it is mojibake [01:23:29.0577] Anyway, maybe I’ll try to write a patch for it. That Lounge is otherwise a really great client. Among other things, it enables you to stay on an IRC channel persistently — even after you close the browser tab, or close the browser. Like IRCCloud or whatever [03:54:23.0022] Good Day to all. I am new to coding as well as this community. [03:56:58.0994] I have trying to copy iframe from youtube source and executing in html coding. the frame is showing but video unable to view. if i paste the url again in second line , then the second line video shows properly. May i know how i have to recitfy this. [10:46:47.0861] This server is about developing HTML and related web standards. For technical coding questions, please ask on Stack Overflow or other dev-focused communities. 2025-01-10 [04:26:45.0181] Can you please tell me how I can test this step from the specification of the [create and initialize a Document object](https://html.spec.whatwg.org/#initialise-the-document-object) algorithm? > If browsingContext's active document's is initial about:blank is true, and browsingContext's active document's origin is same origin-domain with navigationParams's origin, then set window to browsingContext's active window. [04:27:07.0085] * Can you please tell me how I can test this step from the specification of the [create and initialize a Document object](https://html.spec.whatwg.org/#initialise-the-document-object) algorithm? > 6. If browsingContext's active document's is initial about:blank is true, and browsingContext's active document's origin is same origin-domain with navigationParams's origin, then set window to browsingContext's active window. [06:26:45.0825] Maxim Vaarwel: I think with https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13378 [06:28:20.0299] Chrome, Firefox: true Safari: undefined [06:29:12.0892] https://html.spec.whatwg.org/#evaluate-a-javascript:-url [06:48:24.0922] Interesting. Are there any other examples besides executing javascript in the search bar? [06:51:19.0881] * Interesting. Are there any other examples besides executing javascript in the URL? [07:00:02.0000] I think javascript: url is the only case where the document is swapped. But you could detect it in other ways, e.g. OAC [07:06:18.0569] I tried iframes, storing different properties in the window object. But I could not find a single case where the window object matches when loading a new document, as in your case. What does OAC mean? 2025-01-11 [01:40:56.0973] There are ways to test that without JS URLs. The 2-documents 1-Window horribleness is much more broad-reaching than that, I think... let me find some old threads... [01:42:35.0113] Ah it's coming back to me, this can be tested by using global variables and watching them stick around... [01:43:01.0266] https://github.com/whatwg/html/issues/3267 [01:45:01.0064] https://github.com/web-platform-tests/wpt/blob/master/html/browsers/the-window-object/window-reuse-in-nested-browsing-contexts.tentative.html and the tests in https://chromium-review.googlesource.com/c/chromium/src/+/804797 [01:48:58.0995] I seem to remember needing to use global `var` declarations for something related to this, to test `Window` vs. `WindowProxy`, but those tests above don't seem to be bothering with that. [04:18:20.0765] Yeah, I've seen some of those links. But I haven't looked at wpt tests before your post. I ran tests on chrome and firefox. Chrome fails almost everything, but firefox isn't perfect either, although it passes almost all the tests. Thanks for the links and help. 2025-01-12 [15:53:41.0505] zcorpan: (or anybody else set up to do HTTP Archive queries) Can you do query to find out how many pages have `shift_jis` (lowercase) in the `` or `` values? Or in the `Content-Type` header? 2025-01-13 [16:13:53.0054] zcorpan: Or actually, not just lowercase but case-insensitive for the standard `Shift_JIS` — also (case-insensitive) `shift-jis` [16:14:01.0765] Context is https://github.com/thelounge/thelounge/pull/4951#discussion_r1912529404 [01:33:43.0427] Do you have a REGEXP handy? I checked "]+(charset|content)=\"shift[_-]jis\"" on response bodies in November, got 1333 out of 672M [02:59:35.0159] That regexp looks right [03:01:41.0640] I guess the lowercase shift_jis is relatively rare. Maybe a Shift_JIS query would return a lot more hits [03:32:15.0167] `SELECT COUNT(*) FROM `httparchive.response_bodies.2024_11_01_desktop` WHERE REGEXP_CONTAINS(response_body, "]+(charset|content)=\"SHIFT[_-]JIS\"")` returned 32 [04:34:01.0258] Thanks — how about just `Shift_JIS` (that is, `Shift` rather than `SHIFT`) [05:09:07.0329] With ignore-case it's 3769 [05:09:22.0415] Thanks much! [06:20:12.0161] Hmm, what is the odd white box (when using dark mode) in the warning here: https://html.spec.whatwg.org/#interaction-with-details-and-hidden=until-found [06:23:40.0869] It's an image of a fingerprint as a link to somewhere. Bit odd it covers content though. Probably needs a darkmode-aware class adding to the img. [06:56:41.0814] Origin-Agent-Cluster. See the "otherwise" steps in the spec 2025-01-14 [19:00:55.0145] Oh, I thought https://github.com/whatwg/wattsi/pull/161 would fix this... [19:39:18.0945] not also fixed in bikeshed yet, maybe? [20:22:25.0747] Yes, TabAtkins fixed it for bikeshed in https://github.com/speced/bikeshed/commit/72e42de7d16654bc6059cf0d622d14d4035fe536 [21:40:51.0253] Maybe HTML's stylesheet doesn't do the darkmode-aware thing? Although I thought that part was shared between HTML and Bikeshed specs. [22:10:31.0839] The fix there is in the markup of the image itself, html is using its own file. [01:55:24.0739] HTML uses https://resources.whatwg.org/tracking-vector.svg which responds to dark mode. But the `img` needs `class=darkmode-aware` [01:59:02.0898] But now I'm confused why it doesn't - https://github.com/whatwg/wattsi/blob/main/src/wattsi.pas#L1695 [02:48:18.0422] zcorpan: I was thinking about the async-CSS discussion... `font-display: swap` is a valid use case (though I personally really dislike that UX) I thought of an option to add ``, where `rel=font` would be non-blocking, but only allow font-descriptors [02:49:56.0552] Noam Rosenthal: I assume people use the onload hack for more than fonts [02:52:35.0323] zcorpan: for that, I thought to have `` where the stylesheet would load, but would only apply when we see an element with that ID [02:53:11.0397] zcorpan: I kind of see these as separate use-cases, where in one of them you actively opt-in to an FOUT and in the other one you probably don't want it but you don't know when the element will come [02:53:20.0889] * zcorpan: I kind of see these as separate use-cases, where in one of them you actively opt-in to a FOUT and in the other one you probably don't want it but you don't know when the element will come [02:54:13.0884] If we had a general `async` people would use it for "below the fold" and then they'd have a FoUCy race between scrolling and CSS loading [02:55:42.0581] * zcorpan: I kind of see these as separate use-cases, where in one of them you actively opt-in to a FOUT and in the other one you probably don't want it but you don't know when the content will come [02:55:56.0490] Would the parser block on that stylesheet when it sees an element with `some-id`? [02:56:02.0953] yes [02:57:13.0060] Interesting, so same effect as putting the link just before that element (in chromium currently), but you can do it from `head` [02:57:21.0312] exactly [02:58:53.0725] That seems reasonable, at least if webkit and gecko are onboard with the general stylesheets block the parser thing [02:59:21.0455] zcorpan: also render-blocking rather than parser-blocking at that point would be non-FoUCy [02:59:59.0041] though probably it would mean freezing the entire frame, might be worse UX than parser blocking where JS still runs [03:01:02.0872] Right we don't currently block rendering after the first paint, and might cause issues to start freezing what the user sees [03:01:33.0886] I want to see from he thread if more use cases come up. So far we've heard of: 1. `font-display: swap` 2. Non-critical/below-the-fold CSS, where for several reasons the dev can only put stylesheets in the head [03:03:32.0826] I think things that are initially hidden could be a use case. For that, ideally you don't want to block the parser, since that would hold up anything after the non-critical widget [03:04:18.0658] zcorpan: yea but you probably want to block the JS that allows showing them [03:04:32.0055] Otherwise you're racing between the interaction that shows them and the CSS loading (FoUC again)O [03:05:55.0124] Yeah. So if `for` points to a script element, wait with running that script until the stylesheet is loaded? (The script could be `async`) [03:09:14.0126] zcorpan: Yea, parser-blocking would do that automatically. Or alternatively, `import` the style from the script and adopt it [03:18:07.0253] Thought: Maybe in the future this could be extended to a behavior where the target element is not parser-blocked, but instead received `display: none` until its stylesheet is loaded. So you'd have those elements appearing asynchronously, but at least each of them would be fully styled [03:28:02.0824] smaug: were you planning on looking at `moveBefore()` once more before it lands? [03:29:00.0773] yes [03:29:11.0842] I was out sick last week [07:19:46.0847] Domenic: I looked a bit more at the prerender code in WebKit we found a long time ago and it turns out that visibilityState at some point supported a prerender value. It's related to that. [08:50:46.0736] I keep seeing people get surprised by the fact that microtasks are not run after callbacks, when JS is on the stack (i.e., user-dispatched events for example). Sometimes it's discussed as a problem that hopefully we can "fix" someday. I'm sure it's intentional, but it is weird and confusing. I haven't thought about it too too much, but is there any appetite / possibility to change this? Any ideas how incompatible it would be? [08:52:11.0435] I imagine it'd lead to very observable differences, but I wonder if we'd be in a better state if we changed it. I don't have a good reason except for "consistency", with the caveat that changing it might introduce other inconsistencies [08:52:47.0521] You should check with server-side runtimes (Node.js, Deno...) because they write most of the runtime's code in JS, and they have in a sense the opposite problem, in that if some runtime-internal JS code runs multiple callbacks, the microtasks would only get run at the end [08:53:49.0843] That said, making all callbacks behave the same way would also make it easier for them, even if it would mean manually triggering a microtask checkpoint [12:03:12.0388] Funnily enough this is something that I've been digging into a litle recently trying to figure out all of the ins and outs of when microtask checkpoint should be run. E.g with how spin the event loop empties the event loop. And the observability of invoking 'spin the event loop' to implement 'Wait for X', since that performs a microtask checkpoint. [12:36:35.0273] Is "Sec-WebSocket-Extensions: permessage-deflate" mandatory? https://github.com/whatwg/websockets/issues/63 [12:39:58.0220] Dominic Farolino: We can't empty the microtask queue after the existing `dispatchEvent`, it would be web breaking... The only reason to do that is to be able to call `stopPropagation` in a microtask (as user-dispatched events don't have `preventDefault`). [12:43:42.0817] What I would want to have is something like `EventTarget.nextEvent(eventType)` that calls `addEventListener` with `once` and returns a promise... but it would need some mechanism to be able to stop propagation synchronously because of those `dispatchEvent` scenarios [15:30:19.0628] Noam Rosenthal: I'm quite confused by this message about `nextEvent`. If you init your event as `cancelable` then you can very well call `preventDefault()` on it, it even sets the return value of `dispatchEvent()`. Also I'm not sure how `stop[Immediate]Propagation` would be an issue for a `nextEvent()`, which I assume would be a kind of "after non-capture" phase, and would thus possibly only prevent other `nextEvent()` listeners. Or did you envision a second round of the whole dispatching with all 3 phases? The issue I see would actually be with the return value of `dispatchEvent()`, and maybe it's what you were hinting at? Dispatchers could wait for one more microtask before checking the event's `defaultPrevented` but that seems indeed problematic that listeners don't know if the dispatcher will receive the info in time. 2025-01-15 [22:46:12.0933] > <@kaiido:matrix.org> Noam Rosenthal: I'm quite confused by this message about `nextEvent`. If you init your event as `cancelable` then you can very well call `preventDefault()` on it, it even sets the return value of `dispatchEvent()`. Also I'm not sure how `stop[Immediate]Propagation` would be an issue for a `nextEvent()`, which I assume would be a kind of "after non-capture" phase, and would thus possibly only prevent other `nextEvent()` listeners. Or did you envision a second round of the whole dispatching with all 3 phases? > The issue I see would actually be with the return value of `dispatchEvent()`, and maybe it's what you were hinting at? Dispatchers could wait for one more microtask before checking the event's `defaultPrevented` but that seems indeed problematic that listeners don't know if the dispatcher will receive the info in time. I haven't thought of all the details here, just that something that turns "once" events into promises could be useful in some scenarios [22:59:13.0997] Yes, I completely agree, but I didn't understand the concerns you expressed. [23:40:48.0488] Kaiido: I was referring to the fact that calling something like `const event = await nextEvent("my-event"); event.stopPropagation()` wouldn't work because the event would already have been propagated at that point [23:44:09.0877] Thinking that `nextEvent` could return something `PromiseLike` instead of a `Promise`, with both `then` and e.g. `preprocess` So or something where the `then` is synchronous, e.g. `const event = await nextEvent("name").then({ e => e.stopPropagation(); return e; });`, and `await nextEvent("name")` would just work. Though we can probably come up with better ergonomics [00:11:15.0675] But you could still prevent the propagation to the next handlers added through later `nextEvent()`. It's basically like how you can't expect `stopPropagation()` in the bubbling phase will prevent the handlers in the capturing phase. It makes sense that `nextEvent()` would be its own phase. [00:33:03.0704] Kaiido: sure, it's a potential way to look at this. [09:59:39.0098] Dominic Farolino: smaug probably recalls the rationale for not draining microtasks when JS is on the stack. I don't. In any event we might want to clarify it in the HTML standard. [10:07:56.0299] The whole point of microtasks is that they are handled at the end of outermost script execution. The idea being that it is effectively end of "your" script when your MutationObservers are handled. Big(est) reason for that is performance, basically trying to batch as many mutation as possible, yet not mix microtasks from different event listeners or so. [10:11:32.0391] Microtasks were designed for MutationObserver, and I'm not sure anyone ever really thought through how well they work with Promises and such. [10:15:16.0158] * Microtasks were designed for MutationObserver, and I'm not sure anyone ever really thought through how well they work with Promises and such (Promises started to use them later). [10:51:32.0616] * Microtasks were designed for MutationObserver, and I'm not sure anyone ever really thought through how well they work with Promises and such (Promises started to use them later). Microtasks were possibly just good enough for Promises. [10:55:42.0697] * Microtasks were designed for MutationObserver, and I'm not sure anyone ever really thought through how well they work with Promises and such (Promises started to use them later). Microtasks were possibly just good enough for Promises. And it would have been probably quite confusing to have microtasks for MutationObserver and something almost-microtasks for some other use cases. [11:43:36.0476] * The whole point of microtasks is that they are handled at the end of outermost script execution. The idea being that it is effectively end of "your" script when your MutationObservers are handled. Big(gest) reason for that is performance, basically trying to batch as many mutation as possible, yet not mix microtasks from different event listeners or so. [11:43:45.0707] * The whole point of microtasks is that they are handled at the end of outermost script execution. The idea being that it is effectively end of "your" script when your MutationObservers are handled. Big(gest) reason for that is performance, basically trying to batch as many mutations as possible, yet not mix microtasks from different event listeners or so. 2025-01-16 [16:18:17.0629] Huh, yeah, that's confusing. I don't know enough about wattsi to debug that. [16:48:25.0539] I remember I did test locally when pushing that change and it did work, in fact, running *html-build* `build.sh --remote` on my machine today does generate the proper class and renders fine for me. The issue might be in the building-pipes. [17:41:54.0406] Hmmm probably it's because https://github.com/orgs/whatwg/packages?repo_name=html-build doesn't rebuild after Wattsi improvements [17:41:59.0635] I thought we had an open issue on that somewhere [17:42:43.0578] I wish I knew Docker well enough to know how this is supposed to work [17:43:20.0150] Like ideally html-build would have some minimum wattsi version in a file (like Node.js package.json or similar) and we could bump that file and that would force a rebuild. [17:44:26.0087] But right now the html-build -> wattsi dependency is expressed via https://github.com/whatwg/html-build/blob/main/ci-build/Dockerfile#L28 (`COPY --from=ghcr.io/whatwg/wattsi:latest`) which is good if html-build and Wattsi are both revved frequently but not good in this case. [17:44:53.0641] I believe docker-compose is possibly the relevant tool here but I have not learned it or how to integrate it into our GitHub actions pipeline... [23:58:29.0080] Domenic: https://github.com/whatwg/html/pull/10737 strictly speaking doesn't have multi-implementer interest [23:59:08.0384] Oh no :(. When someone tells me "ping, all the boxes are checked" on a PR that's been open for months, I'm inclined to take them at their word :( [23:59:12.0765] I see now that was a mistake [23:59:30.0498] I think this is the second time this has happened with Mason. I suggest to no longer do that with him. [23:59:38.0341] Ugh wow that box is definitely checked in error, yeah [00:00:07.0811] Should we revert? [00:00:50.0670] I think it's probably okay, unless Mozilla has some objection to it. Need to think about it a bit more. [00:01:00.0585] smaug: zcorpan: ^^ [00:29:26.0462] One related thing to microtasks/promises... I encountered a few times the issue that if you `resolve` a promise from platform code, the promise reactions would only run at the end of the task. This is confusing if you have a task that does multiple things that might have reactions or callbacks, like the rendering task. I thought to generalize it where HTML would have its own `resolve` that resolves the promise inside a "run/cleanup script" scope and specs should be calling that instead of the WebIDL resolve. Wonder what smaug / Domenic think about this [00:30:51.0884] Kinda like what I had to do in step #5 of https://html.spec.whatwg.org/multipage/browsing-the-web.html#reveal [00:33:39.0563] From the perspective of how they were introduced for mutation observers, it would seem bad if you don't delay them until the end of rendering, as the reactions might incur new things that require rendering. [00:34:21.0184] but we already do that when firing events [00:36:02.0501] also each rAF callback clears the microtask queue and might incur new things that require rendering etc... [00:36:51.0901] Well yes, but that's why we moved from mutation events to mutation observers. So to then suggest that promises should work like events feels a bit backwards. [00:37:32.0721] If you don't want promise-timing, don't use a promise. [00:40:33.0373] Sometimes promises are there because of ergonomics, not because of anything to do with timing [00:41:28.0993] To be clear, I don't think this would change anything existing in the platform. Apart from view transitions, all the other `resolve` calls are one-per-task [00:41:50.0469] (AFAICT) [00:41:51.0682] How would it not change the timing of promises already on the queue? [00:44:01.0415] There should not be any promises in the queue, only platform microtasks such as mutation observers. But it doesn't matter, because in 100% of uses of resolve today this would be a noop [00:44:55.0844] ... because today all the uses of `resolve` *only* resolve during the task, so at the end of the resolve you'd get the event loop's microtask checkpoint [00:52:21.0546] I don't understand that sentence. You can only call resolve during a task. [00:52:31.0847] yes, but no spec does that in practice [00:52:50.0868] They do? [00:52:53.0324] I mean, no spec calls resolve and then does something else that calls user code in the same task, AFAICT [00:53:11.0318] it's usually "queue a task to resolve" [00:53:28.0497] I think there's plenty of examples of events or callbacks and promises all being handled in one sweep. [00:53:34.0935] As they should. [00:54:24.0103] not sure about it, but will go through the specs, maybe my assumption here is wrong [00:55:11.0813] There's also plenty of cases where a promise is rejected immediately. Which happens during whatever call did the wrong thing according to IDL. [00:55:21.0968] sure [00:56:59.0354] ok, perhaps this is not going to work. Thanks for the clarification [01:13:12.0329] The cases I am concerned about which are adjacent to (or the same as?) the ones Noam Rosenthal is discussing are the ones where promises and event firing are next to each other, and thus the existence of event handlers can change the ordering. See https://html.spec.whatwg.org/#note-suppress-microtasks-during-navigation-events . In such cases we can manually add something to the stack to *prevent* promises from immediately resolving when the events are fired. That seems OK as it makes the promises more delayed. It's only happened a couple of times so far so we haven't needed to do it more generally. [01:14:27.0068] I think Noam's case is basically the same as mine. [01:15:01.0267] I don't really know how to generalize it though; just wrapping the resolve in run/cleanup a script wouldn't work. You need wrap both the "fire an event" and the "resolve". [01:21:41.0819] Yea these timing gotchas are not trivial at all to an outside spec to deal with. But not sure what the right solution is [01:55:09.0913] Domenic: can't you fire the event and then resolve? [05:21:41.0141] Given both WebKit and Mozilla track standards positions in public GitHub issues, do you think it is worth adding some tooling to PRs to scrape the API and check that A) an issue is supplied linking to the standards position of those respective vendors and B) that issue has the correct label on it, marking the vendor as supportive? [05:22:32.0710] It could be a CI check that fails a PR unless it is able to successfully confirm that each vendor is indeed supportive, reducing the human error involved. [05:26:46.0247] > <@keithamus:matrix.org> It could be a CI check that fails a PR unless it is able to successfully confirm that each vendor is indeed supportive, reducing the human error involved. One issue with this is sometimes a spec PR is to match implementations and in that case you wouldn't want to raise the issues. But possibly that could be handled with labels? [05:28:14.0023] I imagine the option to skip those checks could be added via a checkbox saying "standards positions aren't necessary for this", which would pass the check but could provide a signal to the editors merging that this _hasn't_ gone through standards positions [06:50:25.0978] keithamus: I wouldn't be opposed to that being available, but as I clarified at some point WHATWG uses "implementer interest" which is quite informal (though you do need to actually have someone say it). Going through standards-positions to obtain that is fine, but it's not required. [06:51:16.0065] that makes sense. Perhaps it would be too much then. [08:13:54.0926] Is there any documentation or issues to read about how moveBefore interacts with stuff like mutation observer? [08:25:41.0988] https://github.com/whatwg/html/pull/10904/files moves a bunch of text and then makes some tweaks. Is there a good way to highlight the changes? I guess copy-and-paste it all and do a manual diff? [08:56:30.0683] Hey, both I and nicolo-ribaudo wanted to join today's WHATNOT meeting to talk about the web integration AsyncContext, and we don't have an invite [09:02:39.0497] Figured it out [10:01:28.0196] Andreu Botella: is there a comment/document somewhere explaining this new design and in particular why it was changed? [10:03:07.0948] Andreu Botella: FWIW, I'm still super worried about any implicit context capture (assuming I understand the proposal correctly). That kind of things tend to cause leaks. [10:03:44.0040] > <@annevk:matrix.org> Andreu Botella: is there a comment/document somewhere explaining this new design and in particular why it was changed? There was feedback from a number of folks, but some of that happened in a meeting and there isn't a lot in the PR or issues. Check out Aug 20 in https://docs.google.com/document/d/1pi-NMbqVhg2UuxQAZ4jOGDeHLlZGD_DJ7fyxHt_C2hs/ though [10:04:31.0733] > <@smaug:mozilla.org> Andreu Botella: FWIW, I'm still super worried about any implicit context capture (assuming I understand the proposal correctly). That kind of things tend to cause leaks. Most of the implicit context capture in the previous proposal is gone. What's left now is similar to what the TC39 proposal would do for `await`s and `.then` [10:05:25.0322] So how would DOM callbacks deal with this then? I'm a bit confused. The proposal talks about "associating state implicitly " [10:06:21.0181] I think this is clearer in https://github.com/tc39/proposal-async-context/pull/109 [10:07:00.0057] For things like `setTimeout`, you'd store the context with the callback, and get rid of it afterwards (or for `setInterval`, when it gets canceled) [10:07:50.0492] Ok, so context is stored implicitly with the callback? [10:09:21.0934] > <@smaug:mozilla.org> Ok, so context is stored implicitly with the callback? not for every callback, only for APIs that take a callback and schedule it at some later point [10:09:40.0906] event listeners would not store the context [10:09:49.0688] Andreu Botella: for a change of this magnitude I'd expect a bit more. I mean I gave feedback too, but that apparently has been dismissed now. [10:09:53.0733] The difference is that now we capture implicitly for callbacks that are going to be run (unless explicitly cancelled) and not for things that _may run_ like event listeners (where you don't know if it's ever going to be triggered again, so you can't capture the context) [10:10:38.0334] * The difference is that now we capture implicitly for callbacks that are going to be run (unless explicitly cancelled) and not for things that _may run_ like event listeners (where you don't know if it's ever going to be triggered again, so you can't ever free the context) [10:20:29.0973] To avoid misunderstandings: this proposal talks about propagating the context implicitly, as a way to frame the expected behavior for context passing. This could be implemented by changing the way task queueing and "in parallel" work in engines, but for the initial rollout we propose only exposing things that could be implemented in other ways. [10:21:29.0577] You could implement/spec `setTimeout` as implicitly passing the context to the "in parallel" code, and then implicitly passing that same context to the queued event loop task [10:21:36.0557] Or you could store the context with the callback [10:22:21.0140] I don't think this is a change from what we discussed in TPAC [10:26:39.0321] I'm not sure I was at the discussion at TPAC, but I'm pretty sure I gave feedback that per-thing handling feels extremely error prone. [10:27:01.0938] Especially for events. [10:33:54.0853] > <@annevk:matrix.org> I'm not sure I was at the discussion at TPAC, but I'm pretty sure I gave feedback that per-thing handling feels extremely error prone. Well, I'm talking about the informal side chats. About per-thing handling, I guess you mean having to know which events have a sync or async dispatch and so on? I think we might be able to spec that such that this doesn't rely on something like a list of events [10:34:33.0296] but for the initial rollout, there would be a very small list of events that would be special-cased so the context does propagate for those [10:34:49.0054] because that can be implemented without the implicit tracking [11:34:34.0318] Andreu Botella: It is quite confusing to have some callbacks work in certain way and other in some other way. And for example idle callbacks aren't guaranteed to be run, even though the are "scheduled". Nothing ensures there is idle time ever. [11:36:04.0409] (I'm just super concerned about memory leaks here, just given, as an example, the massive leaks Youtube fixed couple of days ago. At least some of them were exactly about capturing certain things semi accidentally and keeping them alive for too long) [11:40:13.0373] > <@smaug:mozilla.org> Andreu Botella: It is quite confusing to have some callbacks work in certain way and other in some other way. And for example idle callbacks aren't guaranteed to be run, even though the are "scheduled". Nothing ensures there is idle time ever. For the behavior of callbacks, the underlying behavior should be the same as implicit propagation. Different APIs have different behavior, because they do different things on the way to calling the callbacks [11:41:56.0998] Well, "the same as implicit propagation" isn't strictly true, because multiple rAF callbacks can be scheduled on the same event loop iteration, but you'd still want each to propagate its own context [11:42:11.0426] but it's a similar concept [11:42:39.0531] * Well, "the same as implicit propagation" isn't strictly true, because multiple rAF callbacks can be scheduled on the same event loop iteration (or the same task in some implementations), but you'd still want each to propagate its own context [15:49:35.0561] This discussion of "for the initial rollout" seems scary; I cannot imagine changing this sort of thing after it's shipped. [15:50:01.0691] I would prefer the final semantics are worked out ahead of time, as part of the "initial rollout". 2025-01-17 [16:39:54.0290] Hey [23:23:31.0246] > <@domenicdenicola:matrix.org> I would prefer the final semantics are worked out ahead of time, as part of the "initial rollout". That would mean analyzing essentially the whole set of events across the whole web platform, and would probably mean the whole implicit context propagation would need to be implemented from the beginning in browsers, which might result in interoperability bugs because the exposed surface is huge and it might be really easy for interoperability bugs to creep in [23:25:15.0671] Also, the set of events we're considering for the initial rollout are ones for which we have use cases at this point, but there might be other use cases that haven't been brought up yet [23:26:10.0931] One common thing with AsyncContext is that since much of the goal is for third-party code to be able to pass state seamlessly across first-party code, it's hard to know which events the context should propagate through, because the first-parties are not involved in the conversation [23:30:38.0266] I mean, saying people might implement it wrong and therefore we should implement it piecemeal is not generally how we do things on the web platform. We can't trade hypothetical interoperability bugs now for definite compatibility bugs later. [03:49:42.0222] I am quite confident that there will be interoperability bugs because we're making things observable that so far have been unobservable [03:49:56.0640] but fair enough [05:11:41.0020] I guess what you're saying is that this new feature might build upon some existing infrastructure that might not match the envisioned behavior? But that's really an argument for writing sufficient tests. Not for delivering only part of the feature. 2025-01-20 [01:33:36.0049] TabAtkins: I like the (new?) markup checker in Bikeshed. Already identified valid issues in DOM and Infra and nothing bogus thus far. [06:56:11.0409] > <@annevk:matrix.org> TabAtkins: I like the (new?) markup checker in Bikeshed. Already identified valid issues in DOM and Infra and nothing bogus thus far. Nice, that's precisely what I was hoping for. Saw a lot of little errors in the test suite. [06:56:22.0144] And yeah, brand new, haven't written up the release notes yet [06:56:50.0288] If anything bogus does come up just file an issue 2025-01-21 [18:29:18.0953] All sorts of good Bikeshed stuff being detected now. This is a fun one... https://github.com/whatwg/xhr/actions/runs/12878961165/job/35905693141?pr=394 [02:16:24.0775] I think that one was probably identified already and I caused that to happen when I redid "clone a node". [09:15:42.0023] Yeah that error isn't from anything new, it's just an ordinary ambiguous link