| 01:02 | <TabAtkins> | Hm, there's no list of reflected attributes, is there? |
| 01:02 | <TabAtkins> | (Trying to find examples of attributes that aren't reflected.) |
| 01:04 | <Domenic> | 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? |
| 01:41 | <محسن کمالی> | س |
| 02:25 | <محسن کمالی> | س |
| 07:00 | <annevk> | 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. |
| 08:14 | <Noam Rosenthal> | 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? |
| 08:25 | <annevk> | sideshowbarker: do you know if the old CVS history for specifications can still be found somewhere? |
| 08:31 | <sideshowbarker> | 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. |
| 08:34 | <sideshowbarker> | 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.) |
| 08:35 | <annevk> | Does anyone still have a copy that they could stuff in a git repository somehow? |
| 08:36 | <sideshowbarker> | It depends on which spec |
| 08:36 | <sideshowbarker> | If it were served from dev.w3.org org, then yeah I think we could manage to find copies. |
| 08:36 | <annevk> | Web Crypto came up above. |
| 08:37 | <sideshowbarker> | OK |
| 08:37 | <sideshowbarker> | I will do some digging |
| 08:38 | <sideshowbarker> | 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). |
| 08:39 | <annevk> | sideshowbarker: the Mercurial copy I found suggests there's more history in CVS; they started anew |
| 08:39 | <annevk> | sideshowbarker: https://dvcs.w3.org/hg/webcrypto-api/summary |
| 08:41 | sideshowbarker | looks |
| 08:42 | <sideshowbarker> | well that’s unfortunate |
| 08:44 | <annevk> | Oh wow, I found something by going through the W3C lists |
| 08:45 | <annevk> | It involves Ms2ger (back in 2024 W2) |
| 08:45 | <annevk> | https://wiki.whatwg.org/index.php?title=Crypto&action=history |
| 08:45 | <sideshowbarker> | 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) |
| 08:46 | <annevk> | And https://bugzilla.mozilla.org/show_bug.cgi?id=440046#c43 has the answer bakkot was looking for |
| 08:46 | <sideshowbarker> | excellent |
| 08:46 | <annevk> | UI responsiveness is the reason for the limit in Web Crypto |
| 08:56 | <sideshowbarker> | hmm but was that browser-UI-responsiveness problem only an issue for Firefox in the years before multi-process? |
| 08:57 | <sideshowbarker> | that is, is it actually still relevant at all any longer? |
| 08:58 | <sideshowbarker> | …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 |
| 08:58 | <annevk> | Blocking the main thread is still a concern. |
| 08:58 | <sideshowbarker> | ah OK |
| 08:59 | <annevk> | 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. |
| 15:11 | <bakkot> | aha! thanks much annevk |
| 16:28 | <Dominic Farolino> | Should APIs that take in an AbortSignal and return a Promise, reject the promise when the signal is aborted? |
| 16:28 | <Dominic Farolino> | 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. |
| 16:53 | <Jeffrey Yasskin> | Should APIs that take in an AbortSignal and return a Promise, reject the promise when the signal is aborted? |