The Editor's draft for <select> includes an anatomy breaking the control down into distinct parts and slots where a page author could swap in their own HTML to customize the control.

As currently written, the page author would use the <button> and new <listbox> element to slot their custom content into the <select>, e.g.

<select>
    <button>My custom button with custom styles</button>
    <listbox> <!-- potentially styled by the page author -->
        <option>option 1</option>
        <option>option 2</option>
    </listbox>
</select>

I'd like to consider an alternative approach where the <select> parts are replaced by referencing named <slot>s. For example:

<select>
    <div slot="select-button">My custom button with custom styles</div>
    <div slot="select-listbox"> <!-- potentially styled by the page author -->
        <option>option 1</option>
        <option>option 2</option>
    </div>
</select>

Advantages to using elements like <button> and <listbox> for customizing control UI parts:

• Potentially more intuitive for developers. With built-in elements it's obvious that the author is doing something standard, whereas this might not be so clear with named <slot>s.
• No concerns with <slot> name collisions. I'm not sure how much of a real concern this is though, since the scope of the <slot> names is only under a given <select> element.

Advantages to using <slot>:

• Path to standardization and implementation is shorter without the need to introduce new element types (or update behavior for existing elements like <button>).
• There's already well-defined support for fallback content in <slot>s for handling cases where the page author wants to replace some parts of the control but not others. This could be more complex with the new element approach, particularly if we would be relying on parser fixup to fill in elements not supplied by the page author.
• More scalable as we roll this out to more control types. E.g. for <input type="slider"/> it could be easier to standardize more named slots versus introducing <thumb>/<slider> elements, etc.

I've fleshed out this idea further and provided more examples at https://jsfiddle.net/dandclark_msft/f8vmk6np/2/.

Thoughts?

DOM focus doesn't function normally for <option>s under <select> as implemented today.
Calling focus() on an <option> under a <select> does nothing. Setting a tabindex on an <option> under a <select> has no effect on tab order. An <option> under a <select> never matches the :focus pseudo-class even if it is the currently selected option. The document.activeElement can be the <select> but never one of its child <option>s.

Do we want to change some of this behavior? It could be odd if <option> still has these unique lack of interaction with normal document focus if an <option> can be slotted along with normal <div>s etc that can be focusable in a normal way. It could also be useful for the developer to be able to do things like programatically call focus() on a given option as if it were any other element.

For example:

<select>
   <option tabindex="1">option 1</option>
   <div tabindex="2" >Here's something that's in the tab order but not an option</div>
   <option tabindex="3">option 2</option>
</select>

It would be strange if the <option>s behaved differently from the <div> with respect to focus, activeElement, :focus etc.

There is of course a backwards-compatibility problem here, although a potential opt-in mechanism for all new behaviors might deserve its own Issue thread.

I have been building https://github.com/imvetri/ui-editor to solve problems related to front end frameworks. Just wanted to share.

Contextual PR discussion: #54 (comment)

Creating an issue to discuss the merits of two different approaches to surfacing state indicators for Checkbox. Checkbox has two distinct state properties:

1. Checked
2. Indeterminate

These two states are independent and are in many default UA implementations hierarchical in that a checked appearance is typically not represented when the element is also indeterminate. Note that a given visual design could differentiate all four possible state combinations.

Proposed options

Two indicators

#54 defines two separate elements w/ slots to supply content and CSS to these indicators. Providing two elements facilitates the existing default behavior where the indeterminate appearance takes precedence over the checked appearance, and allows an app author to easily override the appearance of one state without affecting the other.

One indicator for both states

#54 (comment) discusses using only a single element for an indicator. This approach facilitates transitions between states because only a single element is used.

Please let's step aside from what mainstream frameworks do and not name (not just) our buttons small or large.

In your design system your buttons should have unified sizes - if possible. But consider this. You will make a large button for your website - it will be probably used once - in your "carousel" as Call to Action button. Then a new display devices will become available/most used, or new design style will became popular and what do you do? Add new button called "Larger"?

