01:11
<Domenic>
Dominic Farolino: annevk: I think my recollection is a bit different. Workstreams have editors which have some theoretical powers (which rarely, if ever, get exercised). For some policy-adjacent reason we thought it'd be best to stick to one editor per workstream, although there are a few exceptions. Standards have authors. In practice authors are the core contributors to the spec. Also in some cases people who have contributed significantly historically but not currently are listed as authors.
04:08
<Dominic Farolino>
Domenic: I see, so when we colloquially refer to someone being the editor of a standard, we really mean "author"? I imagine we rarely ever mean "Workstream Editor", because that role-specific duty is probably rarely relevant to casual conversation around the maintenance of standards, i.e., people who review and can click merge (as evidenced by your "have some theoretical powers (which rarely, if ever, get exercise)..."
04:12
<Dominic Farolino>
And where do deputy editors fit into this? Are those just the other Workstream Editors besides the first person listed there? Or are they the authors? It sounds like they are the authors, since deputy editor is a per-Standard thing, see https://whatwg.org/working-mode#standard at least) not a per-Workstream thing.
04:12
<Domenic>
Yeah that's my understanding. Although re-reading the policy I guess workstream editors are theoretically the ones who are "authorized" to modify the spec. https://whatwg.org/workstream-policy#modifying-the-living-standard
04:13
<Dominic Farolino>
And deputy editors that they delegate too I think
04:13
<Domenic>
So maybe biblio.json author == deputy editor
04:13
<Dominic Farolino>
I think that's right
04:13
<Dominic Farolino>
Or... db.json you mean?
04:14
<Domenic>
Yeah
04:20
<Dominic Farolino>
Filed https://github.com/whatwg/sg/issues/232
04:21
<Dominic Farolino>
I don't really know how the machinery of that repo works but I can take a look tomorrow maybe if nobody gets to it first.
07:36
<annevk>
Dominic Farolino: the main thing you'll have to do is to look at whatwg/whatwg.org's Python scripts to see if they need the same change; there's probably something there that has "authors" in it
08:33
<iamfernando>
Greetings!
08:33
<iamfernando>
I saw a "This list can be changed. If there are schemes that ought to be added, please send feedback." and was wondering where should I send the feedback?
08:35
<iamfernando>
more specifically about https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
09:05
<iamfernando>
Could we have handlers for nostr?
09:58
<sideshowbarker>

About expected behavior for document.execCommand("Paste") with contentEditable elements: Looking at test expectations in https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L106, I’m trying to figure out why in the contentEditable case, the expectation for the result of the paste is the empty string (rather than the source/input string being pasted).

…whereas in the case of the textarea element and input element, the expectation is that the source/input string does get pasted as expected.

10:06
<sideshowbarker>
zcorpan: about the test at https://github.com/WebKit/WebKit/blob/1ade9b72a383daa2aee2e964d15c42877b9fb999/LayoutTests/editing/pasteboard/paste-text-events.html#L25, calling preventDefault()with a textInput event for a document.execCommand("Paste") operation should not actually cause the paste operation to fail, right?