Open-UI: Maintain an open standard for UI and promote its adherence and adoption
105 comments
·March 9, 2025gyomu
madeofpalk
Customisable select I believe is the first to come out of it.
troupo
The first ones are Exclusive Accordion, Invoker Commmands, Popover. See graduated proposals at https://open-ui.org/
extra88
Customizable selects will be the first that adds a new element, rather than new attribute behaviors or new attributes. Those have still been significant, of course.
AyyEye
Hopefully the user has the same freedoms to style things how they would like.
dartos
Most browsers let you extend a page’s css (at least via extensions)
I don’t think this would be immune to that.
slowmovintarget
Until Google realizes you're using the capability to hide advertising and disables the feature to create a "trusted client" (trusted by Google to render their ads faithfully). They've pitched the idea before as a way to force users into Chrome from the server-side.
I'll go back to shouting at clouds now... Sorry.
Krssst
Some pages seem to randomize element IDs to prevent adblockers from doing their job; randomizing CSS class names wouldn't be out of the ordinary.
nemomarx
if anything a standard element is easier to style on your end than everyone using a custom one right?
nartho
Not really, because for a native element you're dependent of their APIs. For example the color picker will only use the system color picker, a lot of other native elements are hard to style. So custom elements are often easier to style but harder to maintain and usually bad for accessibility.
vlad-roundabout
Yes, one can style them with a userstyle as always.
test6554
We have <input> and <label for=""> elements, but what about <validation for="" condition="" message=""> elements?
Condition could be a wide range of possible built-in validation functions or a custom regex or js function.
Instead of adding all these validation attributes to <input> elements you could have zero or more <validation> elements, each with their own message.
The message could automatically appear when its conditions fail. Unless you call preventDefault() inside an "invalid" event handler. The invalid event could have a list of all "validations" for that element and you could check their status via js, disarm/ignore them individually, or get their messages etc.
blacksmith_tb
Don't we already have that basically, with HTML5 form validation[1]? Often just using the pattern attribute is enough to make sure you don't get a phone number in your email field etc.
1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
extra88
Yes, but it's user agent UI which is not really good in any of them.
Good error messaging is important and having styleable semantic elements would be helpful. It's tricky because you often need more than one error message per input, not just "required" but too big, too small, wrong format, etc.
jefftk
A clearer way to understand this project is to look at their graduated proposals:
* https://open-ui.org/components/popover-hint.research.explain...
* https://open-ui.org/components/popover.research.explainer/
* https://open-ui.org/components/invokers.explainer/
* https://open-ui.org/components/accordion.explainer/
The goal is to take common web UI patterns that are good UI but require fiddly custom JS today, and get them standardized and into browsers.
yanokwa
Some of these are from 2023. Have any of their graduated proposals shipped into a browser? I'm trying to get a sense of their visible wins so far.
itishappy
Exclusive Accordion
https://caniuse.com/mdn-html_elements_details_name
Invoker Commands
https://caniuse.com/mdn-html_elements_button_commandfor
Popover API
https://caniuse.com/mdn-api_htmlelement_popover
Popover=hint
merb
Isn’t popover kinda useless without a position api of the popover element? Most of the time you want to create a ‚better‘ title. But the hard part is not something like the popover it‘s the positioning (can’t do middle at the end of screen even if the others are middle since it would cut stuff or add temporary scrollbars usw.?)
Edit: https://developer.chrome.com/blog/anchor-positioning-api?hl=... this one
echelon
Chrome pulling ahead of everyone else.
It's kind of scary that Chrome is so far ahead in web standards. It's almost as if web standards are designed to give Chrome the edge.
jadbox
CommandFor just made it's way into Chrome
helloguillecl
I highly support this initiative.
One of the many reasons of why frameworks like React are used so extensively is because they provide a bridge for the lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs.
Now what we see around the web as "controls" are just a group of <div>s with hidden JS behaviour, lacking both accessibility and deeper integration. With hundreds, if not thousands, of implementations for things like calendar pickers, search selectors, etc.
We need better native controls for the web.
sumtechguy
> lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs
It was about the spot where CSS popped up then everyone decided native controls was not useful. Every framework since then has basically reinvented them. They had to as the browsers and standards didnt help. Plus the fact that for awhile the junk would just not render correctly at all or weird between the different browsers.
> We need better native controls for the web.
The reality is people want all of these controls with a nice simple way to skin them. But the browsers made it very 'interesting' to do. There is no real reason at this point other than 'i just want to' for these controls being recreated yet again (and they will be with the next framework).
nicoburns
For some controls (I have in mind <select> and date pickers) there is also a lot of functionality missing from the built-in ones.
sumtechguy
Totally. It is like the browser venders just kinda stopped iterating on them. When the reality is people just want the controls and the ability to skin them. Also with all of the events that all of the newer controls have.
RobotToaster
>calendar pickers
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
helloguillecl
I know this exists, but while the implementation in iOs is excellent, I see that a very awkward-looking datepicker shows up in Chrome.
Some things that one can think of as missing:
- Masking (Being able to display "Wednesday, 12th of March 2028")
- Callbacks for enabling/disabling days (for dates)
- Ranges for searches.
homebrewer
Compare the native picker to e.g. one from antd:
https://ant.design/components/date-picker/
Actually, compare everything they have to native elements. If the project can afford it (in terms of bundle size, etc — it's fine for intranet), I don't even bother with native controls anymore.
neogodless
I'm on a sub-optimal connection, so the Ant Design one took me about a minute to be responsive, while the native one worked in seconds.
I also am confused by this Ant demo page. Is every single date item supposed to be selected in a different element?
In this comparison, I vastly preferred the native date picker over the Ant ones. But I am probably misunderstanding the demo page. Or maybe it's just giving you "too many" options? I just need to pick a date and this seems like overkill, at best.
Y-bar
I really like my native pickers and UI compared to those examples. I can start with the fact that those are not usable on iOS 18, and they took almost a minute to load.
spartanatreyu
This goes back to the jQuery and MooTools days, back when Microsoft was holding back web standards. Then when the web started pushing forwards again, some developers didn't want to learn new things and went out of their way to teach new developers not to learn the standards.
That's how we ended up with developers who reach for frameworks instead of just using a simple html element or attribute.
Now we have an entire industry of bootstapping con-artists who are just teaching people to just search for a react thing that does what you want and if that doesn't work use an LLM
They're not actually being taught how to program.
---
Now it's true that some commonly requested features (e.g. date pickers) don't have what everyone needs. But most people also don't realise that a date picker is one of those few specific features where everyone wants it to do things differently. Even when you think you want what everyone else wants, you'll eventually hit a corner case where you realise you need one extra thing changed. There's no way to get everything right in a standard so you'll need to create your own or reach for a 3rd-party implementation.
But just because you may want to use non-standard code for a date picker, doesn't mean you shouldn't learn about (and use) things like <dialog>, <details>, <hgroup>, <menu>, <slot>, etc...
What we'll probably end up with in a few years is the generic standard datepicker, but it'll become extensible, so you can add/remove alter that one extra thing you need. (kind of like <select>'s new ::picker psuedoelement)
osullivj
Standards consolidate. Business differentiates. How will openui resolve that fundamental tension?
madeofpalk
I just rebuilt a custom Select/Combobox component in react for a Business, and I promise you I had no intention of differentiating. I wish I could have used more native browser behaviour.
brookst
Too reductive.
Businesses differentiate to create revenue. Standardization and commoditization are important strategies as well. “Commoditize your complementary goods” and all that.
A web design shop may want to visually differentiate and therefore not use openui. But a restaurant that just wants to have a simple website probably doesn’t want either 1) a crappy looking website, or 2) to invest heavily in web design
pembrook
Allowing for nuanced CSS selectors on each part of these components would get you 90% of the way toward resolving that tension.
rapnie
Yes, a la the old and famous CSS Zen Garden [0].
viraptor
Businesses differentiate when there's a good reason or no common solution. Nobody creates a new calendar picker or database or... "just because" but because there's no easy alternative. Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.
cruffle_duffle
> Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.
Depends on the org. Some places incentivize wheel reinvention by having rubrics that basically resolve to “if you want to level up, you need ‘org wide impact’”, which translates into “all the existing databases suck (for …reasons…) so I need to write our own”.
The company might not actually want this behavior but if the people in charge don’t see how important it is to make sure incentives align with expected behavior, the wrong behavior will always happen. So while it makes absolutely no sense to write your own database and Calendar Picker Platform (Now With a Fully Staffed Team!), unless the rubric incentivizes the right thing that is all people are gonna do.
williamdclt
There’s no tension, you’re just wording this to make it sound like there’s one.
The things that standards consolidate and the things on which business differentiate are entirely different things.
whstl
Most business just adopt something existing, we saw this with Bootstrap, then with Material UI. Now things are a bit more diverse but still.
I feel like the pressure to differentiate is coming from internal design departments rather than business itself in 90% of cases. It's just people generating extra work for other people.
troupo
No one prevents businesses from using their custom implementations if they so wish. Just as nothing prevents them from doing so on literally every platform from desktop OSes to mobile OSes
esafak
Differentiation on UI components adds no value. This is the place for standardization. Users want them familiar.
smjburton
> And so, all-too-often today's web developers turn to heavy JavaScript frameworks to build the user interfaces their designers are asking for. These custom interfaces are rarely fully accessible. They slow down the page, consume power, open security vulnerabilities and exclude people.
I'm running into this issue now using React/TailwindCSS to create a modern UI for a website when I'd much rather use native/built-in UI elements, especially since these Javascript frameworks are hit-or-miss for SEO. The needs of the modern web and the tools available are very disjointed at the moment, and I hope this initiative is successful is in addressing the issue.
xp84
> Web designers demand the ability to express their project's branding across every element on the page, including all user interfaces.
Truer words never spoken. Unnecessary and arrogant, but true.
> Current form and website-level UI controls do not allow for this.
While there are more advanced controls like 'combo box with search bar' that indeed have no native HTML option, there are millions of examples out there of controls on websites that could use completely vanilla HTML controls with CSS to sufficiently trumpet The Brand™ while also being reliable, well-tested, and accessible, and "Web Designers" and frontend developers don't use those either, preferring hundreds of lines of JS to (poorly) reimplement things like `<button>`, `<input type="tel">`, etc. Because they think users need The Brand shoved in their face more than they want a UI designed for the device and environment they use.
We've even come full circle now, as you see things like the iOS horizontal switch element reimplemented in JavaScript and transplanted to the Web and deployed on desktop even though `<input type="checkbox">` has always existed and has zero usability issues.
Still - I'm all for this project, as at least in areas I control like hobby projects I'll be glad to have even more reasons not to adopt bloated "UI Libraries," but I assume the piles of <div>s and <span>s and controls that only work well on the happy path* will continue forever.
* try the less sophisticated fake `<select>` replacements, when the element happens to be at the bottom of the viewport and watch the menu pop up offscreen and force you to scroll. Even ones that do this correctly add so much code bloat just to reinvent the wheel.
bilater
I think the more critical thing is an open UI protocol.
Let me explain - imagine generative AI is good enough we can just generate a UI on the fly. Take to its extreme every user can have a personal block of UI components catered to their preferences (dark mode, blue color scheme, bigger fonts etc). Then instead of every business designing their own UI for their website they just send over the information and the UI is compiled for every user baed on their own personal set of blocks.
We would very quickly need to have some sort of standard protocol to make this work. I think that would be a way more efficient world because companies can focus on the content and not on tweaking design. And every user has a lot more control over their user experience.
Of course a lot of companies may want to control the experience themselves so maybe its not one way or the other but a good chunk of websites cna use this pattern and in time it may actually become an advantage as users expect you to follow this UI protocol.
lelandfe
Saw a talk from a dev at Amazon along these lines recently.
The general concept is called “server-driven UI” (SDUI) and they talked about experimenting with a completely AI/LLM-powered frontend. It has too many problems today for practical use (LLM FE sucks with accessibility, not to mention the overall cost!) so they instead tried a half measure.
Their FE team makes a series of generic components (“primitives”) and the AI then picks among them to “build” the FE on demand. That’s the “control the experience” thing you’re getting at.
They then (hand wave) allowed the LLM access to a customer data DB.
This unused experiment would let customers search things like “what movies will I like?” and get a cogent FE despite no engineer shipping that specifically.
jmholla
Wouldn't the ability to style the existing HTML-native elements and user stylesheets handle most of this ask? It seems that the former is a major goal of this initiative.
alzamos
Very happy to see someone else thought of this too.
I see the endgame as one in which services just expose documentation to their APIs and the AI figures out, based on your request, what to call and how to present the results to you based on pre-set preferences.
The responsibility of discoverability also would shift from the UI/UX person to the AI.
The potential obstacle here is that a lot of companies make their money from the UI/UX used to deliver their service on top of the service itself e.g by adding dark patterns, visual cues, collecting usage pattern data and showing you ads.
lacoolj
For a proposal about UI, they kinda phoned in the UI of the site.
For instance, the graph on "Component Name Matrix" - can't read any labels at the top, and hovering them doesn't give tooltip. You also can't read many of the component names themselves in their respective blocks.
pembrook
This is sorely needed and best path forward out of the OS-specific walled gardens and rent seeking of Big Tech. If building interactive applications wasn't so difficult I think we'd see a big revival of the open web.
We basically have teams independently re-creating the entire MacOS UI component suite in the browser out of various duct-taped libraries every time somebody wants to build an application. And don't even get me started on Rich text editing.
Arguing against this is like arguing against supporting images on the web in the early 90s.
darkwater
> This is sorely needed and best path forward out of the OS-specific walled gardens and rent seeking of Big Tech.
I totally agree with the sentiment but who is developing most of the browsers engines that should implement this?
troupo
And their website: https://open-ui.org/
There's a lot in terms of reference on how the menu controls are defined and used across many libraries and frameworks.
Some of these are slowly making their way into the web
vlad-roundabout
Some fruits of this project have already landed in some browsers:
* Popovers: https://open-ui.org/components/popover.research.explainer/, https://developer.mozilla.org/en-US/docs/Web/API/Popover_API
* Exclusive accordion: https://open-ui.org/components/accordion.explainer/
* New select, already in Chromium only: https://open-ui.org/components/customizableselect/
doug_durham
This feels like it's from the 1990's when grand consortiums attempted to develop common windowing systems, and object systems. These produced more paper than shipping code. UI styles are ephemeral. What is popular today is unpopular tomorrow. At best it seems like this will be chasing trends. It will deliver changes long after the change has gone out of style. I am sympathetic to the underlying issues. I've been scarred by past attempts. People should ship code. Instead of debating, develop and ship new code. If it is popular it will be picked up, and later integrated into standards.
null
andy_ppp
It’d be nice if native date, time and number pickers were good and not super weird (in most browsers anyway).
The statement of purpose on the website (https://open-ui.org) is much clearer with their actual goal than the wordy Github document:
> The purpose of the Open UI, a W3C Community Group, is to allow web developers to style and extend built-in web UI components and controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.
That'd be great. I hope they succeed.