Open josepharhar opened 2 months ago
thanks for raising this joey as this is exactly the direction i was hoping for when i proposed the idea in the discussions we've been having about select.
if selectedoption can be associated with a select
declaratively, then authors can get that value pulled into their own button that they can script to do whatever it needs to do - without having to put it inside the select
itself.
it also makes it a lot easier for browsers to implement, as the select's mappings don't need to potentially be variable to account for extra content presented in the page along with the select's button part for invoking the popup - it also then means that a browser is off the hook for having to determine "is this a split button, and if so, do keyboard behavior as a single tab stop - or is this not a split button and just happens to be two buttons in this select container, and thus two separate tab stops would be expected... etc."
this direction simplifies a lot, and is not an unreasonable expectation to put on developers - particularly since developers that were making well supported accessible split buttons (and other composite custom controls) would likely be already following this sort of practice of having the controls be siblings, rather than nested, anyway.
One more thing I forgot to clarify - if you put a <selectedoption>
inside a <select>
, then the association will be set up automatically without the need for the for
attribute, so this will still work:
<select>
<button>
<selectedoption></selectedoption>
</button>
...
</select>
The Open UI Community Group just discussed [select] `<selectedoption for=id>` as an alternative to split buttons and `<button type=popover>`
, and agreed to the following:
RESOLVED: add an attribute called `selectedoptionelement=foo` to select, which can point to a single <selectedoption> element to update. The first <selectedoption> contained within the <select> would also be updated.
I created an explainer PR for this here: https://github.com/openui/open-ui/pull/1071
Maybe the name would be better changed to selectedoptionfor
?
Our latest idea is that in order to support "split buttons" where one button has the
<selectedoption>
and does something author defined and another button actually opens the popover, we support slotting multiple<button>
s inside a<select>
into the in-page portion and signify which button opens the popover with<button type=popover>
.Instead of doing this, we could make
<selectedoption>
capable of living outside of the<select>
and link them together by supporting the existingfor
attribute on<selectedoption>
. This has some benefits:<selectedoption>
inside a<button>
.<button type=popover>
attribute and complicated algorithms to figure out which button(s) open the popover, which I am still trying to figure out how to implement.type=popover
attribute.Current way of making a split button:
What I am proposing:
In cases where the authors want the layout boxes of the two buttons to be siblings, they can put display:contents on the
<select>
. I think this also might be worth doing by default in the UA stylesheet.