` because it is the first child element of the `
` which is not a ``, ``, or ` `.
-
-The `type=selectlist` attribute on the inner `` tells the browser that this element should open the listbox when clicked. The browser will automatically apply all the click and keyboard handling behavior to this element as well as the appropriate accessibility semantics.
-
The above code snippet results in the following style:
-You can replace the default listbox part in a similar fashion:
+Here is an example which has a custom listbox with custom CSS:
```html
-
-
+
+
Option 1
Option 2
Option 3
Option 4
Option 5
-
-
+
+
```
The above code snippet results in the following style:
### Extending the markup
@@ -447,12 +395,12 @@ Consider the following example:
```html
-
+
+
+ Choose a plant
+
+
+
Choose a plant
-
+
Flowers
Rose
@@ -502,28 +455,28 @@ Consider the following example:
Dragon tree
Giant sequoia
-
-
+
+
```
Using custom markup to wrap the list of options, the above example creates sections with their own styles and content as seen below:
-## Examples
+### Demo page
-You can find multiple examples of `
` on our [demo page](https://microsoftedge.github.io/Demos/selectmenu/).
+You can find multiple examples of stylable select on our [demo page](https://microsoftedge.github.io/Demos/selectmenu/).
## Keyboard Behavior
-The selectlist element has keyboard behavior inspried by both the existing `` element and the [Aria Authoring Practices Guide Combobox Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/). This behavior was decided in [issue 386](https://github.com/openui/open-ui/issues/386) and [issue 433](https://github.com/openui/open-ui/issues/433).
+When a custom `` element is provided, the `` element has tweaked keyboard behavior. The new behavior is inspried by both the existing `` element and the [Aria Authoring Practices Guide Combobox Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/). This behavior was decided in [issue 386](https://github.com/openui/open-ui/issues/386) and [issue 433](https://github.com/openui/open-ui/issues/433).
When the listbox is closed and the button is focused:
* Spacebar opens the listbox.
-* Enter submits the form associated with the selectlist if one exists. Otherwise, enter does nothing.
+* Enter submits the form associated with the select if one exists. Otherwise, enter does nothing.
* The up, down, left, and right arrow keys all open the listbox without changing the selcted value.
When the listbox is open:
@@ -534,84 +487,9 @@ When the listbox is open:
* The down arrow key moves focus forwards in the list of options and changes the selected value to the newly selected option.
* The left and right arrow keys do nothing.
-## Form Semantics
-
-The selectlist element is a [form-associated element](https://html.spec.whatwg.org/multipage/forms.html#form-associated-element), which means that it can be used to build and submit forms just like the existing `` element.
-
-### IDL
-
-The following IDL is used for selectlist. Most items which are named the same as items for other form-associated elements behave in the same way.
-
-```webidl
-interface HTMLSelectListElement : HTMLElement {
- readonly attribute boolean open;
-
- readonly attribute HTMLOptionElement? selectedOption;
- attribute DOMString value;
- [CEReactions, Reflect] attribute boolean disabled;
- readonly attribute HTMLFormElement? form;
- [CEReactions, Reflect] attribute DOMString name;
- readonly attribute DOMString type;
- [CEReactions, Reflect] attribute boolean required;
-
- readonly attribute boolean willValidate;
- readonly attribute ValidityState validity;
- readonly attribute DOMString validationMessage;
- boolean checkValidity();
- boolean reportValidity();
- void setCustomValidity(DOMString error);
- void showPicker();
-
- readonly attribute NodeList labels;
-};
-```
-
-### The `selectedOption` and `value` attributes
-
-`selectlist.selectedOption` returns the currently selected `` element. This is unlike `` which has a `selectedOptions` property and returns a list of selected options because selectlist only supports one selected option at a time.
-
-Just like the `` element, `selectlist.value` returns the `value` property of the currently selected option.
-
-### The `disabled`, `form`, `name`, `required`, and `labels` attributes
-
-These IDL attributes behave exactly as they do for other form-associated elements as specified by HTML:
-* [HTML spec for `disabled`](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#enabling-and-disabling-form-controls:-the-disabled-attribute)
-* [HTML spec for `form`](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fae-form)
-* [HTML spec for `name`](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-name)
-* [HTML spec for `required`](https://html.spec.whatwg.org/multipage/form-elements.html#attr-select-required)
-* [HTML spec for `labels`](https://html.spec.whatwg.org/multipage/forms.html#dom-lfe-labels)
-
-### The `type` attribute
-
-Like other form control elements, selectlist supports the `type` attribute. It simply returns `"selectlist"`.
-
-### Validity IDLs
-
-Like other form control elements, selectlist supports validity checking attributes and methods as specified by HTML:
-* [HTML spec for `willValidate`](https://html.spec.whatwg.org/#dom-cva-willvalidate)
-* [HTML spec for `validity`](https://html.spec.whatwg.org/#dom-cva-validity)
-* [HTML spec for `validationMessage`](https://html.spec.whatwg.org/#dom-cva-validationmessage)
-* [HTML spec for `checkValidity()`](https://html.spec.whatwg.org/#dom-cva-checkvalidity)
-* [HTML spec for `reportValidity()`](https://html.spec.whatwg.org/#dom-cva-reportvalidity)
-* [HTML spec for `setCustomValidity()`](https://html.spec.whatwg.org/#dom-cva-setcustomvalidity)
-
-### The `showPicker` method
-
-Like other inputs, selectlist supports the `showPicker` method. This method is used to show the listbox. It requires user activation.
-
-## Why not improve ``
-
-Instead of creating a new `` element, we could improve the existing `` element to meet the same needs. However, there are a few problems with this (borrowed from the [Custom Controls UI Explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md)):
-
-- Changing the parsing behavior for `` to allow other element children by default would likely break a lot of old sites that depend on the current behavior.
-- While it might be possible to modify the parser to change rules based on the existence of an opt-in attribute, there would be additional work to be done if JavaScript added or removed that attribute after the fact.
-- The `` popup has the capability to break outside the browser window, and `` will not. If the author wants this capability, they will have to stick with ``. If the author would rather have custom styling, then they should use ``. This is a big differentiation and is more than just an opt-in for styling, so havingt a separate tag name than an opt-in attribute makes more sense.
-
-Given that we would be required to introduce something new into the platform (attribute, element, etc) to opt-in to the new behavior; we opted for a new element. This comes with the added benefit that over the years most developers that want customization of controls and components will not leverage `` at all; akin to how developers leverage `grid` and `flex` display types for layout instead of `` or `float`. Additionally, this has the potential to simplify the implementation cost since we do not have to make substantial changes to the current `` parser
-
## Design decisions
-- [Why "selectlist" instead of "selectmenu"](https://github.com/openui/open-ui/issues/773)
+- [Why reuse `` instead of creating a new element](https://github.com/openui/open-ui/issues/970)
- [Why not use the `slot` or `behavior` attributes](https://github.com/openui/open-ui/issues/702)
- [Why not support the `size` attribute](https://github.com/openui/open-ui/issues/153)
- [Why support `:checked` instead of `:selected`](https://github.com/openui/open-ui/issues/827)