2024-06-01 [23:35:07.0599] Hello, could someone tell what does mean: > The insertion point is relative to the position of the character immediately after it, it is not an absolute offset into the input stream. Why not absolute? [23:52:04.0191] PSA: About https://git-pulse.github.io/snapshots/ — a while back I added the WebKit repo to the set of repos it tracks, and yesterday I added the https://github.com/chromium/chromium mirror and https://github.com/mozilla/gecko-dev mirror. The Chromium and Gecko mirrors don’t use GitHub for patch reviews, so the PR stats for them aren’t relevant — but the committer stats are. And the [Chromium numbers](https://git-pulse.github.io/snapshots/chromium-chromium-2024-05-31-pulse.html) are [so exceptional](https://git-pulse.github.io/snapshots/?project=chromium_chromium) that it makes me wonder if what my tool is seeing and reporting is actually accurate — - 13131 commits to main per month - 1310 unique committers per month - 11738 total unique committers over the entire repo history - 49 unique new first-time committers each month [23:55:40.0448] * PSA: About https://git-pulse.github.io/snapshots/ — a while back I added the WebKit repo to the set of repos it tracks, and yesterday I added the https://github.com/chromium/chromium mirror and https://github.com/mozilla/gecko-dev mirror. The Chromium and Gecko mirrors don’t use GitHub for patch reviews, so the PR stats for them aren’t relevant — but the committer stats are. And the [Chromium numbers](https://git-pulse.github.io/snapshots/chromium-chromium-2024-05-31-pulse.html) are [so exceptional](https://git-pulse.github.io/snapshots/?project=chromium_chromium) that it makes me wonder if what my tool is seeing and reporting is actually accurate — - 13131 commits to main _per month_ - 1310 unique committers _per month_ - 11738 total unique committers over the entire repo history - 49 unique new first-time committers each month 2024-06-03 [01:28:17.0853] sunil: I don't know. [01:40:43.0573] sunil: I think you're correct that it's supposed to work although I'm not sure to what extent we actively considered shared/service workers at the time. I don't recall. [01:42:20.0539] Thanks annevk, Do you know who could have more idea on this? [01:45:25.0990] annevk: I am implementing this in Firefox and trying to check if it would be helpful to extend the wpt to service workers as well. It wouldn't add much value if other browsers do not fully support it for workers though. [02:35:03.0285] > <@sideshowbarker:matrix.org> PSA: About https://git-pulse.github.io/snapshots/ — a while back I added the WebKit repo to the set of repos it tracks, and yesterday I added the https://github.com/chromium/chromium mirror and https://github.com/mozilla/gecko-dev mirror. > > The Chromium and Gecko mirrors don’t use GitHub for patch reviews, so the PR stats for them aren’t relevant — but the committer stats are. And the [Chromium numbers](https://git-pulse.github.io/snapshots/chromium-chromium-2024-05-31-pulse.html) are [so exceptional](https://git-pulse.github.io/snapshots/?project=chromium_chromium) that it makes me wonder if what my tool is seeing and reporting is actually accurate — > > - 13131 commits to main _per month_ > - 1310 unique committers _per month_ > - 11738 total unique committers over the entire repo history > - 49 unique new first-time committers each month These numbers seem pretty believable to me. [03:06:46.0596] sunil: I suspect the most straightforward way to find out is to write those tests and run them [03:07:28.0294] > <@domenicdenicola:matrix.org> These numbers seem pretty believable to me. OK — good to have that confirmation. And I’m glad now to have finally added the repo to set that tool monitors. The numbers are more interesting relative to other projects (beyond just the absolute numbers) [04:03:10.0013] About the test at https://wpt.fyi/results/inert/inert-and-find-flat-tree.html — question: is _“Text inside a dialog inside a shadowroot”_ defined as inert per-spec? [04:04:14.0417] correction: “Text _slotted into_ a dialog which is inside a shadowroot should be findable” defined as inert? [04:04:24.0203] * correction: Is “Text _slotted into_ a dialog which is inside a shadowroot should be findable” defined as inert? [04:04:36.0759] * correction: Is “Text _slotted into_ a dialog which is inside a shadowroot” defined as inert? [04:06:44.0993] * About the test at https://wpt.fyi/results/inert/inert-and-find-flat-tree.html — question: is _“Text inside a dialog inside a shadowroot”_ defined as inert per-spec? [04:10:31.0168] Luke Warlow: ↑ (if you happen to know — since I think you may have recently been working on something that you were running the inert test cases to check against) [04:18:21.0565] Apologies I'm not sure about that, I think the inert test I was looking at was using a test driver API that was changed. So it was tangential to the inert spec [12:16:17.0702] Hello, what would be equivalent in browser's `fetch` to what nodejs `undici` supports with `dispatcher: new Agent({ bodyTimeout: 0 })`. This way one can disable the default 300s body timeout. I have an example of long lived streaming responses which I would also like to have working in the web browser https://github.com/elf-pavlik/sosy24/blob/main/streaming-http.mjs [12:18:43.0857] relevant `undici` docs https://undici.nodejs.org/#/docs/api/Dispatcher?id=parameter-dispatchoptions 2024-06-04 [02:19:29.0628] annevk: if there somewhere I can read about the current state of ITP in Safari? Eg double-keying and cookie lifetimes in various contexts (eg iframes, different kinds of popups, the kinds of interactions that change the behaviour) [02:19:38.0803] * annevk: is there somewhere I can read about the current state of ITP in Safari? Eg double-keying and cookie lifetimes in various contexts (eg iframes, different kinds of popups, the kinds of interactions that change the behaviour) [03:17:15.0667] Jake Archibald: suspect https://webkit.org/blog/category/privacy/ is your best bet as far as webkit.org goes, not sure about outside documentation [03:19:15.0631] annevk: hmm, I see stuff like https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/, but that's just a changelog as far as I can tell. Is it expected that folks go through all these changelogs and manually figure out how it works today, or is that documented somewhere else? [04:54:33.0720] https://webkit.org/tracking-prevention/ I believe should be what you want? [05:17:40.0446] Sam Sneddon [:gsnedders]: ohhh, I think that's what I'm looking for. Cheers! [05:22:47.0297] "How are you meant to find that document" is a reasonable question 😛 [06:26:23.0161] Dominic Farolino: is https://github.com/web-platform-tests/wpt/pull/45650 good to go? :) [08:25:40.0539] will finish reviewing within 24h [15:15:09.0443] h 2024-06-05 [20:21:51.0373] zcorpan: sorry to bother you, as far as I know, you seem to have written a part about HTML parsing. Could you give me an answer? [00:55:35.0763] annevk: Does the "settings" button in https://github.com/orgs/whatwg/teams/html-triage work for you? I tested in 3 browsers and it does nothing. No error in the console [00:56:24.0613] Hmm the settings tab works though, ok [01:23:17.0700] Yoav Weiss: so noopener-allow-popups would be used on the opener side and make all the newly opened windows opened basically with noopener? Or am I misunderstanding this? [01:24:51.0700] (in the pr I don't quite understand "maintain its opener relationship with them" - who maintains opener, when we just cut opener relationship ) [01:58:13.0125] smaug: If the header is used by a document, its openers would lose the ability to script it, but it would still have the ability to open other same-origin documents and script them [01:58:48.0491] smaug: does that clarify things? I'll reexamine the language I used there to try and make it clearer [01:59:04.0761] I also added an explainer https://gist.github.com/yoavweiss/c7b61e97e6f8d207be619f87ab96ead5 [02:02:00.0669] Aha, it is the opened page using the header, not opener [02:03:38.0868] yup [02:06:59.0403] document.write can insert stuff into the input stream [02:15:41.0101] > <@zcorpan:mozilla.org> document.write can insert stuff into the input stream It's clear. I ask you to explain why it talks about relative and not absolute offset. Can you provide an example that can might break logic if it will be an absolute offset? [02:36:14.0592] > <@zcorpan:mozilla.org> document.write can insert stuff into the input stream * It's clear. I ask why it talks about relative and not absolute offset. Can you provide an example that can might break logic if it will be an absolute offset? [03:32:48.0027] which makes "noopener" quite confusing, when there can be plenty of other references too if the newly loaded page isn't the first one in the window [03:35:30.0370] I don't know if an absolute offset breaks anything [03:44:32.0689] > <@zcorpan:mozilla.org> I don't know if an absolute offset breaks anything Then I do not understand for what purpose this "warning" was written, contrasting the relative with the absolute offset. By chance, do you know the reason for this formulation? [04:19:37.0956] smaug: I don't think that's true? Assuming the newly loaded page is the one with the new value. COOP can guarantee nobody has a reference to you, by literally creating a new browsing context and such. [06:12:39.0082] annevk: I mean the terminology. It is not about opener, but about having a new top level thingie which no one can refer to [06:18:56.0757] smaug: it's a new thingie without an opener? noopener, if you will :p [06:19:30.0744] I find noopener clearer than omit, but maybe there's something even better [06:27:49.0888] I must be confused. This is about opening a new same origin window (or loading a new page to existing window), and we want that nothing from outside has references to it, right? [07:37:02.0400] Yeah, that's correct. I'm fine with renaming to something better, if you have an ideas [07:38:14.0414] (although "nothing from outside" doesn't currently include e.g. an iframe parent) [07:38:47.0701] The current scope is really about the opener 2024-06-06 [11:46:46.0194] in https://webidl.spec.whatwg.org/#prod-AttributeName isnt the possible values for `AttributeNameKeyword` already covered by the `identifier` production? [11:48:17.0144] curious why it specifies both are available rules 2024-06-07 [03:05:41.0016] Meghan Denny: I think because of: "If the longest possible match could match one of the above named terminal symbols or one of the other terminal symbols from the grammar, it must be tokenized as the latter." in https://webidl.spec.whatwg.org/#idl-grammar [11:38:53.0727] right, okay yeah that makes sense I think I didnt connect 2-and-2 for a sec [11:39:36.0106] that means when AttributeName is added to the ast it needs to be distinguishable which one it matched as [11:40:29.0361] that was the part I was looking for but I can read the doc more to find out [11:44:15.0943] doesnt mention it so maybe not? [11:46:15.0069] oh is enlightening too 2024-06-12 [01:00:55.0920] zcorpan: https://github.com/whatwg/mimesniff/pull/190 next time use the Meta: prefix for pure xref changes [01:19:37.0352] annevk: ok, sorry. I looked for previous "export" PRs and saw the Editorial prefix [01:23:35.0252] Interesting, I think we only do that if there's also editorial nits contained within [06:29:23.0229] Am I correct in saying that SVGScriptElement has basically no concrete spec? There's no equivalent of HTML's [prepare the script element](https://html.spec.whatwg.org/#prepare-the-script-element) for example? [06:34:56.0310] Luke Warlow: html links to https://www.w3.org/TR/SVGMobile12/script.html#ScriptContentProcessing [06:37:24.0064] Eek 2008 😅, that bit seems to have gone missing in the latest SVG spec. At least it gives me *something* to link to. [06:42:44.0433] https://html.spec.whatwg.org/#parsing-main-incdata - another question, does the step about `An end tag whose tag name is "script"` also apply to SVG script? Or is the parsing for SVG contexts specced somewhere else? [06:50:22.0962] I think maybe it can't be an svg one at that point? I found it at https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inforeign [06:52:58.0121] > <@ms2ger:igalia.com> I think maybe it can't be an svg one at that point? I found it at https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inforeign Ah perfect thanks, that's exactly what I needed 2024-06-13 [19:33:22.0690] About https://github.com/mdn/content/pull/34087/files, I guess that behavior is required per the spec? That is, specifically this part: > `` redirect happens after the page is _completely loaded_, which is after all scripts have executed [19:33:49.0486] See also the related issue at https://github.com/mdn/content/issues/7859 [19:46:57.0991] As far as I can see from looking just now, none of the loading steps in https://html.spec.whatwg.org/multipage/document-lifecycle.html#document-lifecycle actually reference handling for `meta http-equiv="refresh"` (instead, only handling for the `Refresh` header) — and https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh doesn’t state _when_ in the loading process the _“shared declarative refresh steps”_ must be run _in the `meta http-equiv="refresh"` case_. [19:51:56.0101] I guess https://html.spec.whatwg.org/multipage/document-lifecycle.html#refresh could be possibly be sort of intentionally misread to state that `meta http-equiv="refresh"` should be handled in the loading process in the same way that the `Refresh` header is handled — but that doesn’t seem to be at all what the spec actually says (instead, it’d sort of be backward with the respect to how the spec actually does define the relationship between `meta http-equiv="refresh"` and `Refresh` — > The `Refresh` HTTP response header is the HTTP-equivalent to a [meta](https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element) element with an [http-equiv](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv) attribute in the [Refresh state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh). It takes [the same value](https://html.spec.whatwg.org/multipage/semantics.html#conformance-attr-meta-http-equiv-refresh) and works largely the same. Its processing model is detailed in [create and initialize a Document object](https://html.spec.whatwg.org/multipage/document-lifecycle.html#initialise-the-document-object). [19:52:30.0380] * I guess https://html.spec.whatwg.org/multipage/document-lifecycle.html#refresh could be possibly be sort of intentionally misread to state that `meta http-equiv="refresh"` should be handled in the loading process in the same way that the `Refresh` header is handled — but that doesn’t seem to be at all what the spec actually says (instead, it’d sort of be backward with the respect to how the spec actually does define the relationship between the two — > The `Refresh` HTTP response header is the HTTP-equivalent to a [meta](https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element) element with an [http-equiv](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv) attribute in the [Refresh state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh). It takes [the same value](https://html.spec.whatwg.org/multipage/semantics.html#conformance-attr-meta-http-equiv-refresh) and works largely the same. Its processing model is detailed in [create and initialize a Document object](https://html.spec.whatwg.org/multipage/document-lifecycle.html#initialise-the-document-object). [19:53:07.0761] * I guess https://html.spec.whatwg.org/multipage/document-lifecycle.html#refresh could be possibly be sort of intentionally misread to state that `meta http-equiv="refresh"` should be handled in the loading process in the same way that the `Refresh` header is handled — but that doesn’t seem to be at all what the spec actually says (instead, it’d sort of be backward with the respect to how the spec actually does define the relationship between the two) — > The `Refresh` HTTP response header is the HTTP-equivalent to a [meta](https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element) element with an [http-equiv](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv) attribute in the [Refresh state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh). It takes [the same value](https://html.spec.whatwg.org/multipage/semantics.html#conformance-attr-meta-http-equiv-refresh) and works largely the same. Its processing model is detailed in [create and initialize a Document object](https://html.spec.whatwg.org/multipage/document-lifecycle.html#initialise-the-document-object). [19:53:53.0828] * I guess https://html.spec.whatwg.org/multipage/document-lifecycle.html#refresh could be possibly be sort of intentionally misread to state that `meta http-equiv="refresh"` should be handled in the loading process in the same way that the `Refresh` header is handled — but that doesn’t seem to be at all what the spec actually says (instead, it’d sort of be backward with the respect to how the spec actually *does* describe the relationship between the two) — > The `Refresh` HTTP response header is the HTTP-equivalent to a [meta](https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element) element with an [http-equiv](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv) attribute in the [Refresh state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh). It takes [the same value](https://html.spec.whatwg.org/multipage/semantics.html#conformance-attr-meta-http-equiv-refresh) and works largely the same. Its processing model is detailed in [create and initialize a Document object](https://html.spec.whatwg.org/multipage/document-lifecycle.html#initialise-the-document-object). [19:55:39.0475] * About https://github.com/mdn/content/pull/34087/files, I guess that behavior is required per the spec? I can’t find where in the spec that behavior is defined. That is, specifically this part: > `` redirect happens after the page is _completely loaded_, which is after all scripts have executed [22:15:14.0097] OK, it’s since been pointed out to me that the relevant requirements are in fact already in the spec, in the definition of _“a refresh is said to have come due”_ in step 13 of https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh > For the purposes of the previous paragraph, a refresh is said to have come due as soon as the later of the following two conditions occurs: > > - At least time seconds have elapsed since document's [completely loaded time](https://html.spec.whatwg.org/multipage/document-lifecycle.html#completely-loaded-time), adjusted to take into account user or user agent preferences. > - If meta is given, at least time seconds have elapsed since meta was [inserted into the document](https://html.spec.whatwg.org/multipage/infrastructure.html#insert-an-element-into-a-document) document, adjusted to take into account user or user agent preferences. [00:37:27.0455] annevk: https://github.com/whatwg/html/issues/10407#issuecomment-2164768308 i feel like i did answer the actual question you asked about what happened to it, which is all i was trying to add.. 😋 [00:38:21.0593] I guess your question that remains is like "has the wg reached out to/coordinated with/considered them?" Is that right?" [00:38:35.0309] * I guess your question that remains is like "has the wg reached out to/coordinated with/considered them?" Is that right? [01:28:14.0215] keithamus: About details auto-expand in GH issues, it still doesn’t seem to be working in Chrome — and my patch at https://github.com/primer/css/pull/2624 not been merged yet [01:34:05.0988] krosylight: I think that star change is actually a bit different, since it is highlighted because the page gets bookmarked. So the process there is rather indirect [01:46:53.0138] > <@smaug:mozilla.org> krosylight: I think that star change is actually a bit different, since it is highlighted because the page gets bookmarked. So the process there is rather indirect Hmmm. Does it also apply before finishing bookmark? The popup opens and the new bookmark is not created yet, and still the star is highlighted [01:48:00.0363] the page is star'ed immediately, I believe. The star stays highlighted even if you just hide the popup by clicking elsewhere [01:49:03.0784] > <@smaug:mozilla.org> the page is star'ed immediately, I believe. The star stays highlighted even if you just hide the popup by clicking elsewhere Hiding the popup is treated as Save (well, yeah) and saves bookmark [01:49:35.0709] bkardell: well that issue already pointed to that explainer so I'm not really sure how that was adding anything new [01:50:28.0352] smaug: you can see the difference by opening Manage Bookmarks popup [01:50:40.0695] * smaug: you can see the difference by opening Manage Bookmarks popup and do the start thing [01:50:44.0793] * smaug: you can see the difference by opening Manage Bookmarks popup and do the star thing [01:51:02.0861] New entry doesn't show up until you either dismiss the popup or click the save button [01:52:12.0594] I guess that is when it is decided where the bookmark is stored [01:53:01.0194] Clicking the star saves it into a temporary folder you mean? perhaps yeah [01:53:11.0221] * Clicking the star immediately saves it into a temporary folder you mean? perhaps yeah [01:54:27.0828] All other popup-opening buttons get background highlight too (including the hamburger button), but I guess that's nothing to do with commands [01:54:49.0525] (or does it?) [02:22:06.0265] oh it did? weird, sorry - I missed it somehow [07:36:07.0779] krosylight: bakkot: FWIW, I fixed some of the Float16Array test issues already [08:11:19.0492] thanks [08:11:25.0746] yeah I wasn't totally sure how to handle those [08:11:37.0597] the tests are not written in a way which makes them easy to split [08:12:51.0009] test262 does things in a slightly different way, where there is a central list of all the TA types, and in that case I could just conditionally add it to that list based on whether it's present [08:13:00.0644] but the WPT tests aren't really set up for that [08:13:09.0995] still, maybe the best option? duplicating every test seems less desirable [08:16:17.0394] bakkot: I think there's a couple that have some duplication for the 64 case [08:17:13.0774] bakkot: and some have the infrastructure that it's just a local failure by making the construction local to the test [09:49:57.0915] Luke Warlow: I prolly can't look at Trusted Types PRs again until somewhere next week. Maybe zcorpan or Dominic Farolino can help out with some review on the DOM stuff meanwhile? I think your suggestion of an optional boolean is reasonable, if one path indeed has to be vetted and the other does not. (Not enough time at the moment to deeply investigate.) [09:50:46.0795] Luke Warlow: and at worst I might not have time until July. Depends a bit on some unknowns. [09:51:30.0229] Yeah no worries I'm OOO till at least Tuesday. It would be good to get other eyes on it too. I'm slightly blind to it given the iteration (apologies for the churn). Any other eyes over it would be great! [09:54:11.0988] zcorpan: Dominic Farolino: for clarity, https://github.com/whatwg/dom/pull/1268 is the PR in question [10:03:07.0589] Thanks I’ll look into this as I can. It might be a week or two though. [11:30:20.0890] If you can formally request my review that'd be a great way to get it in my inbox [11:30:37.0307] Also tough for me to get to it before next Tuesday but I can try, or at the very least review it after. [12:30:49.0572] As I say I'm OOO till Tuesday so no rush. [12:31:55.0343] * As I say I'm OOO till Tuesday so no rush. I've added you as a reviewer. 2024-06-14 [01:54:23.0328] Hi! Should I be able to find info about timings for WHATNOT and other relevant information about WHATNOT somewhere? I was looking at https://whatwg.org/working-mode#meetings but don't see how it's regularly scheduled. Thanks. [01:54:40.0869] * Hi! Should I be able to find info about timings for WHATNOT and other relevant information about WHATNOT somewhere? I was looking at https://whatwg.org/working-mode#meetings but don't see how it's scheduled regularly. Thanks. [02:02:23.0099] Hi Muan! [02:02:26.0946] Meeting times (alternating every week): 18:00 Berlin / 01:00 Tokyo / 09:00 San Francisco: America + Europe friendly 01:00 Berlin / 08:00 Tokyo / 16:00 San Francisco: APAC + America friendly (12:00 am Berlin / 08:00 Tokyo / 15:00 San Francisco when daylight savings are not in effect) 10:00 Berlin / 17:00 Tokyo / 01:00 San Francisco: Europe + APAC friendly [02:02:47.0899] Those are the times at least [02:03:22.0969] Lovely. Thank you. Are these be documented somewhere? [02:04:34.0705] Only in Google Doc that's not linked to anywhere [02:07:10.0815] A while back, I opened a PR to add a link to it somewhere, but the PR did not get approved [02:07:18.0005] Ha. Cool. Is the Google Doc public and include other relevant info? If so I'd love to take a look. [02:11:25.0451] https://github.com/whatwg/html/issues/10408 is where, to get a calendar invite, you should RSVP, by posting a comment [07:22:42.0669] I think we're hitting 10 years of HTML on GitHub this summer, right? Maybe we should do some retrospective. [07:23:11.0765] Yes [07:23:18.0204] 20 years of WHATWG, too [07:24:18.0483] https://www.w3.org/html/wg/wiki/History#2004-06 [07:25:26.0465] June 4th 2004 – WHAT open mailing list announcement [07:26:11.0447] the W3C Workshop on Web Applications and Compound Documents was 1st and 2nd June 2004 2024-06-17 [00:36:26.0284] Dominic Farolino: hey I was curious about something with Observables; when you subscribe with a signal, how would you then use that signal in any of your callback handling? Such as passing it to a fetch you might start based on a click? [01:01:00.0356] I guess you can always close over that AbortSignal separately, but I wonder if we should make this more automatic by having an implicit AsyncContext variable propagate things (if there wasn’t already a plan for that) [01:01:19.0714] * I guess you can always close over that AbortSignal separately, but I wonder if we should make this more automatic by having an implicit AsyncContext variable propagate the AbortSignal (if there wasn’t already a plan for that) [01:02:02.0037] Does AsyncContext also work for 'synchronous' events? [01:03:00.0806] * Does AsyncContext also work for 'synchronous' events? (I guess it does, given what we discussed.) [01:04:31.0148] Yes, it is just a mechanism for saving and restoring dynamically scoped variables. The only thing async about it is that it does this around await by default [01:04:47.0058] The whole API is synchronous [06:35:01.0623] annevk: I'm actually not sure I get the question. The signal you subscribe with is for the observable/producer to be aware of consumer-initiated unsubscription. I don't think you want to use the signal in the consumer's callbacks. [09:00:10.0579] Dominic Farolino: why not? [09:01:03.0429] "I'm no longer interested in this event and if it started any activity on my behalf I'm no longer interested in that either" seems quite reasonable to me. [14:14:47.0011] Right that's reasonable enough. But I don't understand the question "how would you then use that signal"? You just pass it into whatever API (like `fetch()`) receives signals I guess! [14:19:20.0814] Yeah the question is whether it is practical to thread it through. (Some JS developers I have spoken with say it is, some say it isn’t) [14:19:52.0854] * Yeah the question is whether it is practical to thread it through manually, or whether, in practice, people will forget to do so, and strand resources. (Some JS developers I have spoken with say it is, some say it isn’t) 2024-06-18 [20:30:05.0787] Hmm, well I'd think if you're already threading it through `subscribe()` (to unsubscribe later), then threading it through more places is the same amount of effort. Otherwise it sounds like a discussion about how practical AbortController/Signal is in general, I guess. [01:03:11.0119] Dominic Farolino: Can you take another look at https://github.com/web-platform-tests/wpt/pull/45650 ? ty :) [01:41:27.0748] Dominic Farolino: well you could imagine it being exposed to the callback so whoever is writing the callback doesn't need to know about who is subscribing directly [01:43:51.0666] Though we don't offer that with addEventListener() either I suppose, but I could imagine wanting that. Perhaps AsyncContext will help with these cases. [06:48:33.0430] Hi folks, I'm not so much a developer myself as a media archaeologist. I'm currently writing a thesis on the history and development of web browsers and wanted to ask if there are any people here who were involved in the founding of the WHATWG, could put me in touch with such people or could simply tell me something about the history of the WHATWG themselves. It doesn't matter how small or subjective these stories are, but it would help me a lot and maybe it would help to organize the great history of the web and present it to other people. I would be very happy to hear from people. Best regards from Lüneburg Leonard :) [07:40:34.0208] lustigerleo: https://ln.hixie.ch/?start=1085056751&count=1 https://ln.hixie.ch/?start=1086387609&order=-1&count=1 https://ln.hixie.ch/?start=1088526392&order=-1&count=1 and maybe a few other of Ian Hickson 's posts around that time are relevant [07:42:33.0420] lustigerleo: https://htmlparser.info/introduction/ for history of HTML parsing [07:44:05.0710] lustigerleo: https://github.com/whatwg/web-history [07:45:18.0823] lustigerleo: https://platform.html5.org/history/ [07:47:36.0052] lustigerleo: https://wpc.guide/governance/#whatwg-and-html [16:03:30.0220] Domenic (OOO through 2024-06-16): shu: I'm merging https://github.com/whatwg/html/pull/9038 tomorrow. Please let me know if there are concerns from Google. [16:24:55.0241] About the [Disclosures regarding contributions](https://whatwg.org/ipr-policy#561-disclosures-regarding-contributions) part of the WHATWG Intellectual Property Rights Policy: I notice it says this (emphasis added): > _[Individuals](https://participate.whatwg.org/agreement#individual) **but not [Entities**](https://participate.whatwg.org/agreement#entity), or representatives of Entities, participating in a [Workstream](https://whatwg.org/workstream-policy#workstream) must also, as soon as is reasonably feasible, identify and disclose any patent or patent application of which they are personally aware that they believe contains claims that are or may become Essential Patent Claims for any [Workstream](https://whatwg.org/workstream-policy#workstream) in which they are participating._ So, Entities are _not_ required to make (patent) disclosures, but Individuals are? [16:26:12.0436] * About the [Disclosures regarding contributions](https://whatwg.org/ipr-policy#561-disclosures-regarding-contributions) part of the WHATWG Intellectual Property Rights Policy: I notice it says this (emphasis added): > _[Individuals](https://participate.whatwg.org/agreement#individual) **but not [Entities](https://participate.whatwg.org/agreement#entity)**, or representatives of Entities, participating in a [Workstream](https://whatwg.org/workstream-policy#workstream) must also, as soon as is reasonably feasible, identify and disclose any patent or patent application of which they are personally aware that they believe contains claims that are or may become Essential Patent Claims for any [Workstream](https://whatwg.org/workstream-policy#workstream) in which they are participating._ So, Entities are _not_ required to make (patent) disclosures, but Individuals are? [16:26:31.0991] * About the [Disclosures regarding contributions](https://whatwg.org/ipr-policy#561-disclosures-regarding-contributions) part of the WHATWG Intellectual Property Rights Policy: I notice it says this (emphasis added): > _[Individuals](https://participate.whatwg.org/agreement#individual) **but not [Entities](https://participate.whatwg.org/agreement#entity), or representatives of Entities,** participating in a [Workstream](https://whatwg.org/workstream-policy#workstream) must also, as soon as is reasonably feasible, identify and disclose any patent or patent application of which they are personally aware that they believe contains claims that are or may become Essential Patent Claims for any [Workstream](https://whatwg.org/workstream-policy#workstream) in which they are participating._ So, Entities are _not_ required to make (patent) disclosures, but Individuals are? 2024-06-19 [20:38:19.0392] annevk: thanks for the heads up. no concerns on the HTML integration from me [09:19:37.0141] > <@annevk:matrix.org> Dominic Farolino: well you could imagine it being exposed to the callback so whoever is writing the callback doesn't need to know about who is subscribing directly Hmm yeah that is interesting. My gut reaction is that something external like AsyncContext is best to handle this. Exposing things like AC/AS within the callbacks seems potentially useful, but I am not sure how we'd do it. We don't want to store per-subscription state on the Observable itself (see discussion around https://github.com/WICG/observable/issues/22#issuecomment-1804938312). So the alternative would be to somehow set the callback `this` value to some intangible per-subscription object that holds onto, for now, the signal supplied at subscription time. That seems a little funky though. [09:19:59.0990] I guess another option would be to just invoke the next callback with the signal as the last argument every time, but that seems wasteful and not scalable. [11:54:33.0551] spam [12:07:13.0897] do webidl strings support any escape sequences? doesnt appear so but wanted to verify 2024-06-20 [19:13:08.0461] https://whatwg.org/working-mode has a Changes section that lists out ~4 key requirements (“*must have support from implementers”*, etc.) that change to an _existing_ spec must meet. But I can’t find anywhere similar that enumerates the requirements that the contents of any _new_ spec must meet before it can be published at the WHATWG — that is, as/in a new Workstream. [19:19:39.0544] * https://whatwg.org/working-mode has a Changes section that lists out ~4 key requirements (“_must have support from implementers”_, etc.) that a change to an _existing_ spec must meet. But I can’t find anywhere similar that enumerates the requirements that the contents of any _new_ spec must meet before it can be published at the WHATWG — that is, as/in a new Workstream. [19:21:06.0884] I recognize there is a list of _some_ type of requirements at [Workstream Proposals}(https://whatwg.org/workstream-policy#workstream-proposals) — but that’s in a _legal_ doc, and the requirements listed are not requirements related to the _normative_/_substantive_ content of the spec drafts/proposals themselves. Specifically, there’s no requirement like _“must have support from implementers”_ or the others that are required for changes to existing workstream specs. [19:21:29.0110] * I recognize there is a list of _some_ type of requirements at \[Workstream Proposals](https://whatwg.org/workstream-policy#workstream-proposals) — but that’s in a _legal_ doc, and the requirements listed are not requirements related to the _normative_/_substantive_ content of the spec drafts/proposals themselves. Specifically, there’s no requirement like _“must have support from implementers”_ or the others that are required for changes to existing workstream specs. [19:22:02.0187] * I recognize there is a list of _some_ type of requirements at [Workstream Proposals](https://whatwg.org/workstream-policy#workstream-proposals) — but that’s in a _legal_ doc, and the requirements listed are not requirements related to the _normative_/_substantive_ content of the spec drafts/proposals themselves. Specifically, there’s no requirement like _“must have support from implementers”_ or the others that are required for changes to existing workstream specs. [19:25:18.0686] Concretely, do we have any recently-created WHATWG specs with any features that _don’t_ meet all the following requirements? - must have support from implementers. - should have corresponding test changes, either in the form of new tests or modifications to existing tests. - implementations bugs must be filed for each user agent that fails tests [19:27:11.0541] In other words, do we have any recently-created WHATWG specs with existing contents that under the Changes policy requirements would yet not have been able to get merged into the spec if they’d been submitted through our PR process? [19:28:27.0178] * Concretely, do we have any recently-created WHATWG specs with any features that _don’t_ meet all the following requirements? 1. must have support from implementers. 2. should have corresponding test changes, either in the form of new tests or modifications to existing tests. 3. implementations bugs must be filed for each user agent that fails tests [19:30:07.0662] And if the answer to that is No, then does that mean that in practice, we don’t accept/create/publish any new specs/workstreams unless the entire contents of the proposed spec _already_ meet all the same requirements we impose on PRs for existing specs? That is, the 3 core requirements cited above? [19:49:25.0613] Similarly, the [Process](https://whatwg.org/stages#process) part of the Stages doc is limited to describing the process for getting contributions landed in an *already-existing* spec. The Process description starts by saying effectively that: > *Any Contribution effectively starts at Stage 0 without any approvals, by a community member **filing a new issue on a relevant WHATWG standard.*** [19:49:36.0890] * Similarly, the [Process](https://whatwg.org/stages#process) part of the Stages doc is limited to describing the process for getting contributions landed in an _already-existing_ spec. The Process description starts by saying effectively that: > _Any Contribution effectively starts at Stage 0 without any approvals, by a community member **filing a new issue on a relevant WHATWG standard.**_ (emphasis added) [19:52:31.0798] * Similarly, the [Process](https://whatwg.org/stages#process) part of the Stages doc is limited to describing the process for getting contributions landed in an _already-existing_ spec. The Process description starts by saying effectively that: > _Any Contribution effectively starts at Stage 0 without any approvals, by a community member **filing a new issue on a relevant WHATWG standard.**_ And the very definition of a [_Contribution_](https://whatwg.org/ipr-policy#21-contribution) is: > *"Contribution" means any proposal to make **changes to a particular WHATWG Living Standard*** (emphasis added in both citations) It says _nothing_ about the Stages/process for how to start a completely new spec with a Contributy [19:54:10.0115] * Similarly, the [Process](https://whatwg.org/stages#process) part of the Stages doc is limited to describing the process for getting contributions landed in an _already-existing_ spec. The Process description starts by saying effectively that: > _Any Contribution effectively starts at Stage 0 without any approvals, by a community member **filing a new issue on a relevant WHATWG standard.**_ And the very definition of a [_Contribution_](https://whatwg.org/ipr-policy#21-contribution) is: > _"Contribution" means any proposal to make **changes to a particular WHATWG Living Standard**_ (emphasis added in both citations) It says _nothing_ about the Stages/process for how to start a completely new spec/workstream with a Contribution that doesn’t fit into any existing spec but that instead by its nature sufficiently merits/necessitates its own separate spec [19:54:49.0926] * Similarly, the [Process](https://whatwg.org/stages#process) part of the Stages doc is limited to describing the process for getting contributions landed in an _already-existing_ spec. The Process description starts by saying effectively that: > _Any Contribution effectively starts at Stage 0 without any approvals, by a community member **filing a new issue on a relevant WHATWG standard.**_ And the very definition of a [_Contribution_](https://whatwg.org/ipr-policy#21-contribution) is: > _"Contribution" means any proposal to make **changes to a particular WHATWG Living Standard**_ (emphasis added in both citations) It all says _nothing_ about the Stages/process for how to start a completely new spec/workstream with a Contribution that doesn’t fit into any existing spec but that instead by its nature sufficiently merits/necessitates its own separate spec [05:29:32.0079] sideshowbarker: I'm not sure https://testutils.spec.whatwg.org was implemented everywhere (or is today?) when it was approved, but everyone was supportive of it. And yeah, Stages can be used for changes to standards (possibly including a new standard within the same Workstream), but can't be used for new Workstreams. 2024-06-21 [13:24:38.0663] not sure which repo would be the best to file this under but the IDL in https://html.spec.whatwg.org/multipage/semantics.html#the-base-element doesnt link USVString and DOMString to the webidl spec [13:26:15.0156] * not sure which repo would be the best to file this under but the IDL in https://html.spec.whatwg.org/#the-base-element doesnt link USVString and DOMString to the webidl spec [13:54:20.0048] It looks like all the IDL in the spec isn't linking those, in fact. 2024-06-25 [09:39:47.0849] Hi [14:13:22.0901] does https://github.com/w3c/webidl2.js have its own discord/slack/matrix or is here fine? ive been working an a new parser implementation and using their test suite as a reference along with the spec. however it seems a number of cases are out of date? I didnt know if this is something they were aware of or if we should coordinate it or a bunch of small prs would be best [14:53:26.0533] I'm not aware of any specific community for that library. [16:36:10.0147] Meghan Denny: As far as chat, here seems probably like the best place. krosylight is here — along with others who might make time to pitch in on updating the tests 2024-06-26 [01:21:48.0128] Meghan Denny: a GitHub issue is the best place actually [01:22:46.0201] I think I saw some while working on weedle3... Maybe I did not upstream it? [01:23:44.0238] Having a common test set might be a good idea [03:24:11.0464] roger; i've been working on which currently passes 128/165 of the existing tests. i'll finish going through and double checking any remaining bugs i have and file issues for the remaining ones for discussion 👍️ [12:59:14.0469] Yoav Weiss: could you get keithamus write access to https://github.com/WICG/webcomponents? And possibly `Westbrook`? [13:56:42.0107] annevk: added Keith. What's Westbrook github's user? Is that https://github.com/Westbrook? [14:10:17.0158] That’s the one. [14:10:52.0214] * That’s the one Yoav Weiss [14:12:16.0979] done! [14:12:33.0289] Many thanks! 2024-06-27 [17:29:37.0598] (thought it was gonna let me post more message before sending) not sure if anyone else got this [01:49:50.0037] UA shadow dom isn't specified anywhere in any way, right? [01:53:04.0508] I guess just used vaguely, like in https://html.spec.whatwg.org/#the-details-and-summary-elements [02:00:38.0514] (not sure how much there is to specify, I was just pondering the options in https://github.com/w3c/csswg-drafts/issues/10242 where option 2 would need like a /deep/ selector for some UA shadow doms) [03:45:35.0483] annevk: I canceled this week's WHATNOT and I'm wondering what to do with the July 4 one. I'm inclined to skip since all of us US-based attendees won't be attending, but if enough European folks want to attend and you can facilitate, maybe it's worth keeping? [03:46:35.0617] The next meeting on July 11 will be 2 weeks after the joint task force meeting, which seems soon enough. [03:47:13.0482] Also smaug ^^ [07:16:28.0509] Panos Astithas: I'll be around, let's keep it for now and I'll cancel/end early as needed [10:36:07.0935] https://github.com/tc39/ecma262/pull/1314 is going to land imminently. before landing it, i'd love to have an HTML PR up to migrate to that notation. can someone give me some pointers as to where I'd need to make those changes? (in particular if it's webIDL stuff and not just spec text changes) [11:00:38.0569] FYI I will be afk between now and July 29 [11:05:33.0348] ljharb: in https://github.com/whatwg/html in the `source` file and in https://github.com/whatwg/webidl in the `index.bs` file [11:06:26.0516] ljharb: I think it only ends up impacting a couple of algorithms, nothing downstream [11:06:46.0347] awesome, thanks, i'll TAL 2024-06-30 [20:02:22.0071] Quite interesting SO question about BroadcastChannel and origins: https://stackoverflow.com/questions/78679467/web-broadcastchannel-fails-in-iframe-when-src-is-redirected They end up in a situation where 2 documents can communicate directly through WindowProxy access, but not through BroadcastChannel.