2024-01-02 [18:13:29.0992] annevk: right, what is the next step? It's still doesn't touch the **custom element reactions stack** [23:58:58.0165] Oh, I was confusing it with the queue. I think the stack is being used when for instance a custom element is being constructed and its constructor uses a thing with CEReactions. [08:24:01.0762] We often check for detached documents by checking if some relevant global object "is a Window" and that it's associated doc is fully active. Is there is an equivalent we need to do for workers/other globals? [08:24:16.0682] Can workers ever become "detached" or "inactive" in the same way that requires this checking? [08:25:38.0952] I'm writing a spec for an interface that is being introduced to Window and Workers, but I have a bunch of "relevant global object's active Document is fully active" checks. But that's obviously insufficient for Workers, so I'm trying to figure out if I need a similar check for those environments or not [08:49:43.0094] Dominic Farolino: I think in theory a worker can be bfcache'd and then it'd prolly apply, but that's poorly defined [10:09:42.0035] +1 that it would be lovely for org admins and moderators to be able to see an org-wide view of reported content. Then folks wouldn't need to know to forward spam to keithamus; they could just use Github's reporting API. [10:09:54.0130] * +1 that it would be lovely for org admins and moderators to be able to see an org-wide view of reported content. Then folks wouldn't need to know to forward spam to keithamus; they could just use Github's reporting UI. [10:13:14.0220] Should Infra have any advice on how specs should use exceptions? https://infra.spec.whatwg.org/#algorithm-control-flow says algorithms can throw, and the exception will silently propagate up the stack, but I feel like it's a best practice to at least mention which algorithms can throw. [11:28:07.0794] I want to propose allowing `blocking=render` on inline scripts, would that be a "new feature" or a "new issue"? [12:56:14.0296] Noam Rosenthal: I guess up to you which template you want [13:26:06.0425] > <@zcorpan:mozilla.org> Noam Rosenthal: I guess up to you which template you want Hmm ok thanks. 2024-01-03 [16:43:46.0900] annevk: well, you confirm my suggestions about API that decorated by CEReactions that can create an element and invoke constructor method with another API decorated by CEReations. Thanks. [16:47:28.0939] * annevk: well, you confirm my suggestions about API that decorated by CEReactions that can create an element and invoke constructor method in the code of which calls another API decorated by CEReations. Thanks. [22:18:47.0431] * annevk: well, you confirm my suggestions about API that decorated by CEReactions that can create an element and invoke constructor method in the code of which is called another API decorated by CEReations. Thanks. [22:21:05.0573] * annevk: well, you confirm my suggestions about API that decorated by CEReactions that can create an element and invoke constructor method in the code of which is called an another API decorated by CEReations. Thanks. [00:18:40.0742] Jeffrey Yasskin: I don't think WHATWG specs mention it. IDL doesn't either. It is typically mentioned in domintro boxes though. But we could change all of that I suppose. [01:53:00.0559] > <@noamr:matrix.org> I want to propose allowing `blocking=render` on inline scripts, would that be a "new feature" or a "new issue"? https://github.com/whatwg/html/issues/10034 [05:48:47.0001] Is there something in HTML that would trim whitespace from nonce attributes? https://html.spec.whatwg.org/multipage/urls-and-fetching.html#nonce-does-not-update-dom doesn't at least, but I am not sure how attributes from the parser are handled. [07:52:31.0439] evilpie: typically preserved [10:00:20.0884] > <@annevk:matrix.org> Jeffrey Yasskin: I don't think WHATWG specs mention it. IDL doesn't either. It is typically mentioned in domintro boxes though. But we could change all of that I suppose. I don't want to change what experienced spec authors are doing, just try to document it better, if there is actually a pattern to document. My impression was that WHATWG specs usually return "failure" from algorithm steps and then only convert that to an exception when implementing a WebIDL operation. For example, https://url.spec.whatwg.org/#dom-url-url converts failure to an exception in the URL constructor, and https://fetch.spec.whatwg.org/#dom-global-fetch does the same conversion from network error to rejection. Some of the helper algorithms for WebIDL operations do throw without mentioning it in their interfaces, but the deeper layers seem to prefer returns. [11:44:35.0109] > <@jyasskin:matrix.org> I don't want to change what experienced spec authors are doing, just try to document it better, if there is actually a pattern to document. My impression was that WHATWG specs usually return "failure" from algorithm steps and then only convert that to an exception when implementing a WebIDL operation. For example, https://url.spec.whatwg.org/#dom-url-url converts failure to an exception in the URL constructor, and https://fetch.spec.whatwg.org/#dom-global-fetch does the same conversion from network error to rejection. Some of the helper algorithms for WebIDL operations do throw without mentioning it in their interfaces, but the deeper layers seem to prefer returns. This usually makes sense to me because "throwing" means that there's some catching semantic, and that's not guaranteed when you're in an internal operation (e.g. it could be an `in parallel` operation) [11:54:14.0704] does anyone know why getRandomValues has a size limit? I poked around the git history and mailing lists but couldn't find it offhand [13:53:23.0892] Jeffrey Yasskin: I think that's right. Just like you would (might?) return std::nullopt in C++ over an exception. [13:59:13.0895] bakkot: I found it predates git but not super motivated to dig into the CVS history [13:59:35.0206] bakkot: emailing Ryan Sleevi or dm'ing him somewhere might work [15:09:14.0583] > <@evilpie:mozilla.org> Is there something in HTML that would trim whitespace from nonce attributes? https://html.spec.whatwg.org/multipage/urls-and-fetching.html#nonce-does-not-update-dom doesn't at least, but I am not sure how attributes from the parser are handled. "becomes browsing-context connected" also applies for parser-inserted elements. The parser doesn't trim whitespace for nonce attributes, nor anything else in the spec AFAICT. [15:31:58.0616] annevk: if you know where the CVS history is I am happy to dig into it 2024-01-04 [17:02:40.0608] Hm, there's no list of reflected attributes, is there? [17:02:49.0339] (Trying to find examples of attributes that aren't reflected.) [17:04:17.0827] There should be 0 such attributes, although maybe one slipped in around... Shadow parts, IIRC? Because rniwa hated DOMTokenList or something like that, so we just gave up on getting consensus for how to reflect it? [17:41:32.0462] <محسن کمالی> س [18:25:34.0051] <محسن کمالی> س [23:00:22.0834] Shadow parts is also not properly standardized still maybe? At least the DOM aspects are not in HTML or DOM as they ought to be. [00:14:49.0183] Is there a standard way to say “perform this operation after this promise resolves *including all its reactions* or it’s a matter of adding a microtask checkpoint? [00:25:49.0705] sideshowbarker: do you know if the old CVS history for specifications can still be found somewhere? [00:31:56.0070] annevk: For W3C specs, I think no — not any longer. Not the original CVS history itself at least. because since CVS is a client-server thing, W3C would need have the CVS server running — or at least have the filesystem thing that CVS served from still saved. [00:34:27.0257] Well, with the exception of anything that we served from www.w3.org or w3.org URLs — that all still exists in CVS. (And is still being added to — W3C is still using CVS to maintain large parts of w3.org content, and till adding to it via CVS.) [00:35:45.0529] Does anyone still have a copy that they could stuff in a git repository somehow? [00:36:12.0075] It depends on which spec [00:36:35.0181] If it were served from dev.w3.org org, then yeah I think we could manage to find copies. [00:36:50.0138] Web Crypto came up above. [00:37:45.0171] OK [00:37:54.0260] I will do some digging [00:38:20.0899] Given that for dev.w3.org at least, I think you remember that in the pre-github days, we (in many cases, me) migrated all of dvcs.w3.org content to Mercurial. So that still may exist somewhere — at least in local clones (maybe some things even on my own laptop). [00:39:00.0744] sideshowbarker: the Mercurial copy I found suggests there's more history in CVS; they started anew [00:39:18.0325] sideshowbarker: https://dvcs.w3.org/hg/webcrypto-api/summary [00:41:12.0464] /me looks [00:42:22.0205] well that’s unfortunate [00:44:53.0635] Oh wow, I found something by going through the W3C lists [00:45:15.0744] It involves Ms2ger (back in 2024 W2) [00:45:18.0263] https://wiki.whatwg.org/index.php?title=Crypto&action=history [00:45:20.0876] Yeah, I was just now typing this: I vaguely recall that we might have once had a mailing list set up, to which all dvcs.w3.org commit messages were archived (even i n CVS ldays) [00:46:30.0216] And https://bugzilla.mozilla.org/show_bug.cgi?id=440046#c43 has the answer bakkot was looking for [00:46:44.0043] excellent [00:46:47.0054] UI responsiveness is the reason for the limit in Web Crypto [00:56:32.0000] hmm but was that browser-UI-responsiveness problem only an issue for Firefox in the years before multi-process? [00:57:07.0589] that is, is it actually still relevant at all any longer? [00:58:03.0103] …though I guess it might be a moot question, if browser projects are interested in going back and touching that part of the existing web-crypto code [00:58:11.0346] Blocking the main thread is still a concern. [00:58:12.0065] * …though I guess it might be a moot question, if browser projects are not interested in going back and touching that part of the existing web-crypto code [00:58:17.0652] ah OK [00:59:18.0168] But yeah, bit unclear if that's a good enough reason to have a limit as there's a lot of ways to block it. [07:11:29.0406] aha! thanks much annevk [08:28:38.0771] Should APIs that take in a Promise and an AbortSignal reject the promise when the signal is aborted? [08:28:49.0816] I think that's consistent with https://w3ctag.github.io/promises-guide/#rejections-should-be-exceptional:~:text=When%20it%20will%20be%20impossible%20to%20complete%20the%20requested%20task, but want to make sure my judgement on that is right. [08:29:39.0370] * Should APIs that take in an AbortSignal and return a Promise, reject the promise when the signal is aborted? [08:53:28.0123] > <@domfarolino:matrix.org> Should APIs that take in an AbortSignal and return a Promise, reject the promise when the signal is aborted? https://dom.spec.whatwg.org/#abortcontroller-api-integration says yes. 2024-01-06 [22:11:20.0480] Has there been any discussion around non-CSS custom cursors (i.e. an element that follows the mouse coords) and top-layer? top-layer effectively breaks all existing solutions. I’ve been able to abuse a manual popover to keep the cursor on top (https://codepen.io/knowler/pen/PoLNNKB), but that’s not perfect since there’s no reliable way of knowing when something new becomes the topmost top-layer. I will admit that non-CSS custom cursors aren’t great, but it’s not uncommon. Seems like maybe a document author use-case for the `overlay` property or maybe something CSS needs to allow better customization around (specifically in regard to animation which is generally why people implement custom cursors this way). [23:36:49.0788] knowler: I think a write-up on https://github.com/w3c/csswg-drafts/issues/new explaining why CSS custom cursors exist and how they're running into issues due to the top layer would be helpful. Keep https://whatwg.org/faq#adding-new-features in mind, in particular 1. 2024-01-08 [01:33:37.0753] > <@annevk:matrix.org> It involves Ms2ger (back in 2024 W2) I deny everything [04:03:03.0433] I'm quoting from this source: https://infra.spec.whatwg.org/#implementation-defined "Features that are defined in documents using the Infra Standard that can be used as a tracking vector are marked as this paragraph is". This sentence is unclear to me: "are marked as this paragraph is". Can you explain what it means? [04:21:26.0462] chargeitall: it's referencing the fingerprint icon, maybe we should make that more explicit [04:26:17.0200] I appreciate your clarification. I was puzzled by the presence of this fingerprint, but I did not see how it related to this phrase since the fingerprint was far from the text. [08:19:31.0840] using only icons and not also text isn't accessible anyways, that should probably be improved [08:38:32.0305] https://infra.spec.whatwg.org/#algorithm-declaration "Declare algorithms by stating their name, parameters, and return type, in the following form: To **[algorithm name]**, given a [type1] _[parameter1]_, a [type2] _[parameter2]_, …,perform the following steps. They return a [return type]." Q1. Is it better to add parameter type? e.g. "Declare algorithms by stating their name, parameter type, parameters, and return type, in the following form:" Q2. why _[parameter1]_ is in italic? [08:40:27.0400] * I appreciate your clarification. I was puzzled by the presence of this fingerprint. I did not see how it related to this phrase since the fingerprint was far from the text. [08:40:34.0062] There's no alt attribute? [08:40:39.0979] * I appreciate your clarification. I was puzzled by the presence of this fingerprint. I did not see how it related to this phrase since the fingerprint icon was far from the text. [08:41:42.0187] i'm sure there is but i shouldnt have to hover to see what something means, ideally [08:43:17.0037] The word "fingerprint" was missing in the paragraph as opposed to Features that are defined in documents using the Infra Standard that can be used as a tracking vector are marked with a fingerprint icon as this paragraph is [08:43:28.0443] * The word "fingerprint" was missing in the paragraph as opposed to F > eatures that are defined in documents using the Infra Standard that can be used as a tracking vector are marked with a fingerprint icon as this paragraph is [08:43:45.0779] * The word "fingerprint" was missing in the paragraph as opposed to > Features that are defined in documents using the Infra Standard that can be used as a tracking vector are marked with a fingerprint icon as this paragraph is [08:46:06.0233] * https://infra.spec.whatwg.org/#algorithm-declaration "Declare algorithms by stating their name, parameters, and return type, in the following form: To **\[algorithm name\]**, given a \[type1\] _\[parameter1\]_, a \[type2\] _\[parameter2\]_, …,perform the following steps. They return a \[return type\]." Q1. Is it better to add parameter type? e.g. "Declare algorithms by stating their name, ****parameter typ**e,** parameters, and return type, in the following form:" Q2. why _\[parameter1\]_ is in italic? [08:46:26.0531] * https://infra.spec.whatwg.org/#algorithm-declaration "Declare algorithms by stating their name, parameters, and return type, in the following form: To **\[algorithm name\]**, given a \[type1\] _\[parameter1\]_, a \[type2\] _\[parameter2\]_, …,perform the following steps. They return a \[return type\]." Q1. Is it better to add parameter type? e.g. "Declare algorithms by stating their name, **parameter type**, parameters, and return type, in the following form:" Q2. why _\[parameter1\]_ is in italic? [08:46:55.0429] * The word "fingerprint" was missing in the paragraph as opposed to > Features that are defined in documents using the Infra Standard that can be used as a tracking vector are marked **with a fingerprint icon** as this paragraph is [08:49:13.0882] Variables are conventionally rendered in italic [08:53:41.0951] * https://infra.spec.whatwg.org/#algorithm-declaration "Declare algorithms by stating their name, parameters, and return type, in the following form: To **\[algorithm name\]**, given a \[type1\] _\[parameter1\]_, a \[type2\] _\[parameter2\]_, …,perform the following steps. They return a \[return type\]." **Q1**. Is it better to add parameter type? e.g. "Declare algorithms by stating their name, parameter type, parameters, and return type, in the following form:" **Q2**. why _\[parameter1\]_ is in italic? [08:54:43.0438] this information qualifies to a concept used by multiple standards without a good home. would it make sense to add it to the infra? [08:55:45.0991] * https://infra.spec.whatwg.org/#algorithm-declaration "Declare algorithms by stating their name, parameters, and return type, in the following form: To **\[algorithm name\]**, given a \[type1\] _\[parameter1\]_, a \[type2\] _\[parameter2\]_, …,perform the following steps. They return a \[return type\]." **Q1**. Is it better to add parameter type? e.g. "Declare algorithms by stating their name, **parameter type**, parameters, and return type, in the following form:" **Q2**. why _\[parameter1\]_ is in italic? [08:56:14.0291] * your clarification qualifies to a concept used by multiple standards without a good home. would it make sense to add it to the infra standard? 2024-01-09 [20:23:09.0936] annevk: post-holiday ping on https://github.com/whatwg/html/pull/10005 [02:02:58.0393] PSA: If you see a spam PR or issue, please label it with `invalid`. That's a label recognized by GitHub's tooling and I'm in the process of adding it to all the repositories of WHATWG standards. [06:29:12.0878] why default is written twice? [06:52:06.0083] "default value" is a placeholder [06:53:38.0374] why it is not written with italic like the parameter placeholder ? [06:56:24.0915] "parameter" is a placeholder for a variable name. See the example below. [07:07:41.0412] the example below is for an algorithm parameter not a variable parameter. A variable is declared with "let" and changed with "set" [07:30:44.0755] ..., be a new list. ..., be null. ..., is a string. after verb to be there is no italic except for ..., be _target_ why? [07:31:22.0161] * ..., be a **new list**. ..., be **null**. ..., is a **string**. after verb to be there is no italic except for ..., be **_target_** why? [07:32:31.0606] * ..., be a **new list**. ..., be **null**. ..., is a **string**. ..., is **true**. after verb to be there is no italic except for ..., be **_target_** why? [07:44:23.0086] Because target is a variable and the others are not? [07:45:00.0926] Although it seems there's a bug there as the second instance of target doesn't have italics. [07:47:56.0082] yes. [07:51:35.0124] To clarify, you are uncertain whether to use italics for the second instance of target? [07:52:51.0739] I'm not, it should be italics. [07:53:36.0977] okay [08:00:26.0285] Do you create issue for each bug you encounter? [08:09:20.0182] It's fine to create a PR directly, just make sure you can sign the agreement. [08:13:01.0575] OK yes, but does the example make it clearer why one of them is italic? [08:14:27.0635] I have never done this. I need to google it first 2024-01-10 [19:44:55.0068] Dark mode styles are being deployed. Seems that on non-HTML, this is causing us to get W3C colors temporarily. Hopefully this will stop once the bikeshed-boilerplate stuff propagates through the ecosystem? [20:28:25.0802] Yeah, not clear how often api.csswg.org gets updated, but until it gets the latest `bikeshed update`, we have W3C colors on all WHATWG specs :( [20:30:33.0186] If we want to resurrect https://github.com/whatwg/spec-factory/pull/42 and https://github.com/whatwg/whatwg.org/pull/404/ we could fix I guess [23:50:24.0698] Looks like https://resources.whatwg.org/standard.css uses a few hard-coded colors that don't really match with the dark-mode? The ones I spotted are `.element` (which is particularly outstanding), and the top links of the full page `#head nav > div > a[...]`. There a few others but they seem less problematic (like `figure.diagrams`). [01:50:29.0619] > <@kaiido:matrix.org> Looks like https://resources.whatwg.org/standard.css uses a few hard-coded colors that don't really match with the dark-mode? The ones I spotted are `.element` (which is particularly outstanding), and the top links of the full page `#head nav > div > a[...]`. There a few others but they seem less problematic (like `figure.diagrams`). Fixes would definitely be appreciated! Yeah, I noticed .element... some of these are HTML-specific and maybe should be moved to HTML's stylesheet, hmm. [01:57:50.0635] TabAtkins: sorry to ping while you're on vacation, but any idea how often the CSSWG API server runs `bikeshed update` to pull in new boilerplates? [02:00:15.0279] I thought that was instant. But you might have to trigger builds for each standard? [02:00:21.0251] No, it's not instant [02:00:29.0125] It may pull in new bikeshed releases, but it doesn't do bikeshed update [02:00:53.0348] We will *also* need to trigger new builds, but only after the CSSWG API updates [02:01:20.0645] (You can test this by running `make remote` locally on any spec; you get one with the wrong boilerplate. Whereas if you run `bikeshed update; make local`, you get the right boilerplate.) [02:01:22.0823] I think the problem is that Tab didn't generate new manifest files [02:01:29.0232] That's done automatically [02:01:30.0669] Maybe I can fix that [02:01:34.0039] No it's not [02:01:48.0046] See commit history: https://github.com/speced/bikeshed-boilerplate/commits [02:01:51.0790] https://github.com/speced/bikeshed-data/commit/9cab061e5d6c9cfffd1771698848379acfad5367 [02:02:21.0688] Hmm I wonder what the difference between the two manifest.txt files is [02:05:34.0555] The script fails for me with a syntax error... [02:05:49.0894] Python 2 vs. 3? Or 3.11 vs. 3.12 or something maybe [02:07:19.0773] Bingo, okay, I'll push an updated manifest [02:11:25.0642] Though I guess it shouldn't matter since bikeshed-data indeed appears to be source of truth. Hmm. [02:53:55.0383] Sorry, I doubt I am the right person for fixing color schemes... [05:02:56.0056] Bikeshed-data polls bikeshed-boilerplate as part of its update [05:03:59.0453] Ah and sorry, you merged the thing that needed coordination while I wasn't around 😃 [07:01:21.0997] TabAtkins: I suspect Domenic might be afk for a while, but let me know if there's anything remaining I could help with [07:01:53.0033] I'm still not technically around into next Monday but if something needs poking I can fix [07:03:10.0638] TabAtkins: I think Domenic was saying that it appears as if api.csswg.org isn't updated [07:03:30.0836] TabAtkins: and that's why various specifications are now W3C blue instead of WHATWG green [07:03:43.0534] :( [07:06:28.0897] If there's one thing bikeshed should do well, it's painting in the right colour [07:18:47.0099] Looks like things are good now, I just did a `make remote` and got whatwg colors [07:19:04.0495] So it's just a matter of pinging things to rebuild [07:22:36.0847] Thanks TabAtkins. Trying it out with whatwg/dom. [07:24:29.0298] And it worked. Hurray. [12:40:26.0427] Is there somewhere in the spec where the legacy DOM behavior of `document.myForm` access is mentioned? I know that form elements are supposed to be exposed as named properties on the window (and also globalThis) of the page, but I haven't seen references to that old (Netscape? IE?) Behavior of exposing them on the document as well. [12:42:29.0092] Oh I'm just blind [12:42:50.0164] It's right below current script on dom.html [12:48:12.0930] Named property access on the window, document and forms is just screaming for a cache. The naive "just implement the spec" approach is showing up in profiles on ladybird 🐞 😅 2024-01-11 [16:39:52.0443] Now getting CSSWG internal server errors... yeah, I think we should resurrect the run-it-ourselves PRs [16:42:39.0198] I've bugged plinss. It was broken yesterday too. [16:44:22.0677] +1 for getting this onto a server that a whole team is responsible for. It doesn't make sense to rely on 1 person. [16:56:59.0510] See also https://w3ccommunity.slack.com/archives/C010CACSKAL/p1704934117327259 [21:59:14.0853] As far as W3C hosting any replacement for https://api.csswg.org/bikeshed/, I think that’s extremely unlikely to happen. If anybody wants to know why in more detail, I can explain more. But regardless, even if W3C were to host it, that wouldn’t solve the problem of spreading out the maintenance responsibilities among a wider part of the community — because the way that W3C normally does hosting would necessarily limit shell access to the server environment to W3C staff only (or even specifically just to W3C systems-team staff). [23:38:02.0478] I think the problem is more that the whole setup is somewhat opaque without any visibility into the code or ways to report issues in a transparent manner. Not that there's no shell access. [23:52:33.0471] So maybe rather than trying to set up community hosting for the existing code that none of us know anything about or have ever actually even seen or contributed anyway, it might be better to build something from scratch based on the requirements [23:56:25.0139] Yeah, I think for now WHATWG will just install it on GitHub CI per Domenic's work. If at some point a centralized solution exists we feel comfortable with we could switch back to that. Although Domenic's back-of-the-envelope math suggests it might not be worth the effort. [02:16:40.0464] foolip: in case you don't get GitHub pings: https://github.com/whatwg/spec-factory/pull/68 [02:17:04.0746] annevk: I do, just too many :) [02:17:41.0967] Hah, I'm familiar with that problem [06:51:13.0764] If a relative websocket URL is used in a worker, should it be relative to the worker or the document URL? [07:30:01.0661] canadahonk: the worker; it's the same as any other URL [07:48:47.0232] Hmm, I regret answering. If you're still there, what made you ask that? [08:24:49.0964] annevk: 🎏 2024-01-12 [19:43:28.0697] Yeah just relying on CI seems completely reasonable to me. [06:34:59.0468] https://github.com/whatwg/infra/pull/629 2024-01-14 [09:41:55.0614] I have signed the agreement 2024-01-15 [23:20:17.0085] Matrix threads, at least as implemented on app.element.io are terrible. There's always unread notifications and nowhere to find them. The experience is so much worse than Slack. :/ [23:30:06.0330] _“There's always unread notifications and nowhere to find them”_ — exactly that, yeah. I often end up just setting the entire room to _”mark read“_, because it’s still showing there unread-messages dot— but even after checking, I can’t find any thread that has unread messages… [23:35:46.0071] In general it seems like the UI/UX of app.element.io and the Element desktop app are worse in pretty much every way than Slack and Discord too. Stuff “just works” in the Slack and Discord UIs, but in Element makes even the simple things difficult. Before I had hoped that Element UI/UX would eventually get better but it’s been this bad for so long now that at this point it seems pretty clear it’s never going to really improve significantly [23:36:17.0664] * _“There's always unread notifications and nowhere to find them”_ — exactly that, yeah. I often end up just setting the entire room to _”mark read“_, because it’s still showing that there unread-messages dot— but even after checking, I can’t find any thread that has unread messages… [23:37:15.0569] * _“There's always unread notifications and nowhere to find them”_ — exactly that, yeah. I often end up just setting the entire room to _”mark read“_, because it’s still showing that the unread-messages dot— but even after checking, I can’t find any thread that has unread messages… [23:56:18.0765] I wish there were a way to disable threads for a room [00:10:43.0769] I think I found what you have to do to get rid of the dot. Next to the (i) in the top right corner there's a threads button. But all the threads in there have a dot as well, despite having gone through those at least once in the past. I suspect it simply doesn't remember across sessions or some such. It's just bad. [00:11:29.0678] Anyway, Domenic will you be around for a while? I just remembered it's Monday and were supposed to attempt a rollout of spec-factory. [00:12:21.0036] I will not, sadly. Gym for 30 minutes then out for the night. [00:13:02.0984] Tomorrow should be doable [00:13:30.0945] Domenic: okay, I guess I'll do the RDs without spec-factory then. Sound good. [00:13:38.0643] * Domenic: okay, I guess I'll do the RDs without spec-factory then. Sounds good. [01:49:58.0026] Is there a specific label you use for this kind of PRs? If so, what is it? [02:08:17.0179] not yet. I am still thinking about it. [02:10:05.0340] * The meaning is not clear to me yet. I require more time to understand it. [02:12:11.0158] https://infra.spec.whatwg.org/#algorithm-params [02:17:16.0902] I have a question about the term resource. Is it referring to a variable name or a function name? And why do we have to write it in two different ways, one normal and one italicized? I could not find the formating rule behind it [02:21:52.0075] It's a type followed by variable name for the type. [03:39:57.0326] If it was a JS template string instead, it would be: `an optional ${type} ${parameter} (default ${defaultValue})` and the example below has for the navigationType param: type="boolean" parameter="exceptionsEnabled" defaultValue="false" [08:45:39.0587] is there a link that defines the type resource? with examples? [08:49:48.0518] real examples of algorithms that use the “resource” type, 2024-01-16 [00:51:16.0400] I think this bit in infra is an example. But I found `media resource` in https://html.spec.whatwg.org/multipage/media.html#media-resource and fetch uses the term "resource" a lot for something that is supposed to be fetched. But it doesn't seem to be defined or used in an algorithm there. [07:01:10.0064] keithamus: how do I get diff of diffs in github? I mean there is some older version of a pr and new one and I'd like to know what has changed [07:01:48.0080] (oh, and reviewing HTML spec prs is now really hard with darkmode) [07:09:12.0546] If you scroll through the timeline items it should show you the diff range. If someone has force pushed it’ll give you a link so the commit ranges. There should also be a “view changes” button in the timeline that’s personalised to you, to the last time you viewed the diff [07:09:30.0468] What makes dark mode difficult? [11:33:06.0613] There's a 'mark as read' button in the room's ... menu. It took me so long to find it, after all the threads got spontaneously marked as unread. [11:35:09.0216] I believe "resource" comes from https://httpwg.org/specs/rfc9110.html#resources [12:29:43.0894] Ooh, looks like I missed a few colors, that's on me. I'll file a PR later this week. [12:29:58.0988] At least those have bg+text declared, so they're readable in dark mode even if their coloring isn't ideal. [12:31:08.0190] > <@smaug:mozilla.org> (oh, and reviewing HTML spec prs is now really hard with darkmode) What is going wrong there? Are colors being pulled in from a place I wasn't aware of? [12:33:40.0881] TabAtkins: ooh, maybe the diff script [12:34:23.0564] I guess you can check on recent PRs [12:55:05.0948] yeah, recent diffs are quite unreadable [12:55:41.0571] TabAtkins: https://whatpr.org/html/9360/41a2b50...7978361/nav-history-apis.html#the-notrestoredreasons-interface as an example [12:56:39.0504] yup, that's awful, thanks for the heads up. I'll drop a PR shortly. 2024-01-17 [18:29:38.0473] Even after doing that thing with the threads button, you can still end up with Element showing that you have unread messages. My element’s been that way for a long time. The only thing which does actually work in that case is to do what Jeffrey said and just use the 'mark as read' button. This is apparently a known issue — see https://github.com/element-hq/element-web/issues/24392 (raised nearly a year ago…). And unfortunately, there’s no option to completely disable threads in Element — see https://github.com/element-hq/element-meta/issues/1090. Per comments in that issue, the Element product team has intentionally chosen not to provide any such disable-threads option — despite the stuck-notifications bug. And given their track record on fixing bugs, it’s very unlikely they’re going to get the stuck-notifications bug fixed any time soon. [18:30:11.0327] * Even after doing that thing with the threads button, you can still end up with Element showing that you have unread messages. My element’s been behaving that way for a long time. The only thing which does actually work in that case is to do what Jeffrey said and just use the 'mark as read' button. This is apparently a known issue — see https://github.com/element-hq/element-web/issues/24392 (raised nearly a year ago…). And unfortunately, there’s no option to completely disable threads in Element — see https://github.com/element-hq/element-meta/issues/1090. Per comments in that issue, the Element product team has intentionally chosen not to provide any such disable-threads option — despite the stuck-notifications bug. And given their track record on fixing bugs, it’s very unlikely they’re going to get the stuck-notifications bug fixed any time soon. [18:54:14.0877] PSA: W3C is organizing a remote-only “Breakouts Day” to be held on March 12th. This is an additional day of breakout sessions like the day that’s held during the W3C TPAC each year face-to-face — except this additional one is remote-only. You can propose a breakout session by going to https://github.com/w3c/breakouts-day-2024/issues/new/choose to create a session proposal — though per https://github.com/w3c/breakouts-day-2024/#who-can-propose-a-session you need to be participant in a W3C group to do that. But that includes W3C Community Groups — and you can directly join on your own any W3C Community Group you want to by going to https://www.w3.org/community/ If you want to get some idea of what kind of topics are in scope, at https://www.w3.org/2023/09/TPAC/breakouts.html#grid you can browse through a hyperlinked table of the titles of the breakout sessions that were held at TPAC 2023 in Sevilla. [18:54:43.0003] * PSA: W3C is organizing a remote-only “Breakouts Day” to be held on March 12th. This is an additional day of breakout sessions like the day that’s held during the W3C TPAC each year face-to-face — except this additional one is remote-only. You can propose a breakout session by going to https://github.com/w3c/breakouts-day-2024/issues/new/choose to create a session proposal — though per https://github.com/w3c/breakouts-day-2024/#who-can-propose-a-session you need to be a participant in a W3C group to do that. But that includes W3C Community Groups — and you can directly join on your own any W3C Community Group you want to by going to https://www.w3.org/community/ If you want to get some idea of what kind of topics are in scope, at https://www.w3.org/2023/09/TPAC/breakouts.html#grid you can browse through a hyperlinked table of the titles of the breakout sessions that were held at TPAC 2023 in Sevilla. [01:48:46.0672] Anyone has input about the `pageconceal` event concrete proposal? zcorpan smaug ? I made some progress on the specifics, see https://github.com/whatwg/html/issues/9702#issuecomment-1895379770 [01:51:39.0844] (This is the last blocking issue for cross-document view-transitions!) [02:03:05.0850] Noam Rosenthal: left a comment. Thanks for working on this! [02:05:53.0907] We should just have a bot that kicks anyone who replies in thread [13:36:53.0052] annevk or whoever: do you know why Fetch provides `.arrayBuffer` instead of `.uint8Array`? various other places generally prefer vending `Uint8Array`, and I found https://github.com/whatwg/fetch/issues/1724#issuecomment-1814626681 which says that "We decided that we'd use Uint8Array generally for byte buffer representation." [13:37:14.0116] maybe it's just that the `arrayBuffer` method predates the more general tendency to prefer `Uint8Array`? [14:17:47.0657] Arthur Hemery (and Camille Lamy): what do you think about proposing a “Breakouts Day” session on your proposal for https://github.com/whatwg/html/issues/6364? It might be a way to get some more webkit/gecko input and make some progress. See sideshowbarker’s post above about the breakouts day. 2024-01-18 [21:30:37.0634] > <@bakkot:matrix.org> maybe it's just that the `arrayBuffer` method predates the more general tendency to prefer `Uint8Array`? I think this is likely. [21:40:27.0733] Figure there's any appetite for adding a `.bytes()` method to get a Uint8Array? It feels a bit unnecessary given that you can just do `new Uint8Array(await body.arrayBuffer())`, but it would be more consistent in allowing people to never think about ArrayBuffers [21:56:01.0756] I think so. Seems uncontroversial, but also the kind of thing that would benefit from someone being willing to submit patches since it's not exactly fitting into any team's quarterly goals. [23:45:05.0730] bakkot: that seems reasonable. We'd have to add it to some other APIs too that copied Fetch. And maybe we should annotate `arrayBuffer()` somehow so it doesn't get copied further. [23:59:40.0770] a quick glance through https://dontcallmedom.github.io/webidlpedia/names/ArrayBuffer.html suggests it has been copied only to PushMessageData and Blob, which isn't too bad so far [00:00:10.0543] Yeah, that sounds about right. [00:00:23.0515] FileReader also has `readAsArrayBuffer` which is a bit odd [00:00:58.0491] Right, we don't have to care about updating FileReader though. It's kinda like XHR (which also has responseType = "arrayBuffer" come to think of it). [00:01:43.0926] huh, wonder why that doesn't show up on the WebIDLpedia page [00:01:47.0320] anyway yeah [00:02:04.0920] Probably because it's an enum value? [00:02:19.0083] * Right, we don't have to care about updating FileReader though. It's kinda like XHR (which also has responseType = "arraybuffer" come to think of it). [00:02:42.0245] I'd expect it to show up in the algorithm, though. maybe the enum value gets threaded through to Fetch? [00:03:07.0458] anyway, if "things which vend bytes should vend Uint8Arrays specifically, not ArrayBuffer" is indeed a general principle to follow, might also be worth documenting in the design principles? [00:14:36.0207] bakkot: XHR has responseType (takes an enum) and response (which returns the type corresponding to the enum) [00:21:12.0736] hmm, https://xhr.spec.whatwg.org/#the-response-attribute does refer to "a new ArrayBuffer object", and ArrayBuffer links; not sure why WebIDLpedia wouldn't pick up on it. [00:21:18.0122] possibly because of https://github.com/whatwg/xhr/issues/376 I guess [00:21:25.0286] anyway, not super important [00:58:31.0323] bakkot: I think you are confusing the IDL index with https://dontcallmedom.github.io/webdex/a.html#ArrayBuffer%40%40%40%40interface [00:58:53.0972] bakkot: response uses any in its IDL which is why it's not on WebIDLpedia [05:16:33.0286] Andreas Kling: https://twitter.com/eatonphil/status/1747732476468826446 hah! The independent SQL implementation WebSQL wanted, but never got. 2024-01-19 [05:42:33.0603] https://github.com/whatwg/html/issues/10056 - is fetch priority only for the server? I thought the browser would use it somehow [08:37:57.0543] > <@annevk:matrix.org> Hmm, I regret answering. If you're still there, what made you ask that? Sorry just saw. Implementing relative URLs and got confused by harness URLs (eg `.worker.any.js` vs `.worker.any.html`) [08:48:02.0237] > <@annevk:matrix.org> Hmm, I regret answering. If you're still there, what made you ask that? * Sorry just saw. Implementing relative URLs and got confused by harness URLs (eg `.worker.any.js` vs `.worker.any.html`). It was only noticeable in the `?` test since that is the only test which should have the full worker URL in it [13:18:01.0223] annevk: Okay I've poked around a little two times now, and can't find where the diff styles on whatpr.org are sourced from. They're inserted as an inline style block, so presumably it's from the diff script somehow, which I also can't find. (It's not from the W3C diff JS, either.) Any help? [13:21:53.0404] (whatpr.org isn't hosted on the whatwg/ org, as far as I can tell...) 2024-01-20 [00:20:30.0200] TabAtkins: It's from https://github.com/w3c/htmldiff-ui. I suspect it also impacts W3C documents relying on PR Preview? [00:21:25.0471] TabAtkins: whatpr.org is our own PR Preview domain. I didn't want ugly S3 URLs all over the place. [00:33:05.0382] TabAtkins: See https://github.com/w3c/htmldiff-ui/blob/main/htmldiff.pl#L314-L331 (if you mean other styles I need a more specific question I think) [01:36:44.0673] Just to pile on the Bikeshed API server a bit more, it seems like it hasn't been updated since a random commit in September, https://github.com/speced/bikeshed/issues/2762 [01:37:47.0856] Someone should write a version of htmldiff.pl that doesn't insert random spaces everywhere 2024-01-22 [23:30:55.0059] Domenic: I was looking at https://github.com/web-platform-tests/wpt/pull/21041 again and I think they match implementations, but not the spec. The spec grabs the document when calling parseFromString(). But implementations (and the tests) assume it's grabbed as part of the DOMParser invocation. [23:31:39.0680] Domenic: I prototype'd the spec in https://github.com/WebKit/WebKit/pull/22971 and got a number of test failures. [23:33:17.0835] There's also some differences across implementations from code inspection. Only Gecko seems to carry over the base URL. And Gecko caches the URL when DOMParser is constructed. So pushState() doesn't impact it. (This fails some tests, though a design like that might be simpler in certain ways.) [23:34:04.0292] Hmm, good catch. Strange that I added tests specifically for this sort of multi-global madness but didn't match the spec when doing so. [23:44:28.0933] > <@annevk:matrix.org> Domenic: I was looking at https://github.com/web-platform-tests/wpt/pull/21041 again and I think they match implementations, but not the spec. The spec grabs the document when calling parseFromString(). But implementations (and the tests) assume it's grabbed as part of the DOMParser invocation. Wait, no, I think the tests match the spec. "this's relevant global object's associated Document" is equivalent to the global at the time `new DOMParser()` was called; `new DOMParser()` creates `this`. [23:44:46.0084] Your patch prototypes using the current global object's associated Document, which is not what the spec says. [23:49:24.0454] Domenic: interesting, thanks! So whenever we use relevant I guess we implicitly require the implementation to store a reference in the constructor. I guess that makes sense. [23:52:52.0271] Yeah, I kind of thought all implementations already did that? Web IDL certainly assumes it. [23:53:02.0741] At least a reference to the global, from which you can get the document [23:54:14.0732] Domenic: It looks to be manual in all three implementations. Chromium and WebKit even use a WeakPtr which worries me a little bit, but it's hard to force GC in tests so not sure if my concerns are well-founded. [23:55:32.0053] Hmm yeah, in Chromium there's a variety of easy utility classes and templates you can inherit from I guess, but that makes sense. [23:55:48.0806] Or maybe there's just some leftover code in DOMParser that's redundant with more recent IDL developments? [02:47:01.0851] I see that https://github.com/WICG/identity-credential/blob/main/digital-credentials-2-proposal.md (frontend web-platform API for “Digital Credentials”) seems to have gotten some implementor interest. I don’t really know much of anything about credentials/identity stuff, except some incidental awareness of the W3C Verifiable Credentials and Decentralized Identifiers (DID) stuff — and only then, because the groups working on those things are at the W3C. So is the implementor interest in WICG Digital Credentials also an indicator that implementors now see W3C Verifiable Credentials (and maybe DID also) as something actually possibly relevant for the web platform? I’ve gleaned that W3C Verifiable Credentials are just one possible data format for Verifiable Credentials — and the WICG Digital Credentials draft cites a protocol spec at https://openid.net/specs/openid-4-verifiable-presentations-1_0.html which mentions W3C VC but also an “ISO mdoc” data format that seems to be for basically the same thing. Anyway, I’m basically just wondering whether there’s now actually enough browser-implementor interest in this stuff — in integrating it into the web platform through frontend APIs — that I should actually start paying attention to any of it. [06:02:52.0725] How come https://url.spec.whatwg.org/ isn't WHATWG green? [06:05:14.0489] Refresh? There was a CI issue earlier [06:05:34.0507] * Refresh? There was a CI issue earlier [06:05:43.0801] > <@ms2ger:igalia.com> Refresh? There was a CI issue earlier Doesn't help. I guess there's a sticky cache somewhere. [06:05:59.0483] I was seeing green from my own cache. Probably the build step needs to run again [06:07:51.0555] cc annevk [07:08:11.0599] Yeah, Domenic and I should deploy some spec-factory changes. But also, turns out i18n-glossary is at it again squatting on UTF-8 making it impossible to build the URL Standard: https://github.com/w3c/i18n-glossary/issues/66 :/ [10:13:59.0237] I had missed that Gecko now passes most URL tests. Nice work! 2024-01-23 [23:32:19.0700] bakkot: I thought that when you detached a view its [[ByteLength]] would be 0? [23:43:55.0437] annevk: you detach buffers, not views [23:44:42.0884] detaching a buffer does indeed set its [[ArrayBufferByteLength]] to 0 but it doesn't reach out and also update the views of that buffer [00:03:19.0386] bakkot: it seems implementations treat it as 0 so I guess we some kind of length getter that accounts for detachment [00:03:33.0461] Assuming https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0As%20%3D%20new%20Uint8Array(new%20ArrayBuffer(8))%3B%0ApostMessage(s%2C%20%22*%22%2C%20%5Bs.buffer%5D)%3B%0Aw(new%20TextEncoder().encodeInto(%22fd%22%2C%20s))%3B%0A%3C%2Fscript%3E is a valid test [01:25:39.0634] zcorpan: Can you help me understand https://github.com/web-platform-tests/wpt/blob/master/css/css-ui/compute-kind-widget-generated/kind-of-widget-fallback-checkbox-input-background-attachment-001.html and friends? If you disable the auto appearance, wouldn't you get appearance:none? But that's not what's expected. [02:49:49.0629] annevk: sure. The test is correct, but the title is misleading/incorrect. [02:52:57.0071] annevk: looks like the build script doesn't know what the pass condition should be, it's only in the reference. I can make the title not say what is expected [03:03:53.0160] annevk: https://github.com/web-platform-tests/wpt/pull/44138 [06:41:35.0983] annevk: no pressure but just want to check that on https://github.com/whatwg/html/pull/9804 you are not waiting for me for something? It can get hard for me to follow these are all resolved, but I believe this is back to you now, right? [07:05:36.0635] thank you annevk [08:05:49.0658] bakkot: hey so are you sure about ByteLength? That might be a bug as at least implementations do set it to 0 [08:05:53.0900] bakkot: see https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0As%20%3D%20new%20Uint8Array(new%20ArrayBuffer(8))%3B%0Aw(s.buffer.byteLength)%0Aw(s.byteLength)%3B%0ApostMessage(s%2C%20%22*%22%2C%20%5Bs.buffer%5D)%3B%0Aw(s.buffer.byteLength)%0Aw(s.byteLength)%3B%0Aw(new%20TextEncoder().encodeInto(%22fd%22%2C%20s))%3B%0A%3C%2Fscript%3E [08:14:59.0638] bakkot: https://tc39.es/ecma262/#sec-get-%typedarray%.prototype.bytelength suggests to me you're prolly wrong [08:29:57.0634] Panos Astithas: it seems i18n might wanna discuss a number of things in Feb: https://github.com/w3c/i18n-activity/labels/Agenda%2BI18N%2BWHATWG [15:39:39.0331] Hello all. I've identified a slight difference in behavior between Firefox and Chrome that is making a health insurance website I use to malfunction in Firefox. The difference appears to be that, when the checkedness of a radio button is set (via the checked property), Firefox sets the dirty checkedness flag on all inputs in its radio button group, while Chrome does not. The reproduction is here: https://jsfiddle.net/9j6wcxqu/2/ . On Firefox, this testcase logs false false, while on Chrome it logs false true. I can't find any discussion of this. Does my assessment of the issue seem correct? If so, which behavior is more correct? I can't find any explicit statement in the spec supporting Firefox's behavior, but it might have some logic to it. [15:40:02.0552] * Hello all. I've identified a slight difference in behavior between Firefox and Chrome that is causing a health insurance website I use to malfunction in Firefox. The difference appears to be that, when the checkedness of a radio button is set (via the checked property), Firefox sets the dirty checkedness flag on all inputs in its radio button group, while Chrome does not. The reproduction is here: https://jsfiddle.net/9j6wcxqu/2/ . On Firefox, this testcase logs false false, while on Chrome it logs false true. I can't find any discussion of this. Does my assessment of the issue seem correct? If so, which behavior is more correct? I can't find any explicit statement in the spec supporting Firefox's behavior, but it might have some logic to it. 2024-01-24 [16:21:55.0764] Digging around a bit more, this behavior in Firefox appears to be very old. It seems to be have been introduced in 2001, 23 years ago. Here is the associated bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=108308 . [16:23:02.0474] * Digging around a bit more, this behavior in Firefox appears to be very old. It seems to be have been introduced in 2001, 23 years ago. Here is the associated bugzilla bug: https://bugzilla.mozilla.org/show\_bug.cgi?id=108308 . This also gives me more confidence that my assessment is correct. [16:23:28.0481] * Digging around a bit more, this behavior in Firefox appears to be very old. It seems to be have been introduced in 2001, 23 years ago. Here is the associated bugzilla bug, including some discussion of the design: https://bugzilla.mozilla.org/show\_bug.cgi?id=108308 . This also gives me more confidence that my assessment is correct. [17:05:45.0893] Safari logs false true for https://jsfiddle.net/9j6wcxqu/2/ [17:20:04.0812] Thanks for the heads up, should I add them to the same meeting as the existing one or in future meetings? [17:20:14.0895] I don’t find anything in the spec that says anything about setting the dirty checkedness flag on all elements in radio button group after the dirty checkedness has been set on one element which happens to be in that group. Ari Entlich So you probably want to file a bug report at https://bugzilla.mozilla.org/enter_bug.cgi?format=__default__&product=Core&component=DOM%3A%20Core%20%26%20HTML [17:20:30.0346] * I don’t find anything in the spec that says anything about setting the dirty checkedness flag on all elements in a radio button group after the dirty checkedness has been set on one element which happens to be in that group. Ari Entlich So you probably want to file a bug report at https://bugzilla.mozilla.org/enter\_bug.cgi?format=\_\_default\_\_&product=Core&component=DOM%3A%20Core%20%26%20HTML [23:32:36.0332] annevk: What time will the Feb 22 meeting referred to in https://github.com/whatwg/html/issues/5121#issuecomment-1857601843 be at and how do I get myself invited? [23:40:23.0321] hsivonen: they'll join the WHATNOT meeting [23:41:06.0367] I think the same one. We should just start with this and hopefully cover everything they want to talk about. [23:41:26.0392] > <@annevk:matrix.org> hsivonen: they'll join the WHATNOT meeting WHATNOT isn't findable by the usual search engines. [23:43:08.0762] > <@hsivonen:mozilla.org> WHATNOT isn't findable by the usual search engines. Looks like I need site:github.com instead of site:whatwg.org, but even so, can't find the time for that particular day. [23:44:06.0332] hsivonen: apologies, I thought you were on the invite list. Do you want to join just that meeting? [23:44:25.0837] > <@annevk:matrix.org> hsivonen: apologies, I thought you were on the invite list. Do you want to join just that meeting? A calendar invite for just that meeting would be great, yes. [23:45:46.0159] hsivonen: invited your corporate account, assume that's the one you use for Google Meet [23:46:06.0984] > <@annevk:matrix.org> hsivonen: invited your corporate account, assume that's the one you use for Google Meet Yes. Thanks! [23:46:41.0894] Domenic: how are you feeling today and doing for time? [23:48:10.0042] > <@annevk:matrix.org> Domenic: how are you feeling today and doing for time? Today's good, at a doctors appointment for the next 30-60 minutes though [00:26:47.0952] Ari Entlich: sideshowbarker: this is the relevant requirement I think: > When the checked content attribute is added, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to true; when the checked content attribute is removed, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to false. [00:27:56.0133] Coupled with these requirements for the IDL attribute: > The checked IDL attribute allows scripts to manipulate the checkedness of an input element. On getting, it must return the current checkedness of the element; and on setting, it must set the element's checkedness to the new value and set the element's dirty checkedness flag to true. [00:28:01.0816] It seems to me that Firefox is correct. [00:29:29.0482] Ooh wait. Actually, it only sets dirtiness for a single element. So I guess Firefox is wrong, though arguably its behavior makes more sense than Chromium/WebKit. [00:31:36.0168] Maybe there was an intervening spec change years ago that inadvertently changed the required behavior? [00:32:13.0216] well, or maybe the Firefox behavior predates when this was first properly specced [00:35:28.0696] annevk: What in the Web Platform is known to set `beStrict` to true in https://url.spec.whatwg.org/#idna ? AFAICT, nothing in Gecko does. I'm trying to figure out if ICU4X should support the `beStrict = true` case. [00:35:42.0409] (My current thinking is not supporting Transitional processing in ICU4X.) [00:37:39.0199] Also interesting: https://bugzilla.mozilla.org/show_bug.cgi?id=1788115 [00:38:32.0728] hsivonen: validation only; domain to ASCII is intentionally not exported. Maybe file a bug for a note as it seems worth stating explicitly. [00:39:44.0091] hsivonen: And good to see those fixed! I think we still need another round with the Unicode UTS46 folks as they made some changes last year, but not all the ones we wanted and they also broke some tests. [00:40:19.0077] hsivonen: If you have time to help with sorting that through as part of ICU4X that'd be nice. [00:40:53.0521] hsivonen: https://github.com/whatwg/url/labels/topic%3A%20idna [00:43:11.0382] So beStrict = true is needed for checking content for conformance but not for browser processing of anything? [00:46:08.0076] hsivonen: correct. [00:46:31.0125] hsivonen: created for validator.nu (and friends). [00:47:45.0722] I see. I guess now I will have to check how much it costs in binary size to carry around browser-irrelevant data. (At run time, I expect it to cost one ALU register masking operation per input scalar value, so not much.) [01:26:42.0020] Sad: https://github.com/ogham/dog/issues/75 [01:30:16.0506] hsivonen: yeah that's a well-known problem. Though I think still not standardized in TLS even... [01:33:09.0038] Recurring theme for me: I'm writing a Rust crate that does something that an existing crate does, but hopefully faster. I investigate doing a drop-in replacement shim and I find that the existing crate does more things, but it's not clear to me how well those more things are use-case-motivated. [02:18:14.0376] Ooh. Now I see the logic in the STD3-special-cased characters. Clearly it's a bad idea to store the STD3-disallowed bit on a per input character basis, and instead one should inspect the output for STD3-disallowed ASCII. [02:24:44.0352] TabAtkins: I see Bikeshed now provides tooltips for terms but them disappearing once you want to select text is rather annoying. E.g., navigate to https://xhr.spec.whatwg.org/#ref-for-progressevent%E2%91%A0%E2%91%A4 and hover over "ProgressEvent" at the bottom of the Acknowledgments section. Attempt to interact with the seemingly clickable link and other aspects of the tooltip. [02:25:38.0992] I guess this is popover? Hmm. [02:51:03.0526] PSA: All WHATWG standards now build Bikeshed on CI instead of api.csswg.org (we still use api.csswg.org for PR Preview however). If you see anything weird please reach out to Domenic and I per usual. [02:53:37.0773] As a side effect WHATWG green is now restored across all standards. Just hit refresh. [09:33:48.0028] annevk: Argh, it's resetting when you hover over the contained link. Getting these events set up correctly is tricky, sorry about that. I'll file and fix in a bit. [10:09:03.0495] annevk: 4.1.1 uploaded with the fix [11:55:12.0869] * annevk: 4.1.2 uploaded with the fix [15:10:07.0724] Hmm. For https://github.com/whatwg/html/pull/10085 how should I properly refer to `NavigationHistoryEntry`, which is defined in browsing-the-web, in Location, which is part of nav-history-apis? [15:17:15.0605] Eh. Well I got it to make *a* link, but it doesn't seem like the right link in the diff page [15:18:01.0591] Oh no, it's the right link. Yay. 🦆 2024-01-25 [16:02:00.0667] Sounds like a plan [17:17:09.0859] I have one additional question about how the spec is written. In defining the dirty checkedness flag, it says: "[the dirty checkedness flag] must be set to true whenever the user interacts with the control in a way that changes the checkedness". However, elsewhere it states that setting the checked IDL attribute also sets the flag. Is this some special definition of "user" that the spec is using, including both human and script users? Or is it just incorrect/incomplete/ambiguous? The definition of the dirty value flag includes similar language but also says "(It is also set to true when the value is programmatically changed, as described in the definition of the value IDL attribute.)", which makes me think the answer is the latter? [17:31:07.0668] * I have one additional question about how the spec is written. To define the dirty checkedness flag, it says: "\[the dirty checkedness flag\] must be set to true whenever the user interacts with the control in a way that changes the checkedness". However, elsewhere it states that setting the checked IDL attribute also sets the flag. Is this some special definition of "user" that the spec is using, including both human and script users? Or is it just incorrect/incomplete/ambiguous? The definition of the dirty value flag includes similar language but also says "(It is also set to true when the value is programmatically changed, as described in the definition of the value IDL attribute.)", which makes me think the answer is the latter? [18:38:55.0223] * I have one additional question about how the spec is written. To define the dirty checkedness flag, it says: "\[the dirty checkedness flag\] must be set to true whenever the user interacts with the control in a way that changes the checkedness". However, elsewhere it states that setting the checked IDL attribute also sets the flag. Is this some special definition of "user" that the spec is using, including both human and script "users"? Or is it just incorrect/incomplete/ambiguous? The definition of the dirty value flag includes similar language but also says "(It is also set to true when the value is programmatically changed, as described in the definition of the value IDL attribute.)", which makes me think the answer is the latter? [18:38:55.0225] > <@akaster:serenityos.org> Hmm. For https://github.com/whatwg/html/pull/10085 how should I properly refer to `NavigationHistoryEntry`, which is defined in browsing-the-web, in Location, which is part of nav-history-apis? The multipage filenames do not have any impact, really :) [22:32:21.0635] Ari Entlich: those are complimentary requirements. [22:35:55.0331] It doesn't say "must be set to true *only* when the user interacts". [00:15:38.0860] annevk: with URLSearchParams no longer being serializable, we have a problem for such objects stored in an indexeddb. The spec afaict assumes deserialization steps will be defined (step 22 .. 24 in https://html.spec.whatwg.org/multipage/structured-data.html#structureddeserialize ) [00:18:11.0511] annevk: options: throw (data loss), {} (data loss), serialize to a string, serialize to a plain object, serialize to URLSearchParams [00:22:35.0640] I think deserializing to URLSearchParams is best. At some point in the future we can throw or return null instead [00:35:18.0445] It never was serializable? But maybe it was in Gecko? In any event, throwing or continuing to return the object seems okay I suppose. But that's not really a web platform problem as the web platform didn't support serialization to begin with. [00:36:45.0468] * Ari Entlich: those are complementary requirements. [00:39:23.0393] annevk: it was in Gecko [01:37:25.0011] how did gecko serialize? toString? [01:38:58.0856] TabAtkins: heya, just in case you didn't see my GitHub ping: https://github.com/whatwg/url/pull/812 [01:53:18.0235] freddy: to something that deserializes back to a URLSearchParams object [01:54:05.0680] oh, so a custom serialization that wasn't fully exposed in itself, just as observable behavior. Gotcha :) [01:55:39.0470] freddy: see step 19 onwards in https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal (but the spec didn't specify that URLSearchParams was serializable) [07:04:33.0377] Why do WHATWG steps do this weird thing now that can be reproduced by going to https://infra.spec.whatwg.org/#strings, clicking on the "string" definition and not being able to immediately get a link to that term even by clicking on #string at the top of the grey box? [07:05:31.0278] When I click on #string in the grey box, I don't get navigated to #string (which is what happened in the past), and the grey box moves really slowly in this animation to the bottom left of the screen [07:05:51.0545] I guess the reference box just seems a tiny bit harder to use now, is what I'm trying to articulate. [07:06:34.0751] If I click on anything else in the box, and *then* click on #string at the top, I finally get the fragment navigation to #string [07:06:38.0799] Dominic Farolino: I noticed that too, mind filing at https://github.com/speced/bikeshed/issues/new? Would help TabAtkins with fixing. [07:07:10.0809] Sure thing [07:07:28.0430] I don't see this on other bs specs so I figured it was a WHATWG thing maybe. But yeah, filing an issue is a good start. [07:29:45.0355] annevk: Do you know the difference between https://html.spec.whatwg.org/C#insert-an-element-into-a-document and https://html.spec.whatwg.org/C#becomes-connected? The question reduces to what is the difference between "in a document tree" and "connected". Sorry if that's a dumb question, it probably has to do with shadow DOM which I don't know much about. [07:38:13.0763] Dominic Farolino: I think you found the answer, no? If you follow the links those terms are explained. [07:55:15.0414] Can a node's a shadow-including root ever be a `ShadowRoot` itself? Or is the top-most root always a "normal"(?) node, under which Shadows can exist? [08:54:39.0681] Dominic Farolino: You cannot create a shadow root without a host. So the shadow-including root is always an Element, DocumentFragment, or Document I think. [08:56:25.0628] Above I should also have said that generally we prefer the "becomes connected" concept when we can move things toward it. The former is a bit of a leftover from the "before shadow tree days", iirc. [09:18:19.0943] Makes sense, thank you. [10:23:17.0393] annevk: https://github.com/speced/bikeshed/issues/2772 2024-01-26 [16:05:44.0965] shu: any ideas how long you'd expect microwait need to wait to be useful? [16:07:40.0697] Also, this feels a bit like something where if used in benchmarks, UA might want to keep the cpu as busy as possible while waiting, leading effectively to the current loop. I wonder how to avoid that [17:18:54.0328] Ugh, the definition panels are indeed quite a mess. The fact that they vary per Bikeshed deploy is frustrating too. [17:19:54.0727] I guess if we wanted to get control of them back we'd need to take back the maintenance burden though. Since Bikeshed kept updating its markup for the definition panels, and our scripts/styles weren't keeping up, we lost the ability to control how they look and behave. [23:26:48.0695] We can manually deploy now. We might be able to call that via some API so we're at least consistently bad. 🙃 [07:46:38.0295] The API server breaking its release hooks is frustrating, it needs fixing. [07:47:29.0207] Domenic: Check the latest Bikeshed version, see if anything still feels wrong. If so, happy to discuss fixes. [08:15:18.0269] Is anyone investigating PR Preview breaking all over? Or is that limited to WHATWG repositories? [08:16:04.0722] Maybe some of the metadata changes caused it to no longer work? [08:30:28.0067] I'm not seeing breakages on non-WHATWG repos for what it's worth. Occasionally maybe, but not too frequently. [08:44:02.0080] Domenic: I vaguely suspect this is related to the "die on" change [09:37:29.0488] > <@smaug:mozilla.org> shu: any ideas how long you'd expect microwait need to wait to be useful? i don't know if there's a distribution we can point to. my gut feeling is pretty app dependent [09:38:40.0302] emscripten folks were interested in instrumenting Photoshop to see what distribution of main thread busyloop wait times they could come up with but as these things go, instrumentation isn't turning out to be so easy [09:52:19.0382] What is microwait? [09:53:17.0951] https://github.com/syg/proposal-atomics-microwait [13:43:28.0634] This might be a dumb question but where do we ever set a node's parent to null, once we https://dom.spec.whatwg.org/#concept-node-remove it? Does this happen implicitly somewhere? [14:04:04.0217] The only thing I can think of is that "An object A whose parent is object B is a child of B" tries to imply this, but I really don't think it does. Otherwise, I don't see how/when parent becomes null. 2024-01-27 [02:45:16.0704] Dominic Farolino: I think children are managed explicitly nowadays, but parent is indeed not. I don't think I'd mind if we changed that, but someone would have to think it all through. 2024-01-28 [08:05:05.0957] Not sure if PR Preview is broken or if I am just holding it wrong: https://github.com/whatwg/websockets/pull/48 [09:39:54.0753] Adam Rice: pretty sure it's broken due a recent set of changes. I hope Domenic can have a look tomorrow or so [10:56:09.0569] Hm, I'm pretty curious what those changes might be; api.csswg.org is still claiming that it's using a version of Bikeshed from September. 2024-01-29 [16:33:35.0631] Okay, told plinss about the delayed Bikeshed update; looks like it was because the server it was running on couldn't support one of my dependencies. He migrated it to a new server, it should be visible and up-to-date in a bit. [16:33:46.0348] * Okay, told plinss about the delayed Bikeshed update; looks like it was because the server it was running on couldn't support one of my dependencies. He migrated it to a new server, it should be visible and up-to-date in a bit, once DNS updates propagate. [16:34:00.0888] I just tried it on the temp URL and it looked like it was working fine. [22:07:03.0234] I think the September version of Bikeshed was choking on the new `Dies On` metadata key in the WHATWG boilerplate [22:07:22.0993] It indeed seems fixed now, e.g. https://github.com/whatwg/streams/pull/1303 got a preview [23:42:12.0784] I guess the one change is that we no longer get a preview when there's an error, but I guess that's okay. 2024-01-30 [22:59:17.0313] Hi everyone, My name is Raviteja, and I'm currently pursuing my B.Tech in Information Technology at the International Institute of Information Technology Bhubaneswar. I've carefully reviewed the project details, code of conduct, and the project itself. I'm excited to start contributing to the WHATWG-HTML Standard with some good first issues. I have hands-on experience with web development ,So i guess it shouldn't be a big problem. I'm thrilled to be part of this community and hope to make meaningful contributions. I believe introducing myself is a good first step. I'm open to any suggestions and feedback you might have. Thanks, Raviteja [03:22:50.0044] I wonder why the first comment in https://github.com/whatwg/html/pull/9360 has multiple preview/diff links [04:36:24.0221] smaug: I'll fix that [04:40:21.0337] I suspect they removed the comment that says it cannot be removed [06:05:35.0080] and would be nice to get dark mode fixed 😉 (or backed out) [06:05:42.0181] diffs are still impossible to read [06:05:51.0762] so need to switch to light mode [06:09:45.0786] I'll leave that to TabAtkins and Domenic [06:18:42.0359] * need to switch to light mode [07:06:57.0703] Yeah, apologies, I've been extra busy. [07:07:04.0105] I'll try to get it done today [07:07:15.0098] Color suggestions welcome btw [14:10:16.0359] These colors look reasonable to y'all? [14:10:31.0011] smaug especially [14:11:04.0537] That is easy to read, yes [14:23:55.0461] All right, https://github.com/w3c/htmldiff-ui/pull/10 filed 2024-01-31 [01:58:58.0899] Folks here might be interested in https://github.com/w3c/uievents/issues/369 [06:33:53.0414] Maybe moving it to WHATWG is an option if the motivation is effectively working around W3C Process