Meta discussion: Coordination/specing of overlap content between Open UI & WHATWG

[gregwhitworth]

Issue #5791 requests an addition of the open state based on research and agreement in Open UI in order to create a spec for the <select> control (anatomy, behaviors, states and events that transition based on behaviors). I would like to discuss, possibly over call or here on how best to coordinate possible overlap to ensure that UAs can implement according to Open UI specifications. I have now met with the CSSWG & ARIAWG regarding this work and there is general agreement to the pain points that Open UI aims to solve and I'd like to facilitate a similar discussion with those here.

To kick things off, I'd like to propose the following:

• WHATWG will define new elements, attributes and DOM APIs that hang off of control
• Open UI pull in content as necessary for the web platform or component library authors to effectively implement the control/component and user interactions and the impacts on the parts
• Open UI will file issues against WHATWG with gaps (such as the open attribute, focus stops for the file input, etc) found but defined within Open UI that need to be brought back to the HTML specification

Let me know if you think a phone call for me to present the content and kick off this discussion further. Thanks!

[annevk]

(Open UI is https://github.com/WICG/open-ui.)

Is an accurate summary that changes to the web platform are standardized here and Open UI serves as some kind of discussion/documentation hub for the effort? If so, I think that division seems reasonable.

[domenic]

Agreed, that makes sense, and mirrors previous incubation efforts, where initial work is done elsewhere but the final specification work is done as pull requests against HTML.

[gregwhitworth]

Is an accurate summary that changes to the web platform are standardized here and Open UI serves as some kind of discussion/documentation hub for the effort? If so, I think that division seems reasonable.

It is a hub for discussion but the resulting output is a functional specification in completion for the control/component which every component lib, UA ultimately ends up producing and there is enough overlap here that we can standardize on which then enables the styling and extensibility of the controls/components. It will also enable us to bring controls/components in there to provide those functional specifications where there may not be a desire to pull the necessary aspects into HTML (as the UA is only one such implementer of these controls/components) but if we do desire to the spec will be there that will have had naming research investigation, necessary parts again backed by research and overlap with input from major component libs and design system/UI folks.

Is there a key group of UI/HTML folks from WHATWG that I can setup a telecon to go over the goals to set the stage for how best to bring in the content to WHATWG (eg: should I open individual issues, should I create an explainer that pulls out the parts within Open UI, etc). As noted in the other issues there was a request of the use cases which is outlined in many places but there are many pieces that are needed to unlock those use cases.

[domenic]

We don't generally do telecons, and prefer public discussion like you're doing in this issue thread.

The best way to participate in the WHATWG process is outlined in https://whatwg.org/faq#adding-new-features and https://whatwg.org/working-mode. In general, the more you can bring to the table as part of WHATWG issues, instead of linking to external documents that assume familiarity with another group's culture, the better.

[gregwhitworth]

The best way to participate in the WHATWG process is outlined in https://whatwg.org/faq#adding-new-features and https://whatwg.org/working-mode. In general, the more you can bring to the table as part of WHATWG issues, instead of linking to external documents that assume familiarity with another group's culture, the better.

Ok, I'll try to write up a <select> explainer that goes into a github issue that outlines the gaps found in Open UI and in our explainer. My instinct is we'll want to break all of those up into separate issues - such as the open state but at least it will provide the cohesive use-case outlined and the known gaps.

cc @dandclark @mfreed7 as FYI