WHATWG on 2023-06-14

02:46	<Domenic>	I wonder what the story behind this RFC standardizing C header and implementation files is. https://www.rfc-editor.org/rfc/rfc6234#section-8
02:54	<Jeffrey Yasskin>	I wonder what the story behind this RFC standardizing C header and implementation files is. https://www.rfc-editor.org/rfc/rfc6234#section-8 "Much of the text herein was adapted by the authors from FIPS 180-2."
02:55	<Jeffrey Yasskin>	I don't know for sure that FIPS 180-2 defines SHA-2 using C code, but I wouldn't put it past them.
13:20	<Adam Rice>	I wonder what the story behind this RFC standardizing C header and implementation files is. https://www.rfc-editor.org/rfc/rfc6234#section-8 This isn't even the only RFC containing source code. See https://martinthomson.github.io/rfc-code/
14:33	<bkardell>	wow idk what happened to that :dir pull request, so sorry about that... I think it is fixed now
14:33	<zcorpan>	annevk https://github.com/whatwg/html/issues/5880#issuecomment-1589229150
14:34	<smaug>	How does fetch for import() work in workers? https://tc39.es/ecma262/#sec-import-call-runtime-semantics-evaluation calls HostLoadImportedModule ,but https://html.spec.whatwg.org/#hostloadimportedmodule throws in 2.3.
14:35	<smaug>	I'm missing something obvious
14:40	<annevk>	bkardell: dunno if you did this, but I personally always find it useful to gloss over the changes tab of the pull request for a quick self-review to catch any obvious mistakes
14:41	<annevk>	zcorpan: prolly? If we're the only browser that does that still we could remove it I think
14:41	<evilpie>	smaug: I think this handles worklets and serviceworkers
14:41	<annevk>	nicolo-ribaudo: ^^
14:42	<smaug>	evilpie: ha, yes, WorkletGlobalScope. Idiot me 🙂
15:44	<bkardell>	bkardell: dunno if you did this, but I personally always find it useful to gloss over the changes tab of the pull request for a quick self-review to catch any obvious mistakes yeah I generally do that myself which is why this was so suprising - but I know that I was rushing to get some things done as I was in and out the door a lot last week with my mom in the hospital - so probably i tried to squeeze something in there in a rush and was careless/sent the push and didn't stick around to check
15:44	<bkardell>	btw - does anyone else find that these PRs can get really hard to follow as people are commenting over time and things are getting resolved
15:59	<Jeffrey Yasskin>	btw - does anyone else find that these PRs can get really hard to follow as people are commenting over time and things are getting resolved This is why I suggest that people do big changes as monkeypatch specs in their own repositories so that we can file and resolve issues instead of just making PR comments.
16:08	<annevk>	Yeah it varies, definitely depends on the size of the PR, turnaround time from both sides, and using fixup commits and resolving threads accurately. And even when all of that is followed you might run into GitHub limitations at some point, though I guess that's really about size.
16:19	<annevk>	Personal repositories are a bit of a problem IPR-wise. I hope the WHATWG SG can get to a better solution there, but it will likely take a while.
16:21	<Jeffrey Yasskin>	Personal repositories are a bit of a problem IPR-wise. I hope the WHATWG SG can get to a better solution there, but it will likely take a while. It's really easy to get a repository added into the WICG once it has enough support to be considered as a WHATWG PR. It'll be better to have a dedicated WHATWG org for that, as I think the SG is working on, but the WICG should work in the interim.
16:30	<annevk>	Jeffrey Yasskin: right, was just reacting to "personal repo".
16:31	<Jeffrey Yasskin>	Ooooh, by "their own repositories" I meant the proposal's own repository, not the author's own repository.
16:38	<bkardell>	Personal repositories are a bit of a problem IPR-wise. I hope the WHATWG SG can get to a better solution there, but it will likely take a while. aren't the pulls generally from personal repository forks?
16:45	<Jeffrey Yasskin>	The PR is a "Contribution" under https://whatwg.org/ipr-policy#21-contribution, and the author of the PR is clearly making the right IPR commitments ... but I'm not sure that everyone who proposes changes to the fork is covered. A dedicated repository in a CG is clearer on that front.
16:51	<bkardell>	oh I see what you're saying... so if I did as it sounded like you were suggesting I would have asked for comments and issues on my repo and then maybe people can't get that right Jeffrey Yasskin ?
17:06	<Jeffrey Yasskin>	oh I see what you're saying... so if I did as it sounded like you were suggesting I would have asked for comments and issues on my repo and then maybe people can't get that right Jeffrey Yasskin ? If the change is big enough, my suggestion would be to create a new repository in the WICG with a spec for the change, and ask for comments and issues there. So, it's not generally worth doing for something you've already sent a PR for, just for future changes.
17:20	<annevk>	Domenic: krosylight: am I correct in thinking that landing https://github.com/whatwg/webidl/pull/1311 won't break the world? Looking at https://whatpr.org/webidl/1311.html#AllowSharedBufferSource perhaps webidlparser doesn't need any updates...
17:21	<krosylight>	Domenic: krosylight: am I correct in thinking that landing https://github.com/whatwg/webidl/pull/1311 won't break the world? Looking at https://whatpr.org/webidl/1311.html#AllowSharedBufferSource perhaps webidlparser doesn't need any updates... The parser will just accept it as an identifier instead of a keyword, which is totally okay
17:32	<annevk>	krosylight: thanks, I'll land it tomorrow then I think, time allowing
18:15	<zcorpan>	annevk: step 9 doesn't use the local name to decide anything, it's only for making the attributes available to https://html.spec.whatwg.org/#html-integration-point
18:56	<zcorpan>	We have both "security-tracker" and "security/privacy" labels. Is this intentional?