The names shouldn't ever represent how the components looks (eg. small, red, rounded, spaced), but how it behaves (active, disabled) or how its used in your project (standard - primary, icon, ...)

The main point is: If you design a small/large button, a guarantee you that somebody will come and design even smaller/larger button and you won't have a name for it. Don't fall for the same trap as Bootstrap did with grid naming xs, sm, md, lg.

Currently Flutter framework also has Web support and good UI component system. Maybe it would be good to include it into https://open-ui.org/analysis/component-matrix?

https://open-ui.org/components/select#structure bans a set of interactive elements from existing under <select>. We should define more precisely how this is enforced and what it looks like when this rule is broken. Parser rules can prevent these elements from being placed under <select> at parse time, but they can still be injected there dynamically. So we have to handle this case.

There are a number of things we could do here:

1. Refuse to slot the banned content into the <select>'s shadow DOM. It's not clear how this would be specified, especially given that banned elements could be present in the subtree of a slotted node even if the root of the slotted content was not a banned element.
2. Refuse to render the control if a banned element has been slotted anywhere into the control.
3. Refuse to render any banned content slotted into the control (treat it as display:none?), but allow everything else to work.
4. Show the banned elements but don't allow clicks/user interaction.
5. Other approaches?

Thanks to @mfreed7 for originally raising this question.

None of the images on pages like the one for button have useful text descriptions. They use the image file name instead. For example:

<img alt="andt-carousel-dotposition.png" ...>

I wanted to track this since it came up today - there was a question of whether a (context) menu-item should invoke the default action on right-click and I was unable to find any documentation defining the behavior, but many examples of divergent behavior across web and native UIs.

Would be great to tackle this question when we investigate menus and menu items.

In issue #26 I put a strawman proposal of having a part of icon-arrow and this will be a common paradigm in many controls so I'd like to bring about some conformance on what these should be called. I hesitate to call them glyphs as that conflicts with text glyphs and these should not be unicode or SVG font glyphs. I would really like to defer to the design system folks that have done this many times.

@levithomason @dzearing @chrisdholt @emplums

Would someone with permissions be able to update the repo description? I was sharing on Twitter and noticed it seems a bit outdated (the repo description is what's used for the link preview).

Our mission on the README might be better fit: Maintain an open standard for UI and promote its adherence and adoption https://open-ui.org

Hello earthlings. ✋

Interesting work you are doing here.

I hereby tell my personal opinion on the term "Design System".

I think "Live Style Guide", or "Living Style Guide" was used before to refer to what is referred as DS nowadays. I think it was a better alternative, but the best alternative is "Component library". Maybe marketing thought it's more smashing to use "Design System" - Component library sounds lame.

I think the whole industry skewed at some point during couple of years, when considering the terminology. I am unsure at which point though. The common description seems to be something similar you have on your /contribute page.

"A design system is a collection of assets and components used to create and maintain UIs on multiple platforms.".

I don't think so. Design systems don't exist in vacuums.

I think it also includes people, processes, communication, tools and deliverables. Like most systems do.

What I do think is that:

• A component library is collection of assets and components used to create and maintain UIs on multiple platforms.
• Component libraries are a part of a DS, an integral part.
• Component libraries may include UI patterns (how to use the components in correct ways, how to make pages that are following our UI pattern guidelines)
• Component libraries may or may not include branding guidelines and similar information that exist in style guides (sometimes it's hard to tell which is which)
• DS's are affected by surrounding topics, such as money paid by customer or Coronavirus.
• DS includes a design process ("process is a set of recurrent or periodic activities that interact to produce a result." -Wikipedia)
  • Making layouts
  • Reviewing components, for example.

Some illustration here

Examples of design systems (starting from smaller / least mature from more mature):

• One-man project where a someone draws their initial sketches to napkin and develops them to production with VIM. You could argue that there is a design system here, if he places similar buttons in similar manner, they just aren't documented
• Two-man project where the designer draws layouts with Sketch based on Sketch symbols and sends them to Dev across the globe.
  • What is included in the system here is: The communication tool and language, deliverables, etc
    (... lots of examples here inbetween - with different tools, makers, processes, communication medium, deliverables, pipelines,...)
• Some big system, like: https://designsystem.digital.gov/

Outro

I ran out of coffee so I'm gonna get some. ☕️

I am sure we can't change the industry overnight - and this was just my personal take on the topic.

TLDR: I hope the term Design System will refer "System" instead of "Component library" in future.

I'm forking from the other issue as I think there were two seperate issues in one. This one and whether they should be referred to as glyphs/icons.

@levithomason I think this could be interesting, though I do wonder how semantics will play into this. Several teams across Microsoft use a pencil for "edit"; however, from a longevity standpoint, I think that might be a mistake to standardize on. Teams at MSFT who don't have edit states may also use that specific icon/glyph to signify "pencil" or something else.

A better example may be that in Edge, a star signifies something like a "favorite". In the Store, that same glyph might be used to signify "rating". The icons are semantic for each team and their specific application. I'm curious how we could standardize considering how often this might happen. "Star" would convey the visual of the icons and could offer alignment for both teams, but it might not end up in the table we create simply because teams are naming the glyph for their semantic scenario.

Mind you, I don't have a great solution or alternative proposal - but I'm wondering how the matrix works with the above considered? Thoughts?

Originally posted by @chrisdholt in #27 (comment)

There was a request for this to the CSSWG here: w3c/csswg-drafts#5049

They are currently focused on the psuedo element for button but it would be good to have a full anatomy breakdown on a proposal page backed by our research.

Just throwing my support that we should move this over to the WICG to discuss the newly proposed elements.

<head> section of the HTML documents on the open-ui.org website lacks <title> element.

Even while seo.js component has a title={title} in it,
for some reason it does not get rendered to the HTML output.

        return (
          <Helmet
            htmlAttributes={{
              lang,
            }}
            title={title}  // NOTE: this element is missing

In any case, rest of the sites feels fast & usable. 👍

Would it be useful to include a more-or-less formal definition of a "control" somewhere in the docs? The select Editor's Draft uses the term but I'm not sure whether there's actually a formal definition. If nothing else this could help clarify the Charter regarding which kinds of widgets fall under the purview of OpenUI.

One way to attempt a definition would be to describe what a control does, e.g.:

A control is an HTMLElement with these properties:

1. Maintains a value that is reflected in the value property. Fires input and change events corresponding to changes in the control's value.*
2. Has a common set of APIs for validation of its value (validity, validationMessage, willValidate, checkValidity(), reportValidity(), the invalid event, and others that are specific to particular control types).
3. Participates in <form>s and form submission.
4. Has some user interface that allows a user to interact with the control to view and/or change its value.*

* Partial exception: <input type=”button”> and <input type=”submit”> don’t fire input/change events and their value cannot be changed by user interaction, only viewed (as button text).

This is a valid point brought up by @chancestrickland - we should indeed add a state column to allow you to see how an event behaves in a given state. It may take a bit of figuring out the best way to show that but this should be investigated and added.

Wouldn't the effects of a specific event depend on the current state? For example, keyup(ArrowDown) would either navigate a list of options or expand the options depending on whether or not the select is already expanded. Is it possible to capture this nuance in the table format without cluttering it up too much, or is this intended to be more of a brief reference with a more detailed spec available elsewhere?

Originally posted by @chancestrickland in #96 (comment)

As we continue to dig into the <select> one aspect that is abundtly clear when I review the many different ways in which a <select> is used is the need for arbitrary content within an <option>. While this sounds easy on the surface it raises a bunch of interesting questions, one primary one being whether we should allow interactive content within an option or not. I have currently stated in the spec that a select will not allow any additional interactive elements (and then list them out).

When I look at the usecases where interactive elements are common in a control that is <select> like, checkboxes and radio inputs are the most common. For example here is Fluent:

and here is Safari's built in <select>:

Both of these behave in the same manner. The only aspect that is actually "selectable" is the option itself. And if the <option> can take in an SVG there is nothing stopping fluent, or anyone for that matter, to insert a checkbox icon and change it on checked state of the option as this now becomes possible.

While I do like the idea of authors being able to just insert a checkbox input there are far too many implementation and spec edge cases to contend with. Does anyone disagree with this position?

IIRC in the Google Dev talk a star-rating component was flashed on the screen. But you already have a rating system:
<meter> = measurement, just as rating = another type of measure
Thought of this when I saw #55 .

I like the idea of adding more feature-rich components, but seems people can only hold so many APIs / HTML tags in their heads. EG everything is a <div>, when some should be a <p> <article> <section> etc...

Perhaps 1 or 2 things could be added to make it more rating friendly, but seems you have most of what you need? Just the CSS needs to be more standardized, & Edge repeats differently....

Demo: https://codepen.io/tomByrer/pen/RwPddRN
Though it renders differently in localhost:

At https://open-ui.org/components/select some states are listed as both attributes and as methods of <select>, Examples are autofocus, disabled, and form. All of these should be either one or the other.

The same page also has separate tables for <option> attributes and <option> properties. It doesn't seem to me like this is a useful distinction to make in this context. Would it be clearer to just enumerate the properties (aka IDL attributes)? Or is there value in accounting for the content attributes separately?

There are a few design system JSON files that use "discipline": "development". I was looking to see what other options were available and didn't find it documented.

Additionally, as I'm filling out the Spectrum data, we have separate URLs for the design system usage guidelines and CSS implementation. When we add JS implementations we will have additional URLs for those. Is this something that is supported or will be supported?

@thepassle has begun creating WIA-ARIA adhering generic components/controls. They can be seen here: https://github.com/thepassle/generic-components/

Since we've begun working on the select we end up spinning up little testcases to test out aspects of the component, and it would be good to iterate on actual web components. In speaking with @thepassle he liked the overall goal of Open UI and agreed to move the generic components into Open UI and plans to, time willing, help us further build out the generic component set of web components while we further improve the Open UI control definitions.

Thanks a ton to @thepassle

There is a common demand for improving the styling capability of the checkbox and radio form controls. We need to get these more defined as it relates to anatomy, behaviors, etc and then off of that we'll move necessary proposals for new standards to make this happen.

I think there is value in how to investigate a component's anatomy and we should add this to the contribution docs.

We resolved in the issue #74 to not allow interactive elements within an option. @levithomason asked if this would also be true of the top part, which currently is named which behaves as a button and an expectation of being a native <button>. That said, the web platform, due to the same issues as the <option> additional interactive elements are not allowed within them. Levi brought up scenarios such as a multi-select that shows the selected options in an input at the top that are clickable to deselect the option.

This is to review whether the current anatomy design would limit this capability or not.

For reference here is the current anatomy design:

Related to #73

As we know from @gregwhitworth's survey, <select> is the control developers most re-create.

@mfreed7 did some initial analysis on the stylability of <select>. The results are encouraging: at least in some browser/OS combinations, select/option/optgroup are pretty stylable. In particular, in the best case (Windows 10 Chrome):

• Select: sizing, fonts, background, borders stylable
• Option/optgroup: fonts, and background colors (not background images) are stylable
• Also worth mentioning: you can hide the dropdown arrow using appearance: none, then make it reappear with background tricks.

Mason linked to this Filament Group post by @scottjehl for more detail.

This inspired me to write up a potential plan for incrementally evolving <select>. Here's a rough outline.

Increase the CSS properties that can be used

Make a list of all CSS properties that could reasonably apply to select/option/optgroup. Be generous: this should include more than just what's possible today, but most things that we think could be reasonable. (E.g. padding, margin, maybe background-image on option...)

Write down this list in a spec. Get cross-browser agreement. Write web platform tests, if possible. Getting this to take off cross-browser is important; web developers need to be able to depend on their selects working as expected everywhere.

(Note: we'd probably have an exception for "popup" implementations of select, as are often seen on mobile platforms. Or watches! My impression is that web developers are OK with such popups not being stylable.)

Align datalist and select

Web developers often wish that the platform had a "combobox". Good news: it does! input + datalist gives you a free-form text field with possible suggestions.

However, currently most datalist implementations do not look as aligned with select as they should. Ideally, web developers should get the same look, and same stylability, with input + datalist as they do with select. The only difference should be behavior. They should feel like slight variations on the same control (as they often are on native platforms).

I'm not sure how much spec/tests work we can do here, besides maybe adding some "should" sentences to the spec. This would largely be about getting browsers to agree to converge on a predictable behavior so that web developers come to trust input + datalist.

Make small, targeted extensions

There are probably many small tweaks we could make to select, and to input + datalist, that would make it more pleasant to style. For example:

• A pseudo-element like ::dropdown-button (or ::marker?) to allow developers to replace or style only the dropdown arrow, without having to replace or style the whole control.
• Better support for the notion of a "placeholder option". The spec seems to have this, sort of, but only if the <select> is required="", and it doesn't impact stylability, only form validation. Maybe we should just make placeholder="" work on <select>?
• A pseudo-class for when the select is "open".
• A pseudo-class (?) for determining whether the select will "pop up" (like on mobile) or be a dropdown (like on desktop).

These are all off the top of my head, and it would be better to get actual web developer feedback for prioritizing them or generating better ideas.

Consider UX fixes

Browsers should experiment with just upgrading the user experience of select.

For example, a very common desired experience is that similar to something like select2, where typing narrows the list of options shown, using substring matching. Note that this experience is already possible using input + datalist, except that input + datalist does not constrain the result to be one of the options; the options there are just suggestions, not the only possible choices. (This suggest another alternative could be something like <input type=text list=somedatalist constrained>, instead of modifying <select>?)

If we can get agreement on certain user experiences, then maybe we can try to suggest them in the spec, or in general get browsers to align around them, in order to increase web developer confidence that by using select/input + datalist, they are giving their users a good experience.

So that's one path. I think it needs to be contrasted with the obvious alternative, of creating a new replacement for <select>/<input> + <datalist> from scratch. Call such a replacement <superselect>.

The advantage of the incremental approach is that it's simpler and delivers value incrementally. However, it does have the following disadvantages:

• Developers will forever have to know about both <select> and <input> + <datalist> as two different ways of accomplishing very similar patterns. This is as opposed to just learning about the new <superselect>, and ignoring the previous patterns.
• A new <superselect> would give us a clean slate, which could be easier for browsers to align around, instead of trying to get everyone to change their long-standing controls.
• A new <superselect> gives us the opportunity to introduce more advanced features that can't be added incrementally, such as server-driven autocomplete, arbitrary HTML inside the options, etc.

In issues #26 and #27 we've begun to discuss icons/glyphs that are commonly included in controls such as <input type="date">, <input type="password">, <input type="checkbox">, "`, etc. There are many ways in which we can implement this, all have pros and cons:

1. Background image: We can have it be a background image and standardize this so that authors no to override the background image to their own custom icon/glyph.

2. Inline SVG with CSS propagation: Implement it using SVG which will allow web developers to adjust the styles of the SVG but not adjust the glyph itself since it will be in-content

3. All icons should be both in a ::part and a ::slot to allow for either of the above of the part but also allow the web developer to completely replace the content with whatever they want.

My instinct is to do 3 + 1 or 2 but there are tradeoffs that need to be made. There may also be things that 3 may cause complications but I can build out a web component that's similar.

Let me know your thoughts.

I believe it would be a great addition if we were able to detect the availibility of the refreshed control styles via @supports.

This way CSS can be adapted to work for browsers that do or do not use/support the new styles, or at a point of time before broader support it would signal if the feature flag was enabled or not.

Otherwise making use of new styling rules may impact the look on older browsers or those who do not have the feature flag enabled.

Not sure if this is the proper place to bring it up or not. Perhaps someone can point me to a good place to bring this up or a place where a conversation has already been had.

On a Textarea, it doesn't seem possible to customize the drag handle. I'm attempting to accomplish something like this. Maybe this could be improved to be easier to handle using a slot?

Hey folks,

@domenic and @tkent-google have been working on creating a new built in component of a toggle switch. The open-ui research has done some initial investigations into Switch and I think it would be valuable to utilize this to begin flushing out what both sides (research & platform) can learn from one another.

My ask:

• @levithomason Can you please have the design system folks review the proposal, is there anything that you feel should be added that isn't currently seen in the proposal that you feel conflicts with the data you've gathered
• @domenic @tkent-google is there anything that is within the switch research above that can be clarified and improved for future component designs to speed up the process of part definitions and use cases. The layout and information on that page is in very early stages so any feedback you can provide is valuable.

While working on adding in the events for specific parts of the <select> I noticed that my assumption of what should occur when pressing escape upon changing an option did not behave that way in Chromium browsers on Windows. So I've put together a very basic repro steps, you can use this fiddle to test it out: https://jsfiddle.net/3uh6nfsr/

1. Open the popup and select option Two
2. Now re-open the popup and navigate to option Three using the keyboard by pressing the down arrow
3. Now press the escape key
4. Which option should be selected, Two or Three?

Keeping with the descriptivism of Open UI I decided to look at other browsers and libraries and the results are actually more diverse than I expected:

So here are the results:

• Selected Option Two: 8/13
• Selected Option Three: 4/13
• Done something different: 1/13

In doing a quicker test of multiple selects this would actually bring consistency as multiple selects usually require another key to select them and thus escape does not set that value since it requires another input from the user.

Based on the above here is my proposed resolution:

When pressing the up and down keys changing options this does not update the value of the select

There is an increasing desire/demand for a or component in the web platform. There is also an explainer that is geared to addressing needs presented by the Payments WG for other items using a custom . We should ensure that needs outlined by the various design systems is also covered by this solution. The cross origin needs outlined there are real but we should figure out a way to converge the needs so that webdevs aren't having to create a modal/dialogue different ways with different capabilities of styling, extensibility, etc.

For the web specifications that web frameworks or user agents are to build from, we need to determine how to write/reference tags and APIs. We discussed this at Microsoft and we propose that they utilize standardize web platform naming conventions and APIs if they exist. Examples of the specification could provide either link or code for various popular frameworks to see how they leveraged the specification.

Hey everyone,

I've done analysis across both dropdowns and select components from the naming matrix of the sub parts (not just the top level names). You can see it here

Here is my initial proposal:

• select
  • button
  • popup
    • optgroup
      • option

The main one I'd like to discuss right now is dialog. I considered a few different names, all of them have pros/cons. Listed in order of my preference.

• dialog: This effectively represents what this container is. It is a non-modal dialog in the majority of use cases for a select. There are two negatives:
  • There already is an HTML dialog element which wouldn't be a problem but it is marred by accessibility issues and as such hasn't been widely adopted. It also has the open state on the dialog, which makes sense but the select will need this state as well. This is less of a problem but we should ensure that if open is set on the dialog then this propagates to the <select> as well.
  • Dialog does imply appearance. While the majority of cases it is a dialog, in a multiple state it may be set in page and isn't shown above other content (the inherent expectation of a dialog).
• popup: This has the same negative as dialogue in the sense that it implies appearance. This doesn't have the bug burden of dialog however. Another benefit is that within ARIA they have aria-haspopup which select will need in relation to this container anyways so the naming is consistent here.
• listbox: This wasn't used by a single framework as the name for this container but it is specifically what this container is per the definition in ARIA . That said, the listbox is also what the <select> overall is and so resolving the duplicity of the two seems complicated.
• menu: This bubbled up primarily in frameworks that combine their <select> with <dropdown> menus. This isn't a bad name but the menu element already exists and semantically means that it is a generic list of items, usually a menu with links for example.
• datalist: @chrisdholt brought this one up and it's a good one. The datalist element currently does what this container is doing which is to contain options and show them in a popup/dialog. Only negative I can see is the naming but I'd need to look at the implementation and potential API implications.

NOTE: I'm not 100% sold on button either even though from invocation perspective that's exactly how it behaves in the frameworks and across UAs. It does allow for traversal even in a closed state so I'm open to other naming suggestions for that as well.

When handling collisions, MacOS uses an arrow indicator that scrolls the list on mouseover vs. a traditional scrollbar. Not sure if that's worth to considering as a part, but this is the current experience with a regular select element.

Originally posted by @chancestrickland in #103 (comment)

In discussing the <select> with some people there is a desire to allow for an input to allow filtering of the available options. Some component libraries bundle this in with their select and others refer to this as a combo box. I'm going to do some research as I think it's important to ensure that the anatomy we're defining allows this extensibility if we believe it to be an expected part of the <select>.

Hey everyone,

I really like the wireframes for showing the component's anatomy, but as we get into some more complex components it gets quite ugly. I'd love if someone that is a good designer could help adjust this a little. Here is the currently defined <select> anatomy: https://open-ui.org/components/select#anatomy

Some ideas I've been thinking about:

• Be able to show/hide slots
• Come up with a different color scheme
• If an element contains a slot then just add it to the name (eg: button [slot])

Any other ideas are welcome.

Under the "Names" section of of each component page (eg. https://open-ui.org/components/button) we list the name of the Design System but we don't link to the resource. I believe we have this information because each component entry in a design system is required to have a URL.

I think we should add anchors to the design system names, linking them to the information resource. Directly linking to the resource brings more transparency about where the information is coming from and allows site users and authors to investigate the design system further if desired.

The anatomy currently shows that the default is a split button. Currently on Edge, Chrome, Firefox and Safari they all behave as <button>. @chrisdholt noted that he'd desire to adjust the glyph and so we can't just use a <button> we'll need to define a sub-part. I don't think this requires a new component/element. That said, this needs to stay a slot as Safari's default behaves as a combobox and we desire for web developers to be able to achieve the same with this.

I'd recommend something like this for default:

<button>${value}<span part="icon-arrow"></span></button>

This change actually raises a few questions, and I'm going to break out into their own issues as I want to keep this scoped to the pieces that belong in the slot by default, I'll link the others to this issue.

It would be good for the landing page to do a good job of presenting the problem we're hoping to solve in a clean, simple and straightforward manner. Additionally help describe the relationship between the design systems and the web platform. We should make it easy to jump to the components. Additionally, it would be good to add the logos of companies that are involved in this project.

table cells show dont show the component name properly

proposing solution add title attribute and display something like this. (or use popper)

The top nave should be priority focused, not alphabetical.

• Home
• Charter
• Contribute

The contributing page explains how to document new components but it's not clear to me the exact steps. Should I start documenting a component without first gauging interest with an issue? It seems like that could be a waste of time if there is no interest in that component type.

I would expect a process to go something like:

1. Create an issue about a type of component worth bringing into open ui.
2. If there is interest, start doing research and create a PR.
3. Work on a proposal and a second PR?

The charter page is a little better about explaining the process but it's still a bit unclear to me. https://open-ui.org/charter

There is a common request for more control over scrollbars. There is a specification for improving control here but not nearly to the extent that web developers desire: https://drafts.csswg.org/css-scrollbars-1/

This one is a bit different from the other components here as most design systems don't consider this a component in itself. Commonly JS libs are used to solve this issue, worth looking into those.

Background

UI components should have a data structure that describes them. This can be useful for multiple reasons, here are a select few:

• Interpretation by editing UI such as VS Code
• Creation of UI through form field generation
• Validation of data against them
• Used to search through a library of components

Things that should be included in the data structure are:

• Version
• Categories
• Properties/Attributes
• Style/Theming
• Available nesting patterns
• Descriptors

Proposed structure

{
    id: "open-ui-button",
    description: "A button definition",
    version: 1,
    categories: [
        "form"
    ],
    tags: [
        {
            name: "open-ui-button",
            type: "web-component",
            description: "An Open UI button",
            attributes: [
                {
                    name: "disabled",
                    type: "boolean",
                    description: "The disabled state",
                    default: "false",
                    required: false
                }
            ],
            slots: [
                {
                    name: "",
                    description: "The default slot, content in this slot displays directly inside the button"
                }
            ],
            cssProperties: {
                "--my-button-color": "#FF0000",
                "--my-button-font-face": "Arial"
            }
        }
    ]
}

I'm using some native HTML web component ideas here, but I think we can extend off of it. What might be some of the design system theory we can add to this?

The capability of a <select> being as extensible as possible opens up a bunch of questions for many of the expected events/attributes/interactions. Here is one of them.

If we have the following <select>:

<select>
    <option>
       <input type="checkbox" required> This is a checkbox
    </option>
</select>

What is the value set to on the option?

Currently an option with no set value will get a value of the text content within (test case). In this case however the author desired to have a checkbox so they probably also desire to understand if that is checked or not. So it seems we have the following potential options:

1. The value of option is not set based on any children's contents, but the option is set to a selected state
2. The value of the option is set by combining the text node content from its children (current behavior)
3. The individual controls will have their own name and value and be tracked as such, this will not bubble to the descendant option
4. Disallow this capability
5. Other solution

I'm leaning towards option 3 as it allows the <option> to behave as a <div> would today. The author will apply their values, etc to the checkboxes or other controls. The only value that will be possible to extract from the <select> will be similar to today in <option> elements that are selected and have a value.

I have JS disabled by default, but this tends to cause a long flash of misstyled content too, so normal users are affected by this too.

The GitHub logo that’s supposed to appear in the top right hand corner lacks a width and height, having only a viewBox specified. And the CSS doesn’t fix this. The result of it is that the logo fills the available width until some JS loads and executes, inserting a few styles, including this critical one:

.svg-inline--fa.fa-w-16 {
    width: 1em;
}

In order to fix this, add width="1em" to the <svg> element.

Nothing else is obviously using fa. I opine that its JS should be dropped. It’s terrible for user experience.

Then I suggest dropping the “This app works best with JavaScript enabled.” message. This is a website, and nothing critical looks to use JS. The component matrix sort button uses it, but that button should just be removed unless JS is enabled.

Each group within the W3C has a different way in which to handle stale documents. As we discuss finalizing on the overall process and template I think it's important that the components/controls that we put in place to initially show what Open UI could be should be removed if they aren't actively being worked on. This, similar to other groups, will allow framework/platforms to not look at button, for example, and assume it has made it through the W3C/Open UI standardization process.

I recommend that we remove any document that isn't actively being worked on. I'm open to ideas of possibly adding a toggle or new section that denotes that these are in the Research Phase only.

We need a way in which to show transition of states and other modifications. The checkbox WD does a decent job of this but we need to get a bit more explicit. I think a table that looks like this may be preferable however to show events tied to specific parts as that's how they'll be implemented. In discussing this on discord we discussed having a table per part and the events that are attached to each one and their subsequent impact.

## PART
| Event   |  Behavior      |  Impacts |
|----------|:-------------:|------:|
| foo | the impacted change | State, aria, etc |

This then can be linked to from the the states table that's in the checkbox spec now by linking to the parts that impact a given state. I also added a column so people can quickly skim to see which events impact what. Thoughts?