-
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 <selectedcontent>
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 |
Thanks, I updated the content model of the button element |
I just made some changes:
|
<selectedoption>
element<selectedcontent>
element
@@ -53198,6 +53201,8 @@ You cannot submit this form when the field is incorrect.</samp></pre> | |||
<dd><span>Phrasing content</span>, but there must be no <span>interactive content</span> | |||
descendant and no descendant with the <code data-x="attr-tabindex">tabindex</code> attribute | |||
specified.</dd> | |||
<dd>If the element is the first child of a <code>select</code> element, then it may have zero or | |||
one <code>selectedcontent</code> element.</dd> |
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 does not seem accurate as it may also have other content in such cases, right? Otherwise, what would be the point of this element.
@@ -53511,6 +53516,9 @@ interface <dfn interface>HTMLSelectElement</dfn> : <span>HTMLElement</span> { | |||
element, and all the <code>option</code> element children of all the <code>optgroup</code> element | |||
children of the <code>select</code> element, in <span>tree order</span>.</p> | |||
|
|||
<p>Every <code>select</code> element has <dfn>select descendant selectedcontent elements</dfn>, |
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.
I don't like the repetition of the class name in its member. I would also continue to markup selectedcontent
I think.
<ol> | ||
<li> | ||
<p>For each <var>ancestor</var> of <var>option</var>'s <span | ||
data-x="ancestor">ancestors</span>:</p> |
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 need to define ordering here.
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.
I think I would also express the ordering in the name of this algorithm. Maybe something like:
To get the <dfn>option element's nearest select ancestor</dfn>
And I think I would markup option
and select
personally (similar to what Anne suggested further above regarding selectedcontent
).
Also related: #10633 (comment) (regarding ordering of "select" and "ancestor", which is a nit I don't feel that strongly about).
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.
I don't think that's sufficient to define ordering for the iteration though. It needs to be part of the iteration somehow. cc @zcorpan
|
||
<p>Whenever an <code>option</code> <var>option</var>'s <span | ||
data-x="concept-option-selectedness">selectedness</span> is set to true, run <span>maybe clone an | ||
option into selectedcontent</span> given <var>option</var>.</p> |
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.
I don't think we should have behavior triggering of selectedness getting changed. That's very weird.
<p>then for each <var>selectedcontent</var> of <var>option</var>'s <span>option element | ||
ancestor select</span>'s <span>select descendant selectedcontent elements</span>, run | ||
<span>clone an option into a selectedcontent</span> given <var>option</var> and | ||
<var>selectedcontent</var>.</p> |
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.
If we only support a single selectedcontent
element, why do this?
<code>select</code>'s <code>button</code>, with alternate rendering based on different selectors | ||
in the author's stylesheet.</p> |
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.
select element's button element.
As this should describe the semantics, I don't think we should discuss style sheets. That seems more suitable for an example.
<p>Every time the selected <code>option</code> of a <code>select</code> switches from one option | ||
to another, the <code>selectedcontent</code> element removes all of its children and replaces them | ||
with a new cloned copy of the DOM structure of the <code>select</code>'s selected | ||
<code>option</code> element.</p> |
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.
I worry that implementers will look at this and not implement the actual algorithm. Perhaps we can make this web developer edition only or turn it into a note or something?
<code>option</code> element.</p> | ||
|
||
<p><code>selectedcontent</code> elements become associated with <code>select</code> elements when | ||
the <code>selectedcontent</code> is a <span>descendant</span> of the <code>select</code>.</p> |
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.
a select element*
(but this also doesn't seem entirely true as their parent has to be button and the parent of the button has to be a select)
|
||
<li> | ||
<p>For each <var>child</var> of <var>option</var>'s <span | ||
data-x="concept-tree-child">children</span>:</p> |
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.
I think you need to specify order.
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.
Hmm, I don't know? The children member is an ordered set, and I think we can just iterate over ordered sets normally, right? Just like the children
DOM getter doesn't specify the order of the collection returned: https://dom.spec.whatwg.org/#dom-parentnode-children.
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.
Oh right. I forgot I made that change at some point and was thinking about an earlier definition of child.
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.
Nothing major except I'm concerned about using selectedcontent element's insertion steps instead of post-connection steps. This is because I believe the steps as currently specified can run script, and script must not run during an element's insertion steps.
<ol> | ||
<li> | ||
<p>For each <var>ancestor</var> of <var>option</var>'s <span | ||
data-x="ancestor">ancestors</span>:</p> |
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.
I think I would also express the ordering in the name of this algorithm. Maybe something like:
To get the <dfn>option element's nearest select ancestor</dfn>
And I think I would markup option
and select
personally (similar to what Anne suggested further above regarding selectedcontent
).
Also related: #10633 (comment) (regarding ordering of "select" and "ancestor", which is a nit I don't feel that strongly about).
|
||
<li> | ||
<p>For each <var>child</var> of <var>option</var>'s <span | ||
data-x="concept-tree-child">children</span>:</p> |
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.
Hmm, I don't know? The children member is an ordered set, and I think we can just iterate over ordered sets normally, right? Just like the children
DOM getter doesn't specify the order of the collection returned: https://dom.spec.whatwg.org/#dom-parentnode-children.
</ol> | ||
</li> | ||
|
||
<li><p>Let <var>convertedNode</var> be the result of <span>convert nodes into a node</span> given |
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.
nit: this feels like it should be the result of running
or the result of <span> converting
</ol> | ||
</li> | ||
|
||
<li><p>Let <var>convertedNode</var> be the result of <span>convert nodes into a node</span> given |
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.
Maybe for readability/clarity this variable could be documentFragment
?
<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>SelectedContent</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>SelectedContent</var> before null.</p></li> | |
<var>selectedcontent</var> before null.</p></li> |
<ol> | ||
<li><p><span data-x="concept-node-remove-ext">Remove</span> all <span | ||
data-x="concept-tree-child">children</span> of <var>selectedcontent</var>, in <span>tree | ||
order</span></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.
order</span></p></li> | |
order</span>.</p></li> |
|
||
<li><p><span data-x="list append">Append</span> <var>selectedcontent</var> to | ||
<var>nearestSelectAncestor</var>'s <span>select descendant selectedcontent | ||
elements</span>.</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.
I guess this is related to Anne's question above, but do we support multiple selectedcontent
elements or no?
<var>insertedNode</var>.</p></li> | ||
|
||
<li><p>Otherwise, run <span>clone an option into a selectedcontent</span> given <var>option</var> | ||
and <var>insertedNode</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.
Hmm, this scares me a bit! You're calling the "clone an option" algorithm from inside the selectedcontent
's insertion steps, but these steps must not run script, yet the "clone an option" algorithm can run script, IIUC, because of the "replace all" call.
Given that, I'm actually thinking we should run all of these steps not inside the selected content insertion steps, but maybe its post-connection steps instead — those can run script. A test for this would be great, to confirm my suspicion. It might require some tricks to clone a script that will run during the "clone an option" algorithm.
The
<selectedcontent>
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 selectedcontent 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 )
/parsing.html ( diff )