Skip to content

Define the <selectedcontent> element #10633

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

Open
wants to merge 46 commits into
base: main
Choose a base branch
from

Conversation

josepharhar
Copy link
Contributor

@josepharhar josepharhar commented Sep 18, 2024

The <selectedcontent> element is part of the customizable <select> proposal: #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.

Some details on the cloning behavior, which were decided on in order to always make sure that the selectedcontent element is up to date and in order to reduce developer confusion:

  • Cloning is done with an algorithm similar to the Node.cloneNode() function.
  • Cloning is done synchronously at these times:
    • When an </option> end tag is parsed during HTML parsing.
    • A selectedcontent element is inserted, during its post-connection steps.
    • Immediately before input and change events are fired on a select element.
    • When the select.selectedIndex IDL is assigned to.

Fixes #10520

The selectedcontent element has been discussed generally here: w3c/csswg-drafts#10242

html-aria PR: w3c/html-aria#528
html-aam PR: w3c/aria#2344

(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 )

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
@annevk
Copy link
Member

annevk commented Sep 19, 2024

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 source:

 !   Adding a new element involves editing the following sections:
 !    - section for the element itself
 !    - descriptions of the element's categories
 !    - images/content-venn.svg
 !    - syntax, if it's void or otherwise special
 !    - parser, if it's not phrasing-level
 !    - rendering
 !    - obsolete section
 !    - element, attribute, content model, and interface indices

scottaohara added a commit to w3c/aria that referenced this pull request Sep 27, 2024
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
@josepharhar
Copy link
Contributor Author

Thanks!

  • I added a dl with a bunch of metadata for the element itself.
  • I didn't include this element in any categories
  • I didn't update the content-venn image because I didn't add it to any categories.
  • I didn't update syntax or parsing because it doesn't have any special rules and I didn't implement anything in the HTML parser for this.
  • I didn't update rendering because I noticed that elements like <div> and <span> don't have sections in there, and selectedoption is supposed to render like those elements.
  • I didn't update the obsolete section because nothing is becoming obsolete...?
  • I updated the element and interface indexes

@annevk
Copy link
Member

annevk commented Oct 4, 2024

This still seems incomplete. Where does the button element indicate this element can be a descendant, for instance? If you don't adjust the categories, you still need to account for how the categories are used.

@josepharhar
Copy link
Contributor Author

This still seems incomplete. Where does the button element indicate this element can be a descendant, for instance? If you don't adjust the categories, you still need to account for how the categories are used.

Thanks, I updated the content model of the button element

Copy link
Member

@domfarolino domfarolino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I think this LGTM!

I would like some clarification in the OP as to whether #10520 is fully resolved and fixed by this PR. And we'll need to check the rest of the boxes in the OP and fill out the needed information. I'll add the DNM label until these are satisfied.

@domfarolino domfarolino added the do not merge yet Pull request must not be merged per rationale in comment label Jan 28, 2025
aarongable pushed a commit to chromium/chromium that referenced this pull request Jan 28, 2025
This sort of makes us match the spec more closely:
whatwg/html#10633 (comment)

When there is a <selectedcontent> inside nested <select>s, we were
adding the <selectedcontent> to all <select>'s descendant
selectedcontent element lists. This was probably fine but it also wasn't
removed properly in HTMLSelectedContentElement::RemovedFrom, so I'm
adding an early return to prevent adding the <selectedcontent> to the
upper <select>'s list of descendant selectedcontent elements.

Change-Id: I1591ce192ec3033f32de319e4cb5431aec19cfa3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6196578
Reviewed-by: Dominic Farolino <[email protected]>
Commit-Queue: Joey Arhar <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1412608}
source Outdated
<li><p>Let <var>firstMatchingOption</var> be null.</p></li>

<li>
<p>For each <var>option</var> in the <code>select</code>'s <span
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>For each <var>option</var> in the <code>select</code>'s <span
<p>For each <var>option</var> of <span>this</span>'s <span

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's only partially done it seems. in -> of is also important.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, my bad. Should be fixed now.

I wish the "commit suggestion" button actually worked for these PRs

Copy link
Member

@domfarolino domfarolino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still LGTM; there are two things I'd like to see:

Once I get some clarity on these two I think we're ready to land this; I will hold off until the end of the week.

@josepharhar
Copy link
Contributor Author

Done. Copying into this comment too in case the commit message gets clobbered by the thing that updates the commit message with the build of the PR:

Some details on the cloning behavior, which were decided on in order to always make sure that the selectedcontent element is up to date and in order to reduce developer confusion:

  • Cloning is done with an algorithm similar to the Node.cloneNode() function.
  • Cloning is done synchronously at these times:
    • When an </option> end tag is parsed during HTML parsing.
    • A selectedcontent element is inserted, during its post-connection steps.
    • Immediately before input and change events are fired on a select element.
    • When the select.selectedIndex IDL is assigned to.

source Outdated

<p w-dev>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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"cloned copy" is a pleonasm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I removed "cloned". How does it look now?

source Outdated

<ol>
<li><p>Let <var>childClone</var> be the result of running <span
data-x="concept-node-clone">clone</span> given <var>child</var>, null, true.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and true?

But also, I don't think this works anymore now that concept-node-clone has named arguments?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I changed it to use named arguments. How does it look?

@scottaohara
Copy link
Collaborator

@domfarolino sorry, I missed your mention of me since I've already been mentioned in this thread, github doesn't make it clear when someone has been re-mentioned.

the html aam (2344) PR is waiting on this to merge. It hasn't had any updates since I made some wording changes to a note in February. There are various other HTML AAM PRs related to customizable select which are also ready to go once everything is ready to merge into the HTML spec.

the aria in html pr (528) is essentially ready to go as well. No more spec updates needed, just some issues to file against conformance checkers.

<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>
</ol>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to use replace all with nothing here, no? It would be good to write some mutation observer tests for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I changed it to replace all with null. I am working on mutation observer tests.

@scottaohara
Copy link
Collaborator

@josepharhar not sure if this is the PR to comment on or not, but per our chat discussion it's probably worth calling out that while <option label=foo> can be used with the customizable select, and will render a visible label for the option in the select's popup - if selected nothing will be returned to the selectedcontent element - since that works by cloning the descendants of the option, and in this care there are none.

Someone can still benefit from broader styling capabilities and still define option element label text using the attribute if their customized select does not contain a button part (and thus no selectedcontent element). Maybe it makes sense to call this out? that way, if someone does attempt to use label attributes when defining their options, it's made clear "if you want to do this, then you shouldn't use the button part/selectedconent elements. but, to have greater control, use child content of the option to define your labels, which will also allow for more styling capabilities for represented the selected content in the select's collapsed state.

or you know... word smith as you see fit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements do not merge yet Pull request must not be merged per rationale in comment topic: forms topic: select The <select> element
Development

Successfully merging this pull request may close these issues.

Timing of cloning for the <selectedoption> element
8 participants