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.
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.
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.
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.
> 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).
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.
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)
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.
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
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.
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.
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
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
Readit News
> 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.
https://developer.chrome.com/blog/rfc-customizable-select
https://github.com/whatwg/html/issues/9799
I don’t think this would be immune to that.
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.
1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
* 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.
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
https://caniuse.com/mdn-api_htmlelement_popover_hint
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.
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).
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
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.
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.
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)
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
The things that standards consolidate and the things on which business differentiate are entirely different things.
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.
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.
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.
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.
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.
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.
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.
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.
I totally agree with the sentiment but who is developing most of the browsers engines that should implement this?