Skip to content
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

Update content model for customizable select #10586

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

Conversation

josepharhar
Copy link
Contributor

@josepharhar josepharhar commented Aug 28, 2024

This PR updated the content model for the <select>, <option>, and <optgroup> elements in support of customizable <select>.

Fixes #10317

  • At least two implementers are interested (and none opposed):
    • Google
  • Tests are written and can be reviewed and commented upon at:
    • I'm not sure if this change can be tested?
  • Implementation bugs are filed:
    • Chromium: …
    • Gecko: …
    • WebKit: …
    • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
    • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
  • MDN issue is filed: …
  • The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)


/dom.html ( diff )
/embedded-content.html ( diff )
/form-elements.html ( diff )
/grouping-content.html ( diff )
/index.html ( diff )
/scripting.html ( diff )
/text-level-semantics.html ( diff )

This PR updated the content model for the <select>, <option>, and
<optgroup> elements in support of customizable <select>.

Fixes whatwg#10317
@zcorpan zcorpan self-requested a review September 12, 2024 16:07
@zcorpan
Copy link
Member

zcorpan commented Sep 16, 2024

Is the idea to allow <select><div><h1><option> and such? Or only <select><div><div><option>?

If the former, you need to change the definition of phrasing content to include "option (if it is a descendant of a select element), optgroup (if it is a descendant of a select element)".

If the latter, you need to change the content model if div and span to switch on whether there's an ancestor select element, and if so allow "select element inner content elements". (But still disallow nesting of optgroup and option)

source Outdated
Comment on lines 53234 to 53235
<dd>Zero or more <span>select element inner content elements</span>.</dd>
<dd>Zero or one child <code>button</code>.</dd>
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
<dd>Zero or more <span>select element inner content elements</span>.</dd>
<dd>Zero or one child <code>button</code>.</dd>
<dd>Zero or more <span>select element inner content elements</span>, followed by zero or one
<code>button</code> element.</dd>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The button should probably go first, and I wanted to keep the "zero or one" concept with the button, so I wrote it like this:

<dd>Zero or one <code>button</code> element followed by zero or more <span>select element inner content elements</span>.</dd>

Look good?

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated
<dd>If the element has no <code data-x="attr-option-label">label</code> attribute and is a child
of a <code>datalist</code> element: <span data-x="text content">Text</span>.</dd>
<dd>If the element has no <code data-x="attr-option-label">label</code> attribute: <span>Text content</span> and zero or more <code>div</code>, <code>span</code>, <code>noscript</code>, <code>img</code>, <span>SVG <code>svg</code></span>, and <span data-x="script-supporting elements">script-supporting</span> elements.</dd>
<dd><div class="note">If an <code>img</code> is used within an <code>option</code> and there is no other text within the <code>option</code>, then the <code>option</code> won't have an accessible name unless the <code>img</code> also has a non-empty <code data-x="attr-img-alt">alt</code> attribute.</div></dd>
Copy link
Member

Choose a reason for hiding this comment

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

Don't have notes in the "element" box, put it further down along with the prose about the content model. The note is also not correct, so maybe it's better to remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought this was what @scottaohara suggested, but as per this comment, it sounds like we can add notes and examples as a follow up. I removed the note for now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

besides the placement could you elaborate on what was wrong with the note @zcorpan? i might have phrased it a bit differently, but it seemed to be saying <option><img src=...></option> would have no accessible name, and that is correct.

@zcorpan zcorpan mentioned this pull request Sep 16, 2024
5 tasks

<li><code>span</code> elements.</li>

<li><code>img</code> elements.</li>
Copy link
Member

Choose a reason for hiding this comment

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

Is the idea to allow img between options?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. @scottaohara do you think this should be forbidden?

Copy link
Collaborator

Choose a reason for hiding this comment

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

i think people will generally just want images within their options. they'll probably also sometimes want to use them within the legend for optgroups. If it were just up to me, i'd limit their use to being children of these elements.

per discussions that were had on this, the primary use case people seemed to think authors might want them for, outside of options, would be for decorative reasons. but i don't see why that couldn't be done with the allowed divs/spans and CSS.

@josepharhar
Copy link
Contributor Author

Is the idea to allow <select><div><h1><option> and such? Or only <select><div><div><option>?

If the former, you need to change the definition of phrasing content to include "option (if it is a descendant of a select element), optgroup (if it is a descendant of a select element)".

If the latter, you need to change the content model if div and span to switch on whether there's an ancestor select element, and if so allow "select element inner content elements". (But still disallow nesting of optgroup and option)

h1 elements are not supposed to be part of the content model, so I implemented the div and span switching by pulling out the content models for option and optgroup and using them in div and span.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Content model and 'what' to render for stylable <select> elements
3 participants