I've drafted an update to the Codex page, which can be moved to the Codex page and published once T351753 is resolved. We shouldn't post usage docs until that task is completed, released, and resolved to prevent CSS specificity issues in production.

@Catrope can this be resolved now?

Are we sure we want to change the shadow when it opens up? It feels kind of natural to me to lack the shadow on top of the menu when it's opening up.

@DTorsani-WMF I've pushed a patch to add a new Rules component that can be used in the docs to create dos and don'ts. It's available in all of the docs markdown files, so you don't need to import it or anything.

I made an inventory of all components that style one or more of their subcomponents:

• Accordion: Button, Icon
• ButtonGroup: Button
• Card: Icon, Thumbnail
• Checkbox: Label (via binary-input.less)
• Combobox: Button, Icon, TextInput
• Dialog: Button
• InfoChip: Icon
• InputChip: Button
• Label: Icon
• Lookup: TextInput
• Menu: MenuItem, ProgressBar
• MenuItem: Icon, Thumbnail
• Message: Button, Icon
• Radio: Label (via binary-input.less)
• SearchInput: Button, TextInput
• Select: Icon
• Tabs: Button (cdx-tabs__list__item)
• TextArea: Icon
• TextInput: Icon
• Thumbnail: Icon
• ToggleButtonGroup: ToggleButton
• ToggleSwitch: Label
• TypeaheadSearch: Icon, MenuItem, SearchInput

Huge +1 for Tabs and ChipInput

I would also suggest we test the Field component and its various features with a variety of inputs and input groups. If we need to limit this, I'd suggest:

I'm reopening this based on feedback we got from some Codex users:

• It's not clear when to use TypeaheadSearch and when to use Lookup
• It's not clear that TahS is for page navigation and Lookup is for selecting an item
• The name of the components, especially TahS, do not help clarify their purpose. In particular, both components have "typeahead search" aka autocomplete.
• We could rename one or both components but keep an alias of the old name. Changing CSS class names would be trickier since they are sometimes used outside of Codex (though we discourage this). For example, there are 2 instances of .cdx-typeahead-search selectors in Vector - perhaps these could be updated to a vector-specific classname instead. Unfortunately, there is also a TahS class used in a Vector message (for the search footer text)

Each of these components has an existing demo on the page demonstrating use of the Field component - I'd recommend adding error handling to these existing demos, rather than adding a new separate demo.

Resolving - we can document other composables if Codex users find them useful

@egardner good call, there was one example using Vuex that I updated to use Pinia instead.

We should consider doing this soon to signal to developers of new projects that they should use Pinia and not Vuex

I'm triaging this as medium to differentiate it from low/no priority items. Since we have a use case, and this task is a low lift, I think we should complete it sooner rather than later.

@Celenduin is this perhaps a use case for a Combobox, where you show an initial list of items and then filter the items once there is text in the input?

This page now includes which component library each project was built with

This is not important IMO