Open-UI: Maintain an open standard for UI and promote its adherence and adoption
51 comments
·March 9, 2025gyomu
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.
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/
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
jadbox
CommandFor just made it's way into Chrome
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.
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.
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.
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).
prisenco
This leads newer devs to "learn React" instead of learning web dev, so even after the web catches up, they still reach for React components when a simple html element would do.
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.
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.
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].
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.
esafak
Differentiation on UI components adds no value. This is the place for standardization. Users want them familiar.
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
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.
IanCal
Meant with all the love in the world:
If you want to show show things please show them. Particularly when it's something you can show with html and I'm looking at a web page! We see so many so many new proposals and things you have to show me something early or I'll move on.
My path was
GitHub. Text starting with "in the beginning". The first link is to a page maybe from 1993?
I scroll to find the webpage which is not clearly linked but under "scope of work - plan".
Website, talks about plans.
Look in the menu. Only in the third section are graduated proposals.
Open one. Nothing showing me any examples.
Someone else here says that customisable select came out of this and link to a Google page which has code, screenshots and I think a live code editor.
You can accuse me of being lazy. Sure. But this setup feels like it's putting a lot of roadblocks in the way where people who want to care about this and help will drop out.
bux93
The 'graduated proposals' for UI elements don't even have any mockups at all. Great if your UI proposals are for gopher, I guess.
The people proposing deliberately bad UI on reddit as a joke make GIFs, just saying.
troupo
The site is better, and shows research on how and what is considered. https://open-ui.org/
IanCal
That's the site I visited and saw the graduated proposals.
Nesco
Most of the usual components listed should be standard at some point. The main issue is still that the Web was thought for documents, not apps. The current mess is partially due to OS vendors not agreeing on a standard, cross platform GUI API, so it was done via the Web
upcoming-sesame
Maybe the focus should instead be to dumb down ui elements and remove all the styling noise so that LLMs can operate the UI most efficiently
hypercube33
I often feel like we peaked at UX around 2000 - both KDE and Windows 2000 were lean and mean and got the job done just fine without the web junk or widgets
desertmonad
Extending something built-in instead of adopting a bloated leaky abstraction?
Heresy!
Happy to see this and imagine this with htmx could be clean minimal and maintainable. Front end bloat is ridiculous imo
breadwinner
After 35+ years, the standard for UI intuitiveness and beauty continues to be NeXTSTEP:
gavmor
How's NeXTSTEP for a11y?
infogulch
Is this a xkcd: Standards situation? https://xkcd.com/927/
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.