-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define the <selectedoption>
element
#10633
base: main
Are you sure you want to change the base?
Conversation
The `<selectedoption>` element is part of the customizable `<select>` proposal: whatwg#9799 It allows authors to declaratively clone the contents of the currently selected `<option>` of a `<select>` and style it independently for use in a base appearance `<select>`'s button. The timing of cloning has been discussed here: whatwg#10520 The selectedoption element has been discussed generally here: w3c/csswg-drafts#10242
It seems this is missing a lot of the boilerplate that new elements normally have as well as changes to content models, indexes, etc. See also this checklist at the top of
|
I recreated the [original PR](w3c/html-aam#566) by @josepharhar The `<selectedoption>` element is part of the [customizable select feature](whatwg/html#9799) and is being added to HTML [here](whatwg/html#10633). ## Implementation * WPT tests: web-platform-tests/wpt#45096 * Implementations (link to issue or when done, link to commit): * WebKit: TODO * Gecko: TODO * Blink: https://chromium.googlesource.com/chromium/src/+/18b5eac27b14b409503aa8047cf9358082a0e0df Co-authored-by: Joey Arhar @josepharhar
Thanks!
|
This still seems incomplete. Where does the |
source
Outdated
<li><p>Run <span data-x="dom-parentnode-replacechildren">replaceChildren</span> on | ||
<var>selectedOption</var> given <var>nodes</var>.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You cannot invoke public API.
Also, per the discussion in #10520 this is not the cloning behavior that's implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not the cloning behavior that's implemented?
It was this way before I made it use a MutationObserver. I am planning on reverting that patch in order to support the synchronous timing which was able to get consensus at WHATNOT.
You cannot invoke public API.
Good catch, thanks! I inlined the steps from the dom spec.
Thanks, I updated the content model of the button element |
<li><p>Let <var>nodes</var> be « ».</p></li> | ||
|
||
<li> | ||
<p>If <var>option</var> is not null, then for each <var>child</var> of <var>option</var>'s <span |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the algorithm declaration <var>option</var>
is not a nullable type (i.e., an <code>option</code>-or-null
). So this part of this condition will never be hit. We can either remove this null check, or if it is intentional, change the algorithm declaration to accept nullable option elements in the manner I described.
It looks like it is intentional for at least one reason, maybe two:
L56014
explicitly passes in null to clear the selected optionL55984
: you might be expecting null to be passed in, in the case where we can't find a suitable<option>
? I'm not sure. In that case though, I don't think it would follow that we'd just implicitly pass in null as the option.
See my other comment in this review though, indicating that I think we should solve this by not allow this variable to be nullable in this algorithm.
<var>nodes</var> and <var>option</var>'s <span>node document</span>.</p></li> | ||
|
||
<li><p><span>Ensure pre-insertion validity</span> of <var>convertedNode</var> into | ||
<var>selectedOption</var> before null</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<var>selectedOption</var> before null</p></li> | |
<var>selectedOption</var> before null.</p></li> |
|
||
<li><p>Run <span>clone an option into a selectedoption</span> given the first <code>option</code> | ||
in <var>firstAncestorSelect</var>'s <span data-x="concept-select-option-list">list of | ||
options</span> whose <span data-x="concept-option-selectedness">selectedness</span> is true and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
options</span> whose <span data-x="concept-option-selectedness">selectedness</span> is true and | |
options</span> whose <span data-x="concept-option-selectedness">selectedness</span> is true, and |
<li><p>Let <var>convertedNode</var> be the result of <span>convert nodes into a node</span> given | ||
<var>nodes</var> and <var>option</var>'s <span>node document</span>.</p></li> | ||
|
||
<li><p><span>Ensure pre-insertion validity</span> of <var>convertedNode</var> into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point, <var>convertedNodes</var>
is expected to be null if <var>option</var>
is null, right? I think that's the case because if <var>option</var>
is null, then "convert nodes into a node" would just return null.
And if <var>convertedNodes</var>
is null here, then I think we would always fail the pre-insertion validity check, per its step 4. Basically I think we should just handle the "clear-the-selectedoption" case separately from the "actual clone" case, instead of merging them together and having the clone algorithm accept a null option.
<var>selectedoption</var>, are:</p> | ||
|
||
<ol> | ||
<li><p>Let <var>firstAncestorSelect</var> be null.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an ultra nit but I think I would rename this nearestSelectAncestor
. The ordering of ancestorSelect
feels slightly odd, so I'd suggest selectAncestor
, and "nearest" is less ambiguous than "first" (since first is not directional, regarding the list of all ancestors).
support <code>selectedoption</code> elements:</p> | ||
|
||
<ol> | ||
<li><p>Run <span>maybe clone option into selectedoption</span> given <var>element</var>.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary if we are already modifying the global insertion and removal steps too?
The
<selectedoption>
element is part of the customizable<select>
proposal: #9799It allows authors to declaratively clone the contents of the currently selected
<option>
of a<select>
and style it independently for use in a base appearance<select>
's button.The timing of cloning has been discussed here:
#10520
The selectedoption element has been discussed generally here: w3c/csswg-drafts#10242
html-aria PR: w3c/html-aria#528
html-aam PR: w3c/html-aam#566
(See WHATWG Working Mode: Changes for more details.)
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interactive-elements.html ( diff )