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

Naming of the selected value element #808

Closed
josepharhar opened this issue Aug 19, 2023 · 9 comments
Closed

Naming of the selected value element #808

josepharhar opened this issue Aug 19, 2023 · 9 comments
Labels
select These are issues that relate to the select component

Comments

@josepharhar
Copy link
Collaborator

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 josepharhar added the select These are issues that relate to the select component label Aug 19, 2023
@gregwhitworth gregwhitworth added the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Aug 23, 2023
@josepharhar
Copy link
Collaborator Author

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

@brechtDR
Copy link
Collaborator

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

@css-meeting-bot
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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.

@gregwhitworth gregwhitworth removed the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Aug 26, 2023
@jp-larose
Copy link

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
Copy link
Collaborator Author

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
Copy link

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
Copy link

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...

josepharhar added a commit to josepharhar/open-ui that referenced this issue Sep 14, 2023
This is being discussed here:
openui#808

I renamed it to <selectedoption> for now in the chromium prototype, so
the explainer should match.
josepharhar added a commit that referenced this issue Sep 14, 2023
This is being discussed here:
#808

I renamed it to <selectedoption> for now in the chromium prototype, so
the explainer should match.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
select These are issues that relate to the select component
Projects
None yet
Development

No branches or pull requests

6 participants