Table of Contents

1. Introduction
2. Terminology: Understanding Open UI’s Core Concepts
3. Charter and Vision
4. Adding a Design System
5. Creating a Proposal
6. Contributing to Open UI
7. Roles and Responsibilities in Open UI
8. Working Mode & Stages
9. Conclusion

Introduction

Open UI is a community project that standardises the structure, behavior, and accessibility of common web interface components.

It was formed under the Web Incubator Community Group (WICG), with the aim of fixing the differences between design systems and helping guide the creation of built-in browser components in the future.

It differs from other frameworks by promoting universal definitions using HTML, CSS, JavaScript, and ARIA — all to ensure interoperability, accessibility, and consistency on the web.

The Open UI Community Group is tasked with facilitating a larger architectural plan for how HTML, CSS, JavaScript, and Web APIs can be combined to provide the needed technology for modern custom user interfaces. Once foundational planning is completed, each necessary web standard will be defined in the appropriate working group. Open UI itself doesn’t create the standards — it gives recommendations to those who do.

Terminology: Understanding Open UI’s Core Concepts

Open UI uses a set of consistent terms to describe components and ideas. Understanding these terms is key to understanding Open UI.

• Specification: A document that defines how a component should work. This includes what parts it has (anatomy), what states it should have, and its accessibility requirements.
• Anatomy: These are the different parts that make up a component. For example, a <popup>'s anatomy is composed of the trigger and the content.
• States: These are the different conditions that a component can be in. They include open, closed, disabled, active, inactive, etc. Normally, they affect how it looks and behaves.
• Behaviors: This defines how a component responds to state changes.
• Component: A reusable interface element, defined by its model, parts, slots, and states.
• Control: A specific type of component that allows user interaction (e.g., buttons, sliders). Controls often manage internal state and behavior through logic tied to user input.
• Composite Component: This is a component that is made up of other components. For example, a <file> upload control is made up of an <input> and a <button>.
• Graduated Specification: A proposal that’s ready to be sent to official web standards groups (like W3C or WHATWG) so they can make it part of the web platform.

Charter and Vision

Background

Since 1993, browsers have had basic UI controls. These include text inputs, buttons, and file uploads. As the web began demanding more interaction, the built-in controls weren’t enough. Developers began depending on plugins and JavaScript frameworks, which caused performance and accessibility issues.

Vision

Open UI wants to improve how web controls work. The goal is to build a flexible system using HTML, CSS, JavaScript, and Web APIs so developers can create user interfaces that are easy to customize and accessible to everyone. The Open UI group will suggest new standards to official groups like WHATWG and CSSWG.

Scope of Work

• Research: Study and document common UI patterns and what developers need.
• Plan: Define Open UI design principles.
• Recommend: Suggest changes to HTML, CSS, JavaScript, ARIA, and Web APIs.

Out of Scope

• Creating new UI patterns.
• Defining default UI look and behavior for specific systems or devices.

Adding a Design System

Design Systems Used for Research

1. Ant Design by AFX
2. Atlaskit by Atlassian
3. Auth0 Styleguide by Auth0
4. Boosted by Orange
5. Bootstrap by Bootstrap
6. Carbon Design System by IBM
7. Chromium by Open Source
8. Evergreen by Segment
9. UI Fabric by Microsoft
10. FAST by FAST
11. Firefox by Mozilla
12. GoodBarber Design System by GoodBarber
13. KoliBri by Informationstechnikzentrum Bund
14. Lightning Design System by Salesforce
15. Lion by ING
16. Material Components Web by Google
17. Material UI by MUI
18. Primer Design System by GitHub
19. Semantic UI by Semantic Org
20. Spectrum by Adobe
21. Stardust UI by Stardust UI
22. Tailwind Elements by MDBootstrap
23. WAI-ARIA by W3
24. Web Platform by WHATWG & W3C
25. WebKit by Open Source​

... and many more.

Design Systems Analysis

The purpose of analyzing different design systems is to catalog UI standards, utilizing JSON schemas for consistency and machine readability.

What’s a Design System?

A design system is a collection of ready-made parts, assets, and styles used across platforms. Examples include Google’s Material Design and IBM’s Carbon Design.

Design System Criteria

To be useful for Open UI, design systems must fulfill the following criteria:

• Work on different platforms and frameworks
• Focus on accessibility
• Be widely used in real-world apps
• Be well-designed by experienced teams

Adding a Design System

To add a design system to Open UI, create a JSON file (e.g., /antd.json) with the required details such as name, description, and URL.

Adding Components

Inside the JSON file, list your UI components in a JSON array under the key "components". Only consider the main, interactive components—leave out the helper components.

Concepts

Concepts describe how components look or behave.

Adding Images

It’s helpful to include images to show how a component looks or how it works.

Try it Out

Once you add your documentation, the component will appear in the Open UI menu. You can switch views between research and proposal.

Creating a Component Spec

Two pages are required to add a component to Open UI:

• A research page: to collect examples and data
• A proposal page: to suggest a formal version of the component

Creating a Proposal

The Proposal Page summarizes your findings, conclusions, and open questions.

1. Front Matter

Define your component and link to the research page:

menu: Proposals
name: Your Component
pathToResearch: /components/your-component.research

2. Working Through the Template

Use the proposal template to cover all necessary aspects, skipping sections that don't apply but explaining why.

3. Gaining Consensus

Each change in your proposal must be backed by research and discussed in an issue.

4. Avoid Re-defining Existing Specs

Do not redefine existing web standards. If something is missing, propose it and file an issue for the relevant specification.

5. Denoting Open Questions

Mark unresolved questions with:

<p class="question">QUESTION</p>

6. Definitions

• Component: A part of a design system.
• Control: A component with user interaction.
• Composite Component: A component that contains other components (e.g., <file> with <input> and <button>).

Contributing to Open UI

Contributing to Open UI is straightforward. Here is the process:

Join the Community

Start by joining the conversation using the following platforms:

• Discord for weekly meetings and collaboration.
• GitHub to open issues or submit proposals.
• W3C Community Group membership is required for official contributions.

The Contribution Process

Component standardization follows a 4-stage model:

1. Research & Proposal: Analyze how a component is implemented across design systems, browsers, and platforms.Share your findings and submit a proposal via a GitHub PR.
2. Editor’s Draft: Draft a spec using the component template. This should include anatomy, behavior, states, and accessibility.
3. Community Draft: Collect feedback from W3C groups, browser vendors, and developers. Iterate and improve.
4. Recommendation: Finalize as a Web Component or spec for native implementation. Update related standards (HTML, CSS, ARIA, AAM).

Roles and Responsibilities in Open UI

Open UI defines clear roles to help collaboration and progress:

• Contributor: Refers to anyone who participates by joining meetings, filing issues, or submitting PRs.
• Champion: This is someone who leads the development of a specific component or proposal. Champions attend meetings, guide specs, and synthesize community feedback.
• Editor: Maintains the specification’s quality and consistency. Editors review PRs, respond to input, and keep the spec aligned with Open UI goals.
• Chair: Oversees the broader project, facilitates meetings, mentors contributors, and ensures a respectful and productive community.

Working Mode & Stages

The following table explains the various stages and working modes in Open UI.

Specs may become browser features or usable web components.

Conclusion

Open UI aims to make web development stronger, more accessible, and ready for the future. By bringing together multiple frameworks, Oe Ui is helping make UI components more standardized.

It's a project worth following and contributing to for those serious about front-end development.