Open UIOpen UI GitHub

This project is in its infancy. Expect rapid iteration and high-flux while we flesh out the mission and process.



The web deserves interoperability between component frameworks and design systems. The UI community is in a similar place as the industrial revolution prior to standardization. Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps.

This should not be the case. The UI community should standardize namings and structures for common components. We should also standardize a way of theming these components. We should set a path for existing solutions to converge and for browser to natively provide these things in the future.

UI component patterns have evolved and stabilized but have not made their way to browsers or standards. Designers and developers reinvent the same components for every product they build. When building a web app or web page designers and developers should have a common set of components at their disposal. We shouldn't have to rebuild a dropdown, modal dialog, split button, or other components before we build our products.

For complete outline of goals and process view our full charter.

Goals for web specifications

For web app component specifications here are the specific goals:

  • Standardize on the names of the component parts and anatomy structure
  • Standardize the name of states which are applicable to the component and its parts
  • Standardize the behaviors of components
  • Update other specifications in other standards bodies when gaps are discovered (eg: If discover the need for a new HTML element or CSS property, propose and have it standardized in the WHATWG HTML spec and CSSWG respectively)

Non-goals for web specifications

For web app component specifications here are specific non-goals:

  • Standardize on the default appearance of a component for all implementations


These are the principles Open UI believes should be considered to realize the above goals. As with all rules, there are always exceptions.


  • Descriptivism is superior to prescriptivism for finding names

    Why? Borrowing from linguistic analysis we believe that objective analysis of existing words in use in the UI community at large will produce names that are most likely to be adopted by the broader web.

  • Names should be void of design information

    Why? When designs change names should not become invalid. Names should stand the test of time. Usually, names based on intent or usage are more robust and stand this test. Consider a component that displays mock content while waiting for the actual content to load. It might be more ideally named Placeholder opposed to Shimmer, even though most implementations appears to flash or shimmer. When the design changes and these components no longer shimmer, the name will become invalid and not make sense.