Open-UI: Maintain an open standard for UI and promote its adherence and adoption

Original Article ↗ Hacker News Discussion ↗

Need for Better Native Controls & Why Frameworks Dominate

  • Many support Open UI because browsers lack rich, modern controls (multi-select, searchable selects, good date/time pickers, autofill, rich text, etc.).
  • Today’s “controls” are often div+JS constructions: duplicated effort, poor accessibility, heavy JS, SEO issues, and inconsistent behavior.
  • Browsers largely stopped iterating on form controls; developers turned to frameworks that reinvent them.
  • People want powerful native controls with full accessibility and events, plus a simple, robust way to skin them with CSS.

Standardization vs Business Differentiation

  • One view: no real tension; standards consolidate basic UX primitives while businesses differentiate via content, workflows, and branding.
  • Another: visual differentiation and design departments often drive custom UI, sometimes misaligned with business value and incentives.
  • Several argue component-level visual differentiation adds little value; users benefit from familiar, standardized controls.
  • Good CSS hooks into standard components is seen as the pragmatic middle ground.

What Open UI Actually Aims to Do

  • The website’s purpose statement is seen as clearer than the GitHub text: standardize how to style and extend built-in controls.
  • Graduated proposals include popover, popover=hint, invoker commands, exclusive accordions, and a customizable <select>.
  • Some of these have already shipped (partly or experimentally) in Chromium and other browsers.
  • Some praise this as tractable, incremental work that encodes common patterns rather than inventing new ones.

Critiques of the Project’s Presentation & Process

  • Multiple commenters find the docs hard to navigate, with too much prose and too few inline examples, mockups, or live demos.
  • Graduated proposal pages often link out to examples that change or break over time.
  • There’s concern this feels like 1990s-style committee work that may lag fast-moving UI trends.
  • Name collision with “OpenUI5” adds minor confusion.

Accessibility, Validation, and User Control

  • Strong agreement that standardized controls help accessibility; current div-based widgets often fail here.
  • Discussion around HTML5 form validation: it exists, but built-in error UI is weak and hard to style.
  • Proposal for a semantic <validation> element per field, with multiple messages and better styling, vs today’s attributes and JS workarounds.
  • Some emphasize that standards also empower users via user stylesheets to restyle common controls once, if everything is native.

Browser Power & Ecosystem Concerns

  • Some see this work as a path away from OS-specific walled gardens and big-tech libraries toward a richer, open web.
  • Others note that the same big browser vendors must implement these standards, and Chrome is already “pulling ahead” with experimental features.
  • There’s worry about Google strong-arming standards and the long-term maintainability of a rapidly evolving, Chrome-led platform.

UI/UX Philosophy & Alternatives

  • Nostalgia for older, more “physical” UIs (pre-flat design) with clear affordances: obvious buttons, fields, and boundaries.
  • Complaints that modern flat/brand-driven UI sacrifices usability and the “principle of least surprise.”
  • Some suggest focusing on minimal APIs and letting ecosystems evolve de facto (like TypeScript), others imagine future AI/server‑driven UIs and UI protocols where clients generate personalized interfaces.