2021-08-01 2021-08-02 [02:58:24.0400] Can someone point out to me what the errors are which are causing https://github.com/whatwg/html/pull/6921/checks?check_run_id=3205414516 to fail? [03:23:57.0007] jgraham: https://github.com/whatwg/html/pull/6921/checks?check_run_id=3205414516#step:3:91 ``` unloaded, , then invoke WebDriver BiDi navigation failed with ``` The `, ,` there, I guess? (And possibly some other things after — I stopped looking when I found that `, ,`…) [03:39:07.0053] sideshowbarker: Apparently not :( Would be nice if this would print out which lint rules are actually failing in each case [03:39:36.0296] (for clarity: I fixed the `, ,` and still get the errors) [05:10:06.0715] jgraham: I’ll check out the branch now, and try to see if I can debug it locally [05:37:24.0859] jgraham: the one that’s failing is this: > perl -ne '$/ = "\n\n"; print "$_" if (/chosing|approprate|occured|elemenst|\bteh\b|\blabelled\b|\blabelling\b|\bhte\b|taht|linx\b|speciication|attribue|kestern|horiontal|\battribute\s+attribute\b|\bthe\s+the\b|\bthe\s+there\b|\bfor\s+for\b|\bor\s+or\b|\bany\s+any\b|\bbe\s+be\b|\bwith\s+with\b|\bis\s+is\b/si)' "$1" | perl -lpe 'print "\nPossible typos:" if $. == 1' [05:37:36.0464] will look further [05:38:00.0586] (And by the way I did not write this code.) [05:39:03.0683] Would be nice if it printed the actual re match along with the paragraph [05:40:23.0548] indeed yeah it would be nice [05:40:28.0031] this is nuts [05:40:47.0048] anyway, I spotted a possible cause [05:41:01.0196] “with with” [05:41:12.0173] in lines 2-3 of the patch [05:41:25.0969] will try fixing that now and re-testing [05:44:26.0441] OK yeah, fixed three instances of that, and have one remaining other yet-unknown cause. Checking further… [05:44:47.0075] ah, same — “with with” [05:45:21.0212] yup, all fixed [05:45:30.0645] will push a commit to your branch [05:46:15.0332] …and done [05:47:12.0241] sorry about that linter — we need to fix that [06:03:07.0781] sideshowbarker: Thanks! [06:12:58.0185] cheers 2021-08-03 [06:21:32.0095] sideshowbarker: Domenic: if you could look at https://github.com/whatwg/dom/pull/1004 at least up until line 2100 that'd be terrific [06:27:57.0256] annevk: will look now [07:53:25.0299] Thanks sideshowbarker. To be clear though, I was thinking of aligning more prose with this new model if it looks good. There's actually quite a lot of text is impacted. [07:54:00.0639] annevk: so you want suggestions on what else needs to be changed? [07:54:25.0726] sideshowbarker: no, just if this direction looks good as a thing to expand upon; I can find the rest :-) [07:54:43.0918] OK, I think in general it’s definitely an improvement [07:55:25.0257] I am as usual more interested in the use case of web developers reading the spec than I am for implementors [07:56:25.0269] as far as implementors, I get the impression that the existing spec works well overall for anybody implementing/writing code from it [07:56:33.0776] * as far as implementors, I get the impression that the existing spec works well overall for anybody implementing/writing code from it [07:56:55.0931] but I think it’s a lot harder for developers to learn from [07:57:07.0004] Apparently jsdom ran into issues with "is a Text node" not clearly including CDATASection nodes [07:57:14.0710] aha [07:57:43.0010] OK, yeah, I wondered who would actually be implementing these parts at this point [07:58:39.0298] You don't really want to say Text or CDATASection however as otherwise you also need to say Element or HTMLAnchorElement or ... It gets tricky quickly [07:59:09.0452] yeah, I can see that [07:59:14.0889] Anyway, I hope that depending on CharacterData in a number of cases will make that more clear, as well as more clearly explaining what X node is. [08:00:26.0929] I have recently been looking at some of the lowe-level DOM-related content at MDN, and to speak generously… it has a lot of room for improvement [08:00:55.0943] there is actually nowhere any good “Introduction to the DOM” for web developers [08:01:15.0239] > <@annevk:mozilla.org> You don't really want to say Text or CDATASection however as otherwise you also need to say Element or HTMLAnchorElement or ... It gets tricky quickly The difference is that when working in "DOM" code as opposed to "HTML" code, it's pretty natural to use .nodeType a lot. [08:01:58.0359] Domenic: yeah that's fair, but there's nothing that corresponds to nodeType [08:02:17.0083] Yeah it's just very easy to think that "is a Text node" means .nodeType === TEXT_NODE [08:02:32.0291] I just opened the PR but if you use "implements" that will help. [11:37:35.0061] Hi, I was checking the standard library of the Go programming language and found that the STD3 rules are disabled by default in the current WHATWG URL standard. I was a bit surprised because many Unicode characters in their KC normal forms could introduce forbidden host code points `@`, `#`, `/`, ... that are dangerous or at least misleading. The STD3 check protects us from those dangerous characters. I understand many existing hosts have the underscore `_` in their names that is forbidden by the STD3, but by disabling the entire STD3 check, we become vulnerable to many other attacks based on Unicode normalization. I believe this must have been carefully discussed somewhere within WHATWG. If not, I wonder how I should comment on the current URL standard and propose new changes. I am familiar with GitHub operations but I never interacted with WHATWG before, and would appreciate your guidance in making a proposal. TL;DR: I wish to add a warning about the danger of disabling the STD3 check and, if an application chooses to disable the STD3 check (possibly to allow the underscore), it should verify that forbidden host code points would never arise from normalization and mapping. [13:12:16.0771] favonia: I don't think I understand the issue. Because those are forbidden host code points parsing will fail if they appear. It doesn't matter for the spec whether the parsing fails due to Unicode STD3 checking or because of the explicit step 7 in https://url.spec.whatwg.org/#concept-host-parser [13:12:42.0938] * favonia: I don't think I understand the issue. Because those are forbidden host code points parsing will fail if they appear. It doesn't matter for the spec whether the parsing fails due to Unicode STD3 checking in step 5 or because of the explicit step 7 in https://url.spec.whatwg.org/#concept-host-parser [14:06:19.0998] > <@domenicdenicola:matrix.org> favonia: I don't think I understand the issue. Because those are forbidden host code points parsing will fail if they appear. It doesn't matter for the spec whether the parsing fails due to Unicode STD3 checking in step 5 or because of the explicit step 7 in https://url.spec.whatwg.org/#concept-host-parser As far as I understand, Step 7 does not prevent such attacks. The attack is that the _same_ URL (record) has multiple Unicode normal forms that would be parsed differently. Here is an example: ``` https://google.com\uFF03@evil.com ``` A parser would give the following results: - username: `google.com\uFF03` - host: `evil.com` But with its NFKC: ``` https://google.com#@evil.com ``` a parser would give these results instead: - host: `google.com` - fragment: `@evil.com` So, the string and one of its normal forms are both valid URL records, but with different structures. The discrepancies can be exploited in many IDNA-aware applications to fool users or even bypass security checking. This attack is known as HostSplit. [14:07:25.0388] > <@domenicdenicola:matrix.org> favonia: I don't think I understand the issue. Because those are forbidden host code points parsing will fail if they appear. It doesn't matter for the spec whether the parsing fails due to Unicode STD3 checking in step 5 or because of the explicit step 7 in https://url.spec.whatwg.org/#concept-host-parser * As far as I understand, Step 7 does not prevent such attacks. One attack is that the _same_ URL (record) has multiple Unicode normal forms that would be parsed differently. Here is an example: ``` https://google.com\uFF03@evil.com ``` A parser would give the following results: - username: `google.com\uFF03` - host: `evil.com` But with its NFKC: ``` https://google.com#@evil.com ``` a parser would give these results instead: - host: `google.com` - fragment: `@evil.com` So, the string and one of its normal forms are both valid URL records, but with different structures. The discrepancies can be exploited in many IDNA-aware applications to fool users or even bypass security checking. This attack is known as HostSplit. [14:08:36.0298] * As far as I understand, Step 7 does not prevent such attacks. One attack is that the _same_ URL (record) has multiple Unicode normal forms that would be parsed differently. Here is an example: ``` https://google.com\uFF03@evil.com ``` A parser would give the following results: - username: `google.com\uFF03` - host: `evil.com` But with its NFKC (where `\uFF03` is normalized to `#`): ``` https://google.com#@evil.com ``` a parser would give these results instead: - host: `google.com` - fragment: `@evil.com` So, the string and one of its normal forms are both valid URL records, but with different structures. The discrepancies can be exploited in many IDNA-aware applications to fool users or even bypass security checking. This attack is known as HostSplit. [14:13:46.0165] That is not how those URLs are parsed [14:13:51.0903] See https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly9nb29nbGUuY29tI0BldmlsLmNvbQ==&base=YWJvdXQ6Ymxhbms= [14:14:17.0860] and https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly9nb29nbGUuY29t77yDQGV2aWwuY29t&base=YWJvdXQ6Ymxhbms= [14:16:28.0893] I guess your larger point remains though [14:16:41.0273] Which is yes, different input strings can product different hosts [14:16:52.0819] Opening an issue to discuss that seems fine if you want? [14:17:39.0317] Oops, sorry for my mistakes. It's hard to construct such contrived examples on the fly. 😛 Maybe `https://localhost＃@evil.com` and `https://localhost#@evil.com` would work. [14:47:47.0104] After some thinking I realized this is probably more serious than I thought---the STD3 rules in UTS#46 could prevent some attacks but seem powerless to handle `https://localhost＃@evil.com` v.s. `https://localhost#@evil.com` where the problematic character is never part of the host/domain name. 😱 [14:50:18.0803] I can start a GitHub issue, though I will not be able to meaningfully participate in the discussions probably after two weeks. (I'm teaching in a university and the semester is starting...) Also, I am not an expert on Unicode/URL, merely a concerned user after reading these documents. There might be many strange corner cases that I am not aware of. Therefore, perhaps someone else should take the lead? I can still take the initiative. [14:58:51.0874] PS: consistently applying STD3 rules can probably detect something like `https://cool.asi℀.evil.com` where `℀` could be normalized to `a/c`. [15:01:01.0933] https://cool.asi℀.evil.com is just an invalid URL https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly9jb29sLmFzaeKEgC5ldmlsLmNvbQ==&base=YWJvdXQ6Ymxhbms= 2021-08-04 [17:12:48.0437] https://stackoverflow.com/questions/68641231/does-javascripts-abortable-fetch-close-the-http-connection [17:29:16.0097] > <@domenicdenicola:matrix.org> https://cool.asi℀.evil.com is just an invalid URL https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly9jb29sLmFzaeKEgC5ldmlsLmNvbQ==&base=YWJvdXQ6Ymxhbms= Thank you. Now I see that the Step 7 you mentioned earlier implements a weaker version of the STD3 check that stopped my attack. However, I found another issue showing that whatwg-url probably violated (at least the spirit of) UTS#46. UTS#46 says: > ... > U+2260 ( ≠ ) NOT EQUAL TO > U+226E ( ≮ ) NOT LESS-THAN > U+226F ( ≯ ) NOT GREATER-THAN > > ... If an implementation uses `UseSTD3ASCIIRules=false` but disallows any of these three ASCII characters, then it must also disallow the corresponding precomposed character for its negation. The URL standard forbids `<` and `>`, so I feel `≮` and `≯` should be banned as well. I am happy to open a GitHub issue on this (smaller issue). https://jsdom.github.io/whatwg-url/#url=d3M6Ly88&base=YWJvdXQ6Ymxhbms= https://jsdom.github.io/whatwg-url/#url=d3M6Ly/iia4=&base=YWJvdXQ6Ymxhbms= [17:36:55.0374] Yes, I think this is a case where conforming to the rules doesn't really buy anything. Encoding ≮ to punycode seems fine. [17:37:47.0073] It might be clearer if you think of the URL Standard as a standalone document that gives the full processing model. The fact that it calls into some specific Unicode algorithms with some parameters is interesting, but is just an implementation detail and isn't meant to indicate any greater alignment with the philosophies of those documents. [17:42:25.0204] alright I will skip the reporting. it's perhaps an interesting technical point, though [17:46:22.0835] Sorry I accidentally pressed Enter to create an issue when doing some complex editing on GitHub. Please give me some time to fix that :-/ [18:04:24.0614] Domenic: Is https://jsdom.github.io/whatwg-url some website I can/should cite in my reporting? The tool is very convenient and I wonder if it's "permanent" in any sense. [18:39:11.0805] favonia: yes, feel free to use that site. [19:29:00.0506] > <@domenicdenicola:matrix.org> favonia: yes, feel free to use that site. Done! https://github.com/whatwg/url/issues/626 [07:25:00.0831] > <@domenicdenicola:matrix.org> Yes, I think this is a case where conforming to the rules doesn't really buy anything. Encoding ≮ to punycode seems fine. After checking the Unicode tables more carefully, I must disagree with this judgment and admit UTS#46 has done the right thing. My latest reporting was mainly about NFKC and NFKD, but if we agree that the standard should prevent problematic characters, then ≮, ≯ or even ≠ could generate <, > or = under NFD. [07:25:50.0989] > <@domenicdenicola:matrix.org> Yes, I think this is a case where conforming to the rules doesn't really buy anything. Encoding ≮ to punycode seems fine. * After checking the Unicode tables more carefully, I must disagree with this judgment and admit UTS#46 has done the right thing. My latest reporting was mainly about NFKC and NFKD, but if we agree that the standard should prevent problematic characters on that basis, then ≮, ≯ or even ≠ could also generate <, > or = under NFD and should be banned as well. [07:34:59.0516] That reading is only correct under the assumption that NFD(URL string) is a valid operation, which it's not; as long as you do URL parser(URL string) I don't think you have demonstrated an issue [07:35:42.0023] I could see banning more code points out of caution (though we cannot ban all, e.g., `_` is important), but I wouldn't classify these as a problem with the URL parser [07:39:53.0433] well... I did not imply that the current URL parser itself is wrong. I was only proposing to restrict valid URLs as you suggested. it would be kind of you to cite exact phrases which gave you such an impression so that I can revise my proposal. [07:42:17.0763] Another thing is, according to your statements "You cannot apply Unicode normalization to all inputs" on GitHub, you seemed assume no normalization should be applied to URL strings. that's against the standard and W3C recommendations. NFC _must_ be applied to URL strings as well. There is a related page made by W3C Internationalization Activity: https://www.w3.org/International/questions/qa-html-css-normalization [07:43:59.0055] * Another thing is, according to your statement "You cannot apply Unicode normalization to all inputs" on GitHub, you seemed assume no normalization should be applied to URL strings. That's against the W3C recommendations. NFC _must_ be applied to URL strings as well. There is a related page made by W3C Internationalization Activity: https://www.w3.org/International/questions/qa-html-css-normalization [07:44:08.0933] * Another thing is, according to your statement "You cannot apply Unicode normalization to all inputs" on GitHub, you seemed assume no normalization should be applied to URL strings. That's against the W3C recommendations. NFC should be applied to URL strings as well. There is a related page made by W3C Internationalization Activity: https://www.w3.org/International/questions/qa-html-css-normalization [07:45:22.0929] * Another thing is, according to your statement "You cannot apply Unicode normalization to all inputs" on GitHub, you seemed assume no normalization should be applied to URL strings. That's against (at least the spirit of) the W3C recommendations. NFC should be applied to URL strings as well. There is a related page made by W3C Internationalization Activity: https://www.w3.org/International/questions/qa-html-css-normalization [07:47:14.0263] * Also, you seemed assume no normalization should be applied to URL strings. That's against (at least the spirit of) the W3C recommendations. NFC should be applied to URL strings as well. There is a related page made by W3C Internationalization Activity: https://www.w3.org/International/questions/qa-html-css-normalization [07:51:17.0049] favonia: if you apply normalization at that level though, there is nothing the URL parser can do about it, because you cannot distinguish it from a URL that contains ASCII `#` [07:52:58.0271] I want to repeat that I never implied that the URL parsing is at fault. Could you possibly cite the phrases that gave you such an impression? It seems we miscommunicated and I want to clear up the misunderstanding. [07:53:08.0197] favonia: it might be worth raising with www-international@w3.org as it's a somewhat interesting case; you cannot take a URL from somewhere, validate its scheme and host, then put the input string in HTML that gets normalized; you'd have to put the serialization in which might not be something folks realize [07:54:10.0555] favonia: you start out with talking about URL records, and URL records are the result of parsing [07:54:32.0077] yes, but the parser is not the problem. at least not in my opinion. [07:55:09.0269] "A proper fix would probably be similar to the sanitization of host names." Isn't that a parser change? [07:55:52.0737] > <@annevk:mozilla.org> I could see banning more code points out of caution (though we cannot ban all, e.g., `_` is important), but I wouldn't classify these as a problem with the URL parser no, this is what I meant. thank you for citing exact phrases so that I can prevent other people from misunderstanding the proposal [07:57:45.0024] To be clear, that would be a change to the URL parser aimed at helping scenarios where people parse a URL string to validate it and then somehow output NFX(URL string) elsewhere, which is a somewhat problematic practice for various reasons [07:58:37.0261] E.g., the changes to the URL's path or query are not something we could prevent in that way [07:58:56.0767] (I gotta go for a bit) [08:02:51.0777] > <@annevk:mozilla.org> To be clear, that would be a change to the URL parser aimed at helping scenarios where people parse a URL string to validate it and then somehow output NFX(URL string) elsewhere, which is a somewhat problematic practice for various reasons technically yes, but I think there's a difference between only enlarging the set of forbidden/disrecommended characters and changing the structure of the parser [08:06:54.0561] A difference in what sense? [08:30:49.0237] Could you possibly elaborate more so that I can better answer it? I am happy to simply admit it's a change to the parser. [08:32:53.0933] I don't feel how I personally classify different levels of changes matter here. If WHATWG thinks it's a major change, then it's a major change. If WHATWG thinks it's a minor change, then it's a minor change. I am happy to eliminate different usages in terminology. [08:33:13.0528] * I don't feel how I personally classify different levels of changes matter here. If WHATWG thinks it's a major change, then it's a major change. If WHATWG thinks it's a minor change, then it's a minor change. I am happy to eliminate different usages in terminology in case it helps communication. [08:33:33.0866] * I don't feel how I personally classify different levels of changes matters here. If WHATWG thinks it's a major change, then it's a major change. If WHATWG thinks it's a minor change, then it's a minor change. I am happy to eliminate different usages in terminology in case it helps communication. [08:38:46.0203] I just noticed that `＃` is already rejected when it's part of a host, but it's not rejected when used as a username or password. So STD3 Rules wouldn't matter there either way. [08:39:11.0455] As in, `https://test＃test/` results in failure. [08:39:41.0848] that's correct. proper checking has been done for host names in the current standard. [08:40:23.0582] So yeah, I don't think this is something that can be changed. Those components are expected to allow arbitrary scalar values. [08:41:43.0441] It might be worth calling out somewhere though and I also think raising this with www-international could be worthwhile. [08:42:07.0456] as a disclaimer I only read these documents like three days ago. as a naive suggestion how about demanding percentage-encoding? [08:42:14.0217] * as a disclaimer I only read these documents like three days ago. as a naive suggestion how about demanding percent-encoding? [08:42:24.0130] * as a disclaimer I only started reading these documents like three days ago. as a naive suggestion how about demanding percent-encoding? [08:42:30.0433] * as a disclaimer I only started reading these documents like 2-3 days ago. as a naive suggestion how about demanding percent-encoding? [08:47:50.0835] favonia: it would be a breaking change, URL strings have allowed U+FF03 (＃) for well over a decade [08:48:22.0050] It's easier to ban certain things in hosts because they don't resolve anyway, but we cannot do that for paths and such [08:54:05.0685] got it. well, I feel no one is a warning against any normalization forms other than NFC. following your comment, I guess banning ≮, ≯ in host names would be fine, then? it has almost zero practical impacts while saving us from some terrible situations due to mishandling of host names. [08:54:29.0562] * got it. well, I feel no one is a warning against any normalization forms other than NFC, then? I can actually be satisfied with just that. following your comment, I guess banning ≮, ≯ in host names would be fine, then? it has almost zero practical impacts while saving us from some terrible situations due to mishandling of host names. [08:55:00.0241] * got it. well, I feel no one is a warning against any normalization forms other than NFC, then? I can actually be satisfied with just that. following your comment, I guess banning ≮, ≯ in host names would be fine? it has almost zero practical impacts while saving us from some terrible situations due to mishandling of host names. [08:55:54.0869] * got it. well, I feel no one is aganist a warning about normalization forms other than NFC, then? I can actually be satisfied with just that. following your comment, I guess banning ≮, ≯ in host names would be fine? it has almost zero practical impacts while saving us from some terrible situations due to mishandling of host names. [08:57:27.0462] Well, e.g., ≮ becomes xn--gdh, and it's not clear we can make that inaccessible. And generally we forbid things after ToASCII succeeds, not before. So for that one I'm not sure. It would also depend on how we resolve various other longstanding IDNA issues. [08:58:42.0243] If you apply NFD or some such to a domain name and then pass it to a host parser you are already likely to end up on the wrong website so it's not clear this would prevent all of these attacks so it might be better if sites address the root cause. [09:00:13.0837] Heck, if you apply NFD to HTML in general you would open yourself up to all kinds of attacks. [09:00:38.0270] There's a reason you want NFC unless you do some kind of specialized text processing. [09:01:33.0677] You might enjoy http://www.diveintomark.link/2004/unicode-normalization-form-c [09:02:53.0776] Hah, it's funny and to the point. :laugh [09:03:03.0746] * Hah, it's funny and to the point. 😆 [09:03:38.0073] to be fair KD would be even worse [09:11:36.0849] > <@annevk:mozilla.org> If you apply NFD or some such to a domain name and then pass it to a host parser you are already likely to end up on the wrong website so it's not clear this would prevent all of these attacks so it might be better if sites address the root cause. No you will be fine even after NFD unless the application has serious bugs. See . You need to compute NFC which would undo the "damage". At least Firefox got this correct. [09:20:38.0808] `whatwg-url` gives the correct result as well (which is not really surprising because the `tr46` package used by `whatwg-url` correctly implements UTS46) https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly88zLg=&base=YWJvdXQ6Ymxhbms= [09:24:04.0499] anyways, personally I am much less motivated to promote the banning of ≮ and ≯ in host names because it seems significantly harder to construct concrete attacks. [09:24:18.0614] * anyways, personally I am much less motivated to promote the banning of ≮ and ≯ in host names because it seems significantly harder to construct concrete attacks. it's just a possibility. [09:25:24.0236] Ah right, I guess you would need to apply one of the NFKx variants as those cannot be reversed if I remember correctly [09:25:32.0210] It's been a long time since I looked at this in detail [09:28:12.0865] as far as I have read (did I say I started the reading only days ago?), that seems to be the case. to be more precise, NFX is in general irreversible, but we only care about whether NFC(NFX(input)) = NFC(input) for some X here. [16:14:40.0291] annevk Domenic Thank you for your guidance on GitHub. I however think the issue is going nowhere---I did not sense any positive support even for the suggestion to put in some warnings in the standard, and I am not willing to put in more efforts in convincing members of WHATWG. Is it okay for me to simply close the issue? [16:15:46.0521] * annevk Domenic Thank you for your guidance on GitHub. I however think the issue is going nowhere---I did not sense any positive support even for the suggestion to put in some warnings in the standard, and I am not willing to put in more efforts in convincing members of the WHATWG community. Is it okay for me to simply close the issue? 2021-08-05 [18:10:46.0852] annevk: on https://github.com/whatwg/html/issues/5407, it might be worth posting an update pointing to https://bugs.chromium.org/p/chromium/issues/detail?id=1065085#c72, so that future readers know the status? (the issue is locked, understandably, so I can't do it myself) [21:45:46.0411] bakkot: I don't think so; there's still cross-browser agreement to remove the feature, so the spec reflects that. [21:46:25.0301] Individual shipping decisions are up to browsers to communicate as they wish. [22:28:44.0929] as someone coming across that thread, I would find it useful to know that Chrome's intent is to remove the feature _not before January 2022_, rather than to remove it as soon as resources permit [22:29:10.0027] not suggesting a change to the spec, just an informative post in the thread [23:13:37.0729] bakkot: I unlocked it, feel free to add a comment [00:29:20.0698] By the way, while I support that change, I can also say it did break quite a few embedded interactive examples at MDN [00:31:12.0262] But those are entirely or almost entirely cases of examples that were using `alert()`, which is just bad anyway. So we're gonna fix those regardless. [00:31:16.0938] https://github.com/mdn/content/issues/7566 [01:45:50.0737] PSA for people using the web-based Element client: If you don’t want to have to use the mouse to switch among rooms, you can use Ctrl-K or ⌘-K to focus the search box, and then use the arrow keys to navigate your rooms list [01:46:35.0763] (tab doesn’t work as expected, but it’s a tree view) [01:47:09.0654] That would have been vry helpful to know yesterday when the android emulator decided to prevent mouse interactions with part of my screen, even when it wasn't focused :) [01:48:59.0011] * PSA for people using the web-based Element client: To switch among rooms, if you want to use keyboard navigation rather than the mouse, first do Ctrl-K or ⌘-K to focus the search box, and then use the arrow keys to navigate your rooms list [01:49:08.0320] * PSA for people using the web-based Element client: To switch among rooms, if you want to use keyboard navigation rather than the mouse, first do Ctrl-K or ⌘-K to focus the search box, and then use the arrow keys to navigate through your rooms list [01:49:22.0626] * PSA for people using the web-based Element client: To switch among rooms, if you want to use your keyboard rather than the mouse, first do Ctrl-K or ⌘-K to focus the search box, and then use the arrow keys to navigate through your rooms list [01:49:48.0753] * But those are entirely or almost entirely cases of examples that were using `alert()`, which is just bad anyway. So we're gonna fix those regardless. [01:50:01.0692] haha [01:50:19.0679] You can also do Option + Down/Up [01:50:29.0893] (on macOS anyway) [01:51:25.0549] annevk: oh wow, cool — didn’t know. I like that even better [01:53:16.0529] Appears to be alt+arrows here [01:53:23.0572] Not on macOS [01:55:51.0048] What even is alt? [01:59:08.0600] alt is an actual key on Linux keyboards, right? [02:00:09.0117] Honestly can't tell if people are trolling or if you've all been using macOS too long :p [02:02:48.0794] Don't worry, I remember Ctrl+Alt+Del, also Alt+F4; not sure about Linux shortcuts anymore though, even though I used that more recently than Windows [02:02:55.0602] anyway, as long as were at this this: Option (or Alt) + *Shift* + Down/up cycles you through just the list of your rooms with unread messages — like Option (or Alt) + a, in irrssi [03:04:48.0982] https://github.com/WebKit/explainers/issues/55 [03:05:11.0502] WebKit implemented a `model` element? [03:05:38.0296] Is there an associated proposal in the HTML spec issue tracker? [03:06:17.0010] https://trac.webkit.org/changeset/279451/webkit/ [04:28:26.0817] Somehow Safari TP keeps disappearing from my computer, but last I checked HTMLModelElement was not exposed [04:32:17.0287] Yeah, `document.querySelector("model")` with `` somewhere in the document yields `HTMLUnknownElement` [04:36:54.0190] 👋 Surma [05:10:09.0149] Ah ok [05:34:55.0950] Domenic: so thinking more about obj is/implements Y; I imagine we have that elsewhere too with Blob/File, but I guess there's not a lot of it as outside DOM there's not a lot of hierarchy in classes (I think) [11:00:11.0072] https://github.com/mdn/content/issues/7457 is it right for `window.orientation` be flagged in MDN as deprecated? If so, given that the compat spec doesn’t say it’s deprecated or discouraged, is there some other authoritative so which does? [11:00:36.0093] * https://github.com/mdn/content/issues/7624 is it right for `window.orientation` be flagged in MDN as deprecated? If so, given that the compat spec doesn’t say it’s deprecated or discouraged, is there some other authoritative so which does? [11:00:54.0620] * https://github.com/mdn/content/issues/7624 is it appropriate for `window.orientation` to be flagged in MDN as deprecated? If so, given that the compat spec doesn’t say it’s deprecated or discouraged, is there some other authoritative so which does? [11:01:10.0825] * https://github.com/mdn/content/issues/7624 is it appropriate for `window.orientation` to be flagged in MDN as deprecated? If so, given that the compat spec doesn’t say it’s deprecated or discouraged, is there some other authoritative source which does? [11:03:40.0138] or is it the case that pretty much everything in the Compat spec should be considered discouraged/deprecated? [12:35:27.0912] Weird case. Is there some better replacement? [14:24:20.0937] > <@sideshowbarker:mozilla.org> or is it the case that pretty much everything in the Compat spec should be considered discouraged/deprecated? this would be my expectation, FWIW [14:24:39.0268] maybe screen orientation API? [14:27:01.0174] sideshowbarker: i guess we could include some text for given entries in compat like, prefer this standard thing instead (not sure how useful that is, but it wouldn't be hard) 2021-08-06 [18:20:37.0667] > <@miketayl_r:mozilla.org> sideshowbarker: i guess we could include some text for given entries in compat like, prefer this standard thing instead (not sure how useful that is, but it wouldn't be hard) Yeah, I vote for that [20:38:57.0977] Compat spec has been conceived as a transition document. Nothing in there should be considered the source of truth. It just **attempts** to document things that need to be taken elsewhere in a proper spec **if the spec wants to take it on**. [20:39:52.0760] And yes having section pointing to the right place when it has been described in a proper spec would be great. [20:41:07.0702] sideshowbarker: > or is it the case that pretty much everything in the Compat spec should be considered discouraged/deprecated? [20:41:18.0111] do you mean on the authoring side of things? [20:41:27.0256] or implementation side of things? [20:42:42.0911] Definitely everything which is mentioned in compat spec should not be perceived as ok to write code. [20:50:26.0039] howdy karlcow yeah I meant strictly the author side of things [07:35:29.0066] My HTML parser is 1400 lines and *still* fails to implement a *lot* of the parsing spec. That is one really long spec xD. My parser is worth about 14% of my project's code. Wow, that spec is long [07:44:58.0461] Tokei tells me that html5lib-python is ~13,000 lines of Python code (exclusing comments, but including the test harness and so on) [07:46:51.0089] Weirdly html5ever has the same number of lines of Rust to within 2% [07:47:02.0541] (as html5ever has of Python) [07:47:08.0954] * (as html5lib has of Python) [07:49:16.0683] The validator.nu HTML parser seems to be about 28,000 lines of Java (also including infrastructure, etc.) [07:49:19.0596] Wow, that's giant Looks like I got my work cut out. (I still need to learn Rust btw) [07:52:32.0173] My unit tests also completely fail to exist So I will have to write those someday. [07:54:39.0633] You know about https://github.com/html5lib/html5lib-tests/ ? [07:59:23.0391] > <@jgraham_:matrix.org> You know about https://github.com/html5lib/html5lib-tests/ ? No But I do know about https://wpt.live/ I'll have to star that other one. [12:49:05.0999] Domenic: fwiw on https://github.com/openui/open-ui/issues/380#issuecomment-894404741 I think this is referring to HTMLOptionsList [13:42:51.0619] > <@bkardell:igalia.com> Domenic: fwiw on https://github.com/openui/open-ui/issues/380#issuecomment-894404741 I think this is referring to HTMLOptionsList Sorry, I still don't quite understand... how is HTMLOptionsCollection an example, how is it related to me, and what do the principles Nicole referenced have to do with it? [13:45:50.0692] ah... it's possible I am wrong anyway- it might refer to this comment you made on the issue https://github.com/openui/open-ui/issues/380#issuecomment-891268912 - but I thought in the call it was brought up that you mentioned that, for example, the new select-like element should probably not reuse HTMLOptionsElement... In fact, it is probably the comment you made on the issue tho [13:46:24.0694] * ah... it's possible I am wrong anyway- it might refer to this comment you made on the issue https://github.com/openui/open-ui/issues/380#issuecomment-891268912 - but I thought in the call it was brought up that you mentioned that, for example, the new select-like element should probably not reuse HTMLOptionsList... In fact, it is probably the comment you made on the issue tho [13:46:42.0331] s/list/collection [13:48:51.0112] the group had some decision to see if we could articulate principles about why we would choose to match or not and write them down, I think it was an attempt to summarize them [13:49:31.0688] * Domenic: ah... it's possible I am wrong anyway- it might refer to this comment you made on the issue https://github.com/openui/open-ui/issues/380#issuecomment-891268912 - but I thought in the call it was brought up that you mentioned that, for example, the new select-like element should probably not reuse HTMLOptionsList... In fact, it is probably the comment you made on the issue tho [13:50:18.0383] * Domenic: the group had some decision to see if we could articulate principles about why we would choose to match or not and write them down, I think it was an attempt to summarize them.. it's possible I am wrong anyway- it might refer to this comment you made on the issue https://github.com/openui/open-ui/issues/380#issuecomment-891268912 - but I thought in the call it was brought up that you mentioned that, for example, the new select-like element should probably not reuse HTMLOptionsList... In fact, it is probably the comment you made on the issue tho [13:50:36.0240] * Domenic: the group had some decision to see if we could articulate principles about why we would choose to match or not and write them down, I think it was an attempt to summarize them.. it's possible I am wrong anyway- it might refer to this comment you made on the issue https://github.com/openui/open-ui/issues/380#issuecomment-891268912 - but I thought in the call it was brought up that you mentioned that, for example, the new select-like element should probably not reuse HTMLOptionsCollection... In fact, it is probably the comment you made on the issue tho [13:53:08.0611] * Domenic: the group had some decision to see if we could articulate principles about why we would choose to match or not and write them down, I think it was an attempt to summarize them.. it's possible I am wrong anyway- I was thinking that in the call it was brought up that you mentioned that, for example, the new select-like element should probably not reuse HTMLOptionsCollection... In fact, it is probably the comment you made on the issue https://github.com/openui/open-ui/issues/380#issuecomment-891268912 [13:54:23.0633] /me apologizes for multiple editing attempts to get that right if anyone was watching :) [14:39:19.0687] Yeah, to me it felt like reading the minutes they didn't really discuss the API at all... 2021-08-07 [20:07:51.0409] incidentally, if the html5lib Python parser has 13,000, the fact the vnu Java parser only having 28,000 seems to suggests that Java code is written pretty economically [20:10:30.0612] it seems like Java code is almost always going to take significantly more than twice as many lines than most other common languages [20:26:24.0763] https://www.python.org/doc/essays/comparisons/ > Python programs are typically 3-5 times shorter than equivalent Java programs. [20:26:55.0634] * incidentally, if the html5lib Python parser has 13,000 lines of code, the fact the vnu Java parser only having 28,000 seems to suggests that Java code is written pretty economically [20:27:15.0080] * incidentally, if the html5lib Python parser has 13,000 lines of code, the fact the vnu Java parser only has 28,000 line seems to suggests the vnu Java code is written pretty economically [23:22:59.0717] https://portswigger.net/research/http2 [00:12:57.0369] not quite sure what to do about https://github.com/mdn/content/issues/7667 — help welcome (even just issue comments) [10:28:55.0924] That issue seems based on some pretty bad confusions on how software works... like, how would the data belong to the "site"? Some sort of behind-the-scenes magic server-side syncing? [10:33:22.0982] I dunno though, maybe I'm just too deep into the ecosystem; maybe people coming to web dev from other ecosystems have different expectations. [10:33:36.0649] yeah, I don’t know where to even begin on that one [10:34:53.0643] Like I feel like if you really wanted to address this in good faith you'd need a whole article or so on how browsers work (being self-contained, relying on the site for any long-term storage, etc.) which would make this clear? [10:35:32.0567] I am not aware of other systems where if you have two arbitrary clients that are using some client-side persistent local storage, the state of the local storage from one arbitrary client gets automatically reflected to the local state for every other arbitrary client you might use [10:36:09.0509] > <@domenicdenicola:matrix.org> Like I feel like if you really wanted to address this in good faith you'd need a whole article or so on how browsers work (being self-contained, relying on the site for any long-term storage, etc.) which would make this clear? yeah. I don’t know how to respond to it productively without sounding dismissive [10:36:19.0536] Yeah like this person must not be thinking of browsers in that sense of the word "client", or maybe is new enough to development that they don't have the client-server dichotomy in their mental model [10:37:12.0274] I dunno it just seems like a really hard part of writing docs; what is the baseline level of understanding you require before the docs make sense. Given MDN's seeming mission to be everything (e.g. it has tutorials not just reference docs), that seems hard. [10:39:12.0213] yeah this issue is not a completely isolated case — it’s just a matter of degree [10:39:37.0519] same with the HTML issue tracker, actually [10:40:50.0967] we have people show up and raise issues that the immediate reaction to is going to be, You really should probably read up a lot more about how all this works [10:41:59.0600] but for MDN issues, I try to first take a breath and then really consider in good faith if there’s any possible useful refinement to the docs that could be salvaged out of the issue [10:42:05.0285] sometimes there is [10:42:35.0297] but anyway, this particular issue does make me realize that there’s a common misunderstanding that a lot of people have [10:43:25.0341] …which is, they don’t realize that the code for a web application executes on their machines locally, inside the browser [10:44:15.0516] I guess they imagine it somehow running out in the “cloud” somewhere, at some abstract “origin” [10:55:04.0462] hmm, I guess that’s a bit of what it is in this case — the OP understands what a unique origin is, and they imagine that if code running at a particular origin creates some persistent thing, then that persistent thing should persist at that origin regardless of which browser you use to access it [10:58:27.0334] and I suppose then that a fundamental they’re overlooking is that the persistent things are necessarily persisted per-user — otherwise, every user who ran some code at that origin would clobber the persisted stuff [10:59:09.0922] and two different browsers is two different users — regardless of whether those browsers happen to be running on the same person’s machine [10:59:24.0545] maybe I can try to write up a comment along those lines [11:37:36.0058] commented: https://github.com/mdn/content/issues/7667#issuecomment-894691081 2021-08-08 2021-08-09 [23:51:38.0682] sideshowbarker: is there an equivalent to commit-snapshots/ for snapshots published on TR/? I.e., some kind of index [01:21:23.0842] > <@annevk:mozilla.org> sideshowbarker: is there an equivalent to commit-snapshots/ for snapshots published on TR/? I.e., some kind of index I know only https://www.w3.org/2002/01/tr-automation/tr.rdf [01:21:36.0470] …and the related docs at https://www.w3.org/2002/01/tr-automation/tr.rdf [01:22:21.0400] there’s also now https://api.w3.org/doc [01:23:20.0235] sideshowbarker: I see, that RDF document only lists latest versions and doesn't list the full history as far as I can tell [01:23:41.0362] OK [01:24:24.0373] might be able to get more from one of the API endpoints at https://api.w3.org/doc#operations-tag-Specifications [01:24:56.0607] …or some series of calls to some of those endpoints [01:26:32.0489] I see, that seems to require a key [01:26:40.0126] Thanks though [01:26:57.0363] you can generate a key yourself [01:27:06.0947] docs on that are at https://w3c.github.io/w3c-api/ [01:28:43.0618] Ah cool, I'll hand these to my colleague who was wondering about this [01:29:21.0160] super [01:29:55.0329] certainly plh or Dom or especially Denis could be more helpful than me [01:30:14.0775] Denis develops and maintains the API [01:30:53.0402] so also, if there’s something missing from the API that your colleague needs, there’s a good chance that Denis could add it [01:31:33.0692] I kinda doubt they were looking for an API, but it might suffice 😊 [01:31:43.0576] hai 2021-08-10 [05:58:16.0925] annevk: ping on re-review for https://github.com/whatwg/html/pull/6869 ? [07:44:25.0364] Domenic: so to make sure I understand correctly, the remaining Window-object reuse question is about a subsequent navigation of this about:blank document, right? [07:50:04.0345] Anyway, approved modulo that assumption and an optional nit [08:11:07.0832] annevk: yes, because you can't observe the Window before this initial pseudo-load, so you can't tell whether it was reused or not. [08:20:20.0329] TabAtkins: https://github.com/w3c/webdriver-bidi/pull/131 seems to have a bikeshed error that looks like a bug in the CSS SPec Preprocessor deployment (maybe I should file an issue as it suggests, but also I'm not sure how much attention is paid to issues on repos in tobie's personal GH). [08:21:05.0323] Cool. Initially I was wondering if the Window would end up being replaced somewhere during the lifetime of the about:blank document (where Firefox would navigate to about:blank), but I realized that probably wasn't it. [08:34:03.0872] jgraham: looking [08:34:52.0049] Yup, bug on my end, apologies for that. I don't exercise that code path in my local test files... I should figure out how to. [08:35:09.0584] Thanks for investigating! [08:39:34.0637] Okay, GH is having issues atm, but as soon as it's up I'll push the fix. [11:04:29.0342] jgraham: GH is up and fix is pushed, lmk [12:20:18.0483] my PRs seem to be failing to build the preview with a bikeshed error... https://github.com/tobie/pr-preview/issues/93 [12:20:22.0031] FYI, in case its related [12:24:30.0341] It was the same; I forgot that the processor relies on the pypi version. Update published. [12:37:31.0840] thanks [13:40:37.0984] TabAtkins: hmm, still seem to be getting 500's from pr-preview [14:14:57.0682] wanderview: learn something new about Python every day. confirmed it's fixed now, just pushed up, lmk 2021-08-11 [06:05:49.0794] hsivonen: looks like https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading no longer exists. Has it moved? [06:15:22.0432] I think everything Gecko related was removed from MDN [06:15:41.0367] jgraham: ok ;_; [06:17:07.0680] https://web.archive.org/web/20201021003137/https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading still exists [06:17:39.0385] thanks [06:20:47.0949] https://udn.realityripple.com/docs/Mozilla/Gecko/HTML_parser_threading also seems to be a thing, but I have no idea what the story behind that site is [07:01:21.0843] > <@zcorpan_:matrix.org> hsivonen: looks like https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading no longer exists. Has it moved? Thanks. Stuff like this was supposed to move in-tree, but I'll need to check if I need to actually take action to make it happen for this one. [07:07:56.0673] hsivonen: AFAICT gecko docs in general weren't moved in-tree. [07:56:17.0623] Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1725183 2021-08-12 [18:27:49.0841] random q: in step 3.1 of Formatter in the console spec, it calls `String(arg)`: https://console.spec.whatwg.org/#formatter [18:28:15.0853] this implies to me that `console.log(">%s<", ({ toString: () => { return 'custom' } }))` should print `>custom<`, which it does in FF, but not in Chrome (which instead prints `>Object<`) [18:28:28.0094] am I misreading, or is Chrome not following the spec? [03:56:00.0779] Could someone explain why running the below snippet on https://google.com results in different output than https://source.chromium.org/? As far as I can tell neither are in quirks mode. ```js const target = new EventTarget() target.addEventListener("f", () => { console.log("f"); queueMicrotask(() => console.log("f mt")); }); target.addEventListener("x", () => { console.log("x"); queueMicrotask(() => console.log("x mt")); }); target.dispatchEvent(new Event("f")); target.dispatchEvent(new Event("x")); ``` [03:56:35.0864] google.com logs ``` f VM143:7 x VM143:4 f mt VM143:8 x mt [03:56:57.0489] * google.com logs ``` f x f mt x mt ``` while source.chromium.org logs ``` f f mt x x mt ``` [04:00:42.0316] Oh, source.chromium.org has a custom `queueMicrotask`. Should have looked for that right away. Please ignore :-) [05:06:10.0577] this is why I test on example.com (.net, .org) [05:06:16.0643] * this is why I test on example.com (.net, .org) :P [08:12:13.0858] anyone recalls why getElementsByTagName and such didn't end up to ShadowRoot? [08:12:44.0135] ah, I guess because of HTMLCollection [11:15:55.0957] https://stackoverflow.com/questions/68742660/when-response-text-promise-will-reject [12:29:11.0428] 👋 [12:31:28.0845] hey [12:31:35.0113] just copying a question from irc: [12:31:37.0655] question about the navigate-to csp directive (https://w3c.github.io/webappsec-csp/#directive-navigate-to): if i understand it correctly, this doesn't restrict links the user can click on to navigate; it only restricts navigations initiated by JS, redirects, and forms. is this accurate, or is its scope broader? [12:40:55.0141] also: w3.org directed me to irc.w3.org and #whatwg on fleenode. irc.w3.org is mostly empty. freenode -> libera happened, and i was directed from irc to matrix here. so...are questions about w3c specs welcome here, or is there a better place? [12:47:15.0082] Seirdy: W3C is theoretically mostly still on IRC, although it's fragmented a bit. You can bridge from matrix to the IRC server if you want to have a single interface. I think the answer to "are questions about W3C specs welcome here" is "it depends on the spec". [12:47:52.0816] I think there are some people who can answer webappsec questions, and I don't know of a better place. [12:51:19.0969] > <@jgraham_:matrix.org> Seirdy: W3C is theoretically mostly still on IRC, although it's fragmented a bit. You can bridge from matrix to the IRC server if you want to have a single interface. > > I think the answer to "are questions about W3C specs welcome here" is "it depends on the spec". the biggest room on irc.w3.org has three members. the second biggest has two members. [12:51:56.0712] i generally prefer using weechat anyway [12:53:06.0914] Seirdy: I"m in #_w3c_#webdriver:matrix.org and there are definitely more than 3 members [12:53:38.0069] #css currently has 116 people [12:53:44.0305] wait what [12:54:22.0865] oh wait my usercount script us messed up [12:54:29.0336] nevermind [12:54:56.0546] kids, don't code while sleep deprived or you'll end up like me [12:57:07.0722] ok thanks guys, cya. 2021-08-13 [19:05:23.0678] what if the websocket constructor accepted protocol-relative urls [19:05:42.0056] is there a security reason or smth that it doesn't [23:39:41.0733] devsnek: I guess your actual question is why it doesn't accept HTTP(S) schemes? It probably could... [01:05:00.0207] is there any json data (similar to https://html.spec.whatwg.org/entities.json) that lists the elements and what type they are apart of re: https://html.spec.whatwg.org/multipage/syntax.html#elements-2 [01:05:13.0346] * is there any json data (similar to https://html.spec.whatwg.org/entities.json) that lists the elements and what type they are apart of re: /syntax.html#elements-2 [01:05:25.0176] * is there any json data (similar to https://html.spec.whatwg.org/entities.json) that lists the elements and what type they are apart of re: [03:52:38.0212] > <@annevk:mozilla.org> devsnek: I guess your actual question is why it doesn't accept HTTP(S) schemes? It probably could... I suppose that's also a good question. Perhaps I'll open an issue. [04:04:29.0128] do we have TPAC agenda for whatwg? [05:31:38.0425] zcorpan: I don't think there is anything planned [08:29:26.0284] Given how lackluster last TPAC felt I am not inclined to do much. [08:29:34.0933] (it is online again this year) [10:36:17.0964] anyone familiar with WebCrypto that might be able to answer https://github.com/w3c/webcrypto/issues/269? [10:53:36.0679] I pinged internally to see if whoever maintains WebCrypto in Chrome knows... [11:00:26.0906] Awesome, thanks Domenic [11:41:21.0359] Yeah virtual TPAC is *really* disappointing. The entire value-add of TPAC is hallway-conf. [12:19:40.0021] annevk: smaug: thoughts or straw-poll votes welcome for renaming app history's `respondWith()`: https://github.com/WICG/app-history/issues/94#issuecomment-888248569 [13:14:14.0519] well, I'd like to get rid of that, as you know 😉 But reading [13:44:32.0889] are whatwg specs taking ages to load for anyone else, or am i just lucky? [13:44:59.0201] just took like 2 minutes to load https://dom.spec.whatwg.org/ [13:46:52.0864] DigitalOcean seems to be having trouble [13:46:56.0742] Although https://status.digitalocean.com/ is green still [13:47:15.0999] eventually HTML loaded for me [13:47:20.0527] but yeah, feels like network drama [13:47:24.0221] If you don't refresh the service worker will work for non-HTML specs [13:57:01.0559] Everything's back up [13:59:31.0860] awesome, thanks 2021-08-14 [21:50:57.0629] Anybody familiar with autoplay behavior in Firefox: Help wanted with https://github.com/mdn/content/issues/7908 [07:39:14.0053] https://twitter.com/KawarabeEcma/status/1426420194109394947 is a good reminder that although linking to Infra definitions may seem a bit silly sometimes, i.e. "everybody knows what continue means in a loop", it can be helpful for first-time readers and people for whom English is not their first language. 2021-08-15 [10:24:48.0088] Domenic: that's a great thread <3; I'm on board [10:28:10.0468] hello! I'm thinking of making a proposal for a new web platform API that lets web developers imperatively set the `prefers-color-scheme` media query, or an allowlist of other keys. something like ```js await navigator.setMedia('prefers-color-scheme', 'dark'); ``` the case I have in mind is "toggle color scheme" buttons, which right now typically set a class on the body. This works, but leads to duplication of code, as users would have to ```css body { --my-theme-color: darkgrey; } @media(prefers-color-scheme: dark) { body { --my-theme-color: lightgrey; } } body.dark { --my-theme-color: lightgrey; [10:28:34.0536] * hello! I'm thinking of making a proposal for a new web platform API that lets web developers imperatively set the `prefers-color-scheme` media query, or an allowlist of other keys. something like ```js await navigator.setMedia('prefers-color-scheme', 'dark'); ``` the case I have in mind is "toggle color scheme" buttons, which right now typically set a class on the body. This works, but leads to duplication of code, as users would have to ```css body { --my-theme-color: darkgrey; } @media(prefers-color-scheme: dark) { body { --my-theme-color: lightgrey; } } body.dark { --my-theme-color: lightgrey; } ``` Is this something that WHATWG might consider? is it worth my time trying a formal proposal? [10:47:39.0992] Benny Powers: That's a CSSWG issue, actually. And as it so happens, I started a thread on this exact thing, for that exact use-case, a few days ago: https://github.com/w3c/csswg-drafts/issues/6517 [10:48:02.0528] thank you, @tab [10:48:10.0817] * thank you, TabAtkins 2021-08-16 [22:11:22.0491] Regarding the `meta` prescan discussion from mid-July, I filed https://github.com/whatwg/html/issues/6962 [00:51:19.0046] annevk: is the answer at https://stackoverflow.com/questions/68793536/why-cant-i-use-a-wildcard-on-access-control-allow-headers-when-allow-credenti/68799055#68799055 a correct reading of that note in the spec? [00:53:21.0135] that is, responses that include credentials can’t have `Access-Control-Allow-Headers: *` but must instead explicitly list all the allowed header names? [00:54:41.0472] (or more precisely, in responses that include credentials, the `*` in the `Access-Control-Allow-Headers` is interpreted by browsers as the literal header name `*` — not as the wildcard meaning “any header name”) [00:55:02.0651] * (or more precisely, in responses that include credentials, the `*` in the `Access-Control-Allow-Headers` value is interpreted by browsers as the literal header name `*` — not as the wildcard meaning “any header name”) [04:38:22.0540] sideshowbarker: yeah [06:02:52.0153] html5lib-tests expect `` to have `null` name. See https://github.com/validator/htmlparser/issues/35 . Yet, per https://dom.spec.whatwg.org/#documenttype , the name isn't nullable in the DOM, and is `""` rather than `null` in Chrome. Is the difference between `null` and `""` visible via the Web? Should the spec and test suite change instead of implementations? [06:03:53.0271] (Context, trying to merge https://github.com/validator/htmlparser/commit/3be25a0e44adda338c99bcc85ae9b6167522bc75 to Gecko and wrote a WPT expecting `null`.) [06:34:11.0139] > <@hsivonen:mozilla.org> html5lib-tests expect `` to have `null` name. See https://github.com/validator/htmlparser/issues/35 . Yet, per https://dom.spec.whatwg.org/#documenttype , the name isn't nullable in the DOM, and is `""` rather than `null` in Chrome. Is the difference between `null` and `""` visible via the Web? Should the spec and test suite change instead of implementations? > DOCTYPE tokens have a name, a public identifier, a system identifier, and a force-quirks flag. When a DOCTYPE token is created, its name, public identifier, and system identifier must be marked as missing (which is a distinct state from the empty string), and the force-quirks flag must be set to off (its other state is on). That said, I don't think _anything_ (even parse errors) differ between null and "" for the name [06:36:27.0333] (for public identifiers and system identifiers it can be observed _if_ you can observe parse errors, and in certain combinations by quirks mode activation) [06:37:34.0028] there's some kinda broad questions about how useful/accurate the tokeniser tests are, given for many implementations it's not possible to run the tokeniser in isolation [07:09:30.0091] "Each Entity must: identify individuals who are authorized to participate in each Workstream, " - how do I do this? [07:32:02.0415] Also can I just invite colleagues to the whatwg github org? [07:39:08.0318] > <@zcorpan_:matrix.org> "Each Entity must: identify individuals who are authorized to participate in each Workstream, " - how do I do this? Using the GitHub org [07:39:14.0549] > <@zcorpan_:matrix.org> "Each Entity must: identify individuals who are authorized to participate in each Workstream, " - how do I do this? * Using the per-entity GitHub org [07:39:47.0526] > <@zcorpan_:matrix.org> Also can I just invite colleagues to the whatwg github org? Yeah historically we've used org membership as just "do you want a cool WHATWG badge on your profile" so anyone can join. [07:41:29.0129] Domenic: so members of bocoup github org are allowed to participate in whatwg workstreams? [07:42:05.0731] Yes, since you set that as the org in https://github.com/whatwg/participant-data/blob/8a6e5999042588478cadb24c8e0480accc7c9b9a/entities.json#L189 [07:43:34.0232] aha, thanks. I'll check if we should use a dedicated org for standards stuff [08:31:57.0662] hsivonen: I wonder if it's feasible to kill