Open UI: a charter that writes recommendations, not standards

A charter and a meeting record, not a library

The repository's primary language is recorded as MDX, and that tells you what it holds: prose documents rather than a package. The top level is a charter in `README.md`, a `LICENSE.md`, `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md`, a `site/` directory for the published documentation with `netlify.toml` and a `package-lock.json` beside it, a `meetings/` directory for the community group's records, and `w3c.json` for the group's own metadata. There are no releases. What gets published is the site at open-ui.org and the proposals the group writes, so the artefact to read is the charter and then whatever the site carries.

1993 to 2008: two eras of browser supplied controls

The background section tells the history in two movements. The first set of form controls was specified in the early days of HTML, in 1993, and covered entering text, pressing buttons, uploading files, checking checkboxes and selecting radio buttons. Their visual design was dictated by the browser, often designed to blend in with the underlying operating system, and the charter argues that this is a strength: the same control can behave differently on different device types, integrates with hardware and software, and adjusts to unexpected conditions precisely because the browser handles it. Then, by 2004 to 2008, Web 2.0 had energized interactivity and designers were asking for interfaces HTML did not support, so developers turned to plugins like Flash, non-standard technology like ActiveX, or emerging frameworks like jQuery.

Paving the cowpaths is how HTML5 got its controls

HTML5 is described as born of the idea of paving the cowpaths: the WHAT Working Group set out to take the most popular patterns seen on millions of websites and codify them in HTML itself. The result list in the charter is the one everybody uses. Developers could use HTML for entering a number, a URL, a password or an email address, choosing a date and time, filling out a search field, picking a color, choosing a range from a slider, or choosing an item from a predefined list. For the first time they could also use HTML for placeholder text, for specifying which field should capture focus, and for marking a field required. The claim attached to all of it is that the new elements made forms faster, more secure and completely accessible.

Fifteen years later, the answer is a framework

Another 15 years have gone by since the last major revision to form and interface controls, and the charter's complaint is that most complex web projects today need far more than HTML5 provides. The result is that developers all too often turn to heavy JavaScript frameworks to build the interfaces their designers ask for, and the list of consequences is specific: these custom interfaces are rarely fully accessible, they slow down the page, consume power, open security vulnerabilities and exclude people. A second grievance is added alongside it. Projects reject the built-in controls because they need agency over the look and feel of the interface, since designers demand the ability to express a project's branding across every element on the page, including all user interfaces, and current controls do not allow that.

The ask is an architecture, not a list of widgets

The vision section is where the project stops talking about forms. It is time to modernize HTML once again and standardize the underlying technology needed to create the most common patterns of form and website-level UI controls, but the charter is explicit that HTML alone will not be enough, because new CSS and JavaScript are needed as well. Then the sentence that matters most: rather than simply standardize specific interfaces, it is time to create a more powerful underlying architecture so the creators of websites and apps can design and build their own ideas for interfaces. 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 that technology.

Research, plan, recommend, and then stop

The scope of work is three verbs. Research means documenting universal component patterns seen in popular third party web development frameworks, capturing the commonly used language for component names and parts, states, behaviors and transition triggers, conducting informal developer facing user research, and discovering gaps or bugs in what is possible with current web technology. Plan means debating and defining guiding Open UI Design Principles and defining the developer needs the research uncovered, with progress documented at open-ui.org and on the repository. Recommend means writing draft proposals for targeted improvements to form controls, their styling and their behavior, addressed to HTML, CSS, JavaScript, Accessibility or Web APIs, and delivering them as suggestions to the WHATWG, the CSSWG, W3C, TC39 and other standards bodies. After that, the actual specification happens elsewhere.

Two exclusions, and the second one is the interesting one

Out of scope is a short list with a large consequence. Excluded first is any design, innovation, invention or specification of novel or unique UI patterns or controls, or features that are iconic to a specific platform. Excluded second is any attempt to determine or specify the default look or behavior of these controls in the context of a particular operating system or hardware device. The first says the group codifies what already exists rather than inventing new interaction. The second says it will not decide what a control looks like on a given platform, which leaves the default styling question with the browser vendors and the operating system designers rather than with the standards conversation.

Contributing means joining the group first

The contributing section is short and procedural. This repository is used for work in the W3C Open UI Community Group and is governed by the W3C Community License Agreement, and to make substantive contributions you must join the Open UI CG prior to making a pull request. The site has a Get Involved page describing the other ways to engage, which is the route for people who want to follow the work without a commit to make. The repository therefore behaves like a standards group rather than a project: the `meetings/` directory and `w3c.json` are part of the deliverable. The last recorded push is dated 2026-10-30, and there are no GitHub releases to point at.

Editorial conclusion

Read Open UI if you are a designer or developer who needs to know where web form controls are heading, or if you want to contribute a component pattern to the standards conversation. Do not adopt it as a dependency, because there is no code here to depend on, and do not expect it to settle questions about default styling, which its scope explicitly excludes. Verify first which working group owns the control you care about, since Open UI's role ends at a recommendation, and join the community group before contributing, because a substantive pull request requires membership.

Frequently asked questions

Official sources

1. Issues
2. openui/open-ui on GitHub
3. Project website
4. README