[select] What should the value of an option element be set when it has multiple children?

[gregwhitworth]

The capability of a <select> being as extensible as possible opens up a bunch of questions for many of the expected events/attributes/interactions. Here is one of them.

If we have the following <select>:

<select>
    <option>
       <input type="checkbox" required> This is a checkbox
    </option>
</select>

What is the value set to on the option?

Currently an option with no set value will get a value of the text content within (test case). In this case however the author desired to have a checkbox so they probably also desire to understand if that is checked or not. So it seems we have the following potential options:

1. The value of option is not set based on any children's contents, but the option is set to a selected state
2. The value of the option is set by combining the text node content from its children (current behavior)
3. The individual controls will have their own name and value and be tracked as such, this will not bubble to the descendant option
4. Disallow this capability
5. Other solution

I'm leaning towards option 3 as it allows the <option> to behave as a <div> would today. The author will apply their values, etc to the checkboxes or other controls. The only value that will be possible to extract from the <select> will be similar to today in <option> elements that are selected and have a value.

[gregwhitworth]

Digging into this a bit further, thanks to @levithomason this question has been asked on Semantic UI here. The examples that show an option that contains a checkbox almost always have a single association of 1 checkbox per option. This is very common across the dropdown/selects I've looked at that include a checkbox.

If this was commonly the case then it would be fine, we could generalize this. But what happens in a tree view type scenario?

[gregwhitworth]

Been thinking about this a bit further and will be closing this out.