Naming of the selected value element

[josepharhar]

In this explainer PR, I added <selectedvalue> as the new element name which is intended to replace behavior=selected-value as per this issue: #702
The reason I chose <selectedvalue> is simply because it matches behavior=selected-value.

@lukewarlow pointed out that perhaps if we named it <value> it could be used in a wider variety of future use cases: #798 (comment)

Anyone have thoughts about what it should be called?

[josepharhar]

@una suggested that <selectedoption> would be a good name as well

[brechtDR]

Maybe selectedoption is better because it shows the text value of the option and not the value attribute.

[css-meeting-bot]

The Open UI Community Group just discussed Naming of the selected value element.

The full IRC log of that discussion

<masonf> q?
<masonf> q+
<hdv> jarhar: I proposed `<selectedvalue>` as a replacement of behavior=selected-value
<hdv> jarhar: but then we're rendering the selected option… so I would be in favour of calling this `<selectedoption>`
<hdv> masonf: I'm the only one on the queue… 
<hdv> masonf: based on the offline conversations we had… this element is going to be pretty special
<hdv> masonf: there probably would be future applications outside of this specific element… so maybe something like `<value>` though I'm not very sure about that one
<Luke> q?
<masonf> ack masonf
<hdv> masonf: I would like it if we could come up with a name that is applicable outside of `<selectlist>`
<Luke> q+
<hdv> Luke: it's more like the label of the option rather than the value… selectedoption could also be applied to other elements, like datalist
<hdv> Luke: Maybe a more generic `<value>` could be added in the future
<masonf> ack Luke
<jarhar> q+
<hdv> jarhar: we could resolve to `<selectedoption>` for now and keep the issue open?
<hdv> masonf: to save yourself some time… would probably suggest to keep it open a bit longer or keep it the same
<hdv> masonf: any objections to that proposed resolution?
<hdv> scotto_: I'm trying to figure out where it could be use elsewhere where it wouldn't be an option that is chosen
<hdv> scotto_: I'm all for reusability of stuff… 
<hdv> masonf: maybe file input… and it receives the name of the file
<hdv> scotto_: that doesn't make sense though… it's not an option, it's a file
<hdv> masonf: my concern exactly
<hdv> masonf: maybe `<currentselection>` or something… `<currentcontent>`
<hdv> scotto_: this is outside the scope of this… I'm still trying to figure out how this is going to work and be returned
<hdv> masonf: how the content of it is created?
<hdv> scotto_: where does it go?
<hdv> scotto_: is it something that can only go in that button[type=] that we talked about …is it always a child of the triggering element or is the expectation that it could be used somewhere else?
<hdv> scotto_: if it always goes inside of the button… do we even need something there?
<hdv> scotto_: I don't really understand
<hdv> masonf: it does not have to be inside of the triggering button… it needs to be inside of the bounds of the rectangle that is the in page component that is the selectlist
<hdv> masonf: otherwise only clicking on the down arrow causes the popup
<hdv> masonf: it needs to be somewhere in the selectlist not necessarily the button
<hdv> scotto_: I would wonder how that could get communicated to the accessibility tree
<masonf> q?
<masonf> ack jarhar
<hdv> masonf: yes, a lot to be prototyped still
<hdv> masonf: jarhar, do you want to resolve now to call it `<selectedoption>` now?
<hdv> jarhar: probably not if we end up needing to revert it soon anyway

[lukewarlow]

Another thought I just had is how does this play with multi selects? doesn't really work in that situation?

(I'm assuming the new element works with multi select?)

[josepharhar]

Yeah I suppose that <selectedoptions> would make more sense than <selectedoption> for multi-select.
I'm not actively working on multi-select yet and plan to do that after we get single-select done. The "select-v2" label for issues in this repo contain multi-select issues.

If you have any ideas for a term that would unambiguously be for singular or multiple options, I'm all ears.

[jp-larose]

Why is this a tag, and not a property on the <selectlist> tag? It could simply be the value property, matching the pattern of other form elements.

[josepharhar]

Why is this a tag, and not a property on the <selectlist> tag? It could simply be the value property, matching the pattern of other form elements.

I'm not sure I understand what the API shape would look like.
Here is an example of how selectedoption would be used:

<selectlist>
  <button type=selectlist>
    <span>selected option:</span>
    <selectedoption></selectedoption>
  </button>
  <listbox>
    <option>one</option>
    <option>two</option>
  </listbox>
</selectlist>

How would you rewrite this without the selectedoption tag?

[jp-larose]

Why is this a tag, and not a property on the <selectlist> tag? It could simply be the value property, matching the pattern of other form elements.

I'm not sure I understand what the API shape would look like. Here is an example of how selectedoption would be used:

[snip]

How would you rewrite this without the selectedoption tag?

I guess my initial thought was that the form would simply submit text, in which case this would be sufficient:

<selectlist value="one">
  <button type=selectlist>
    <span>selected option:</span>
  </button>
  <listbox>
    <option>one</option>
    <option>two</option>
  </listbox>
</selectlist>

Overall, I'm finding this whole structure overly verbose, but I'm beginning to see how it can be useful for styling.

The problem I'm having with a whole element/tag for the selected option, at least the way I'm seeing it here, is that it goes against the DRY principle. This has consequences in regards to redundancy (duplication of data, duplication of effort for programming at all levels), data consistency/integrity (the selected option, if not null, should match exactly the item in the list it's aiming to represent, but an author could mess this up).

Perhaps a better alternative is to use a reference instead of duplicating the data.

<selectlist>
  <button type=selectlist>
    <span>selected option:</span>
    <selectedoption ref="op1"/>
  </button>
  <listbox>
    <option key="op1"><i>one</i></option>
    <option key="op2"><b>two</b></option>
  </listbox>
</selectlist>

The browser could then fill in the whole content of the option for 'op1' in the UI, and send that same data to the server when submitting. When the user changes the selection to 'op2', the browser then simply updates the ref value.

I'm not really attached to the ref and key names for the properties, it's just what popped into mind. The point is to have a way to identify different options without having to textually replicate the whole content. I don't recommend relying on id because that's required to be unique thought out the whole document, whereas key would just need to be unique within the selectlist context.

[jp-larose]

Yeah I suppose that <selectedoptions> would make more sense than <selectedoption> for multi-select. I'm not actively working on multi-select yet and plan to do that after we get single-select done. The "select-v2" label for issues in this repo contain multi-select issues.

If you have any ideas for a term that would unambiguously be for singular or multiple options, I'm all ears.

What about <selected> or <chosen>? Something that avoids the whole singular vs plural...