WHATWG
2026-07-08
plaintext logs
prev next
source on github
05:45
<annevk>
Anyone interested in some DOM editorial review? https://github.com/whatwg/dom/pull/1484
06:20
<Noam Rosenthal>
Anyone interested in some DOM editorial review? https://github.com/whatwg/dom/pull/1484
Can get to it in a few hours
10:17
<Noam Rosenthal>
Done
12:50
<annevk>
Thanks!
13:35
<annevk>
I keep reading moveBefore() wrong.
13:37
<Luke Warlow>
It's lost all meaning to me I've read it all so much now.
13:37
<Alice>
wrong in the sense of what the receiver/arguments are?
13:37
<Alice>
cause that confounds me every time
13:39
<Luke Warlow>
Yeah logically based on name I'd expect the caller to be the thing that moves.
13:39
<Noam Rosenthal>
Yea it was supposed to be consistent with insertBefore with the thought that we would add move semantics to the other verbs in the future
13:39
<Luke Warlow>
But the DOM APIs all follow this weirdness so consistency is probably best
14:34
<dbaron>
my attempts to sneak a preference for smalltalk function naming conventions into the TAG design principles failed. ;-)
14:35
<dbaron>
(in particular, I think smalltalk has a practice where function names are split up and the arguments placed in between the parts of the name, so a function called moveBefore would clearly have the thing you move as the first argument and the thing it's before as the second argument.)
15:03
<annevk>
But this follows those principles right? However, I keep thinking we're moving this.
15:11
<Noam Rosenthal>
I feel the same when I use insertBefore, apart from already being used to it because it's old.
15:11
<Noam Rosenthal>
Maybe adding moveReplaceChildren, moveAppend, movePrepend, moveReplaceWith will help here
16:08
<dbaron>
yeah, I guess this does follow those principles. I never remember, I just have to look it up if I want to use insertBefore or moveBefore. Or I can use Element.before() or Element.after() without looking it up.
18:11
<jmdyck>
Consider the sentence (in HTML 4.11.3.5) "The Label of the command is the value of the option element's label attribute, if there is one, or else the option element's descendant text content, with ASCII whitespace stripped and collapsed." which I'll abbreviate as "X is A, or else B, with C." So, on the face of it, there's an ambiguity as to whether the "with C" applies to "A or B", or just "B". Is there a rule that tells me which is the intended/correct parse?
18:16
<dbaron>
I don't know that there's a good general rule -- but in this case I think it's probably just B.
18:17
<dbaron>
the spec could probably use a <dl switch> here.
18:19
<dbaron>
<dt>If the option element has a label attribute
<dd>the value of that attribute
<dt>otherwise
<dd>the option element's descendant text content, with ASCII whitespace stripped and collapsed
19:08
<annevk>
Yeah replacing this with a simple algorithm seems like the way to go
19:08
<annevk>
Though I cannot say for sure which interpretation is correct. If commands are implemented we could at least test
20:04
<dbaron>
The existence of code like: Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_option_element.cc;l=245-258;drc=b862710ed46fb3be9921820e0c12002b2ac65017 Firefox: https://searchfox.org/firefox-main/rev/0088392ab4ccab730743ed188ddec62d04e578b7/dom/html/HTMLOptionElement.h#77-87 https://searchfox.org/firefox-main/rev/0088392ab4ccab730743ed188ddec62d04e578b7/dom/html/HTMLOptionElement.cpp#219-238 suggests that it's just B. (I didn't check that that code is actually used for the spec quote above, but it seems pretty likely.)
23:55
<jmdyck>
dbaron: Thanks for the links. I tried and failed to find something similar for Ladybird. I also tried and failed to find tests of the functionality in WPT.