Use new selectmenu anatomy in explainer #798
Conversation
This new anatomy was proposed and agreed on here: openui#702
josepharhar
requested review from
gregwhitworth,
andrico1234,
mfreed7 and
dbaron
as code owners
|
@mfreed7 want to review this? |
| Selectlist supports a variety of pseudo-elements to target its different parts: | ||
| - `::button` - Targets the button slot. | ||
| - `::listbox` - Targets the `<listbox>`. | ||
| - `::marker` - Targets the dropdown arrow of the default supplied button. |
There was a problem hiding this comment.
Are these psuedo elements only available if the author doesn't provide their own element? At which point I should be able to simply style them as elements, correct?
There was a problem hiding this comment.
They should target whatever is rendered, whether thats the default/fallback content or the author supplied one. I added a sentence to clarify
| <Part name="marker">Dropdown indicator (e.g. icon)</Part> | ||
| </Slot> | ||
| <Part name="button type=selectlist"> | ||
| <Part name="selectedvalue">Currently selected value</Part> |
There was a problem hiding this comment.
Should the part name here be selectedvalue or just value?
Reason I ask is virtually all inputs will have some form of "value" part. But selectedvalue only really makes sense for elements with multiple choices? Saying that most elements can be linked up to a datalist so maybe selectedvalue is fine for all of them?
There was a problem hiding this comment.
The new <selectedvalue> element is only intended to work for <selectlist>, at least for now, and it is an element with multiple choices.
Do you think the element's tag name should be <value> instead?
There was a problem hiding this comment.
If it were to be value then it likely could be reused for other inputs in future?
There was a problem hiding this comment.
Good point. I opened an issue to discuss this further: #808
imo they should review it on the public site after this and my remaining patches are merged to the explainer |
+100 I really don’t like that we have so much review happening on these explainers. The feedback is awesome, and it’s not that I don’t want all of the great input! But the history and conversation on a PR is so much harder to follow later, as compared to an issue. I’d really prefer we do a very basic review on these and then land them. Fundamental (or even small) GitHub issues should then be raised to discuss changes, and the explainer gets updated after we resolve those issues. That way we have a paper trail for how we got to where we ended up. |
This new anatomy was proposed and agreed on here:
#702