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.
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.
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.
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.
"styling on your end" means the _user_ (not the website designer/developer) deciding how controls should be styled and that's much easier if everything uses the same controls because you only need to specify it once and don't need a library to hook all possible UI frameworks that exist.
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.
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.
Right. You can use browser validation and extract the error messages with JavaScript (to style them yourself, e.g. [1]), but there’s no solution without JS yet.
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.?)
There are web standards and then there are web standards.
There are some that Chrome just scribbles on a napkin, throws them into standards committees, and immediately releases even if the napkin cannot even be read by anyone. Because this benefits one or other group inside Google. See basically all hardware APIs.
With others Chrome sometimes just barges ahead even if the final shape of the standard isn't fully agreed on. YOLO. The links above are quite telling. Many of those have the following disclaimer: "This feature is experimental. Use caution before using in production."
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).
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.
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.
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.
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.
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.
> 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.
I get where you're coming from and we all know Google as the bad example here, but looking at it industry-wide, I'm not sure it holds. Like in a lot of cases, "you're not Google" applies and the similar incentives will not be there for a large majority of companies. Software is a cost centre for almost everyone.
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.
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.
> 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.
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.
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 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.
I dunno. Seems to me the organic and natural way is for these things to evolve and then become standardized de facto like TypeScript did. I guess this is kind of just that, but formalizing it? Still seems excessive.
I like the focus on accessibility. Standards & Accessibility go hand in hand, the splintering of approaches means accessibility is always playing catchup.
It's not in the business of pushing for RFCs, but the U.S. Web Design System (USWDS) has done some really cool work here: https://designsystem.digital.gov.
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.
If the project wants no attention from developers or to bring in any new people to get involved, sure, make it as complex as possible to see what is being talked about. If it's an internal document that simply doesn't need protecting, great. However they are explicitly asking people to get involved.
The existing graduated proposals don't even have anything strictly UI-related that needs UI prototypes or screenshots, but I do agree that as docs they should probably link to some of the discussions/proposals/prototypes more prominently.
This links out to several websites to show examples in the wild. Unfortunately, this is highly dependent on sites not changing, the links are not to exactly where they need to go and the link to the pixel 7 page actually goes to pixel 8 now. One of the others goes straight into a privacy policy and never takes you to the right link unless you then close out and follow it again.
It feels like a great candidate to have something interactive with the explanation of the behaviour desired (but not standardised) and then the proposed code for the same behaviour when it's standardised.
Personally, I don't get why there are so many standards for the web platform. Can't we just provide a minumum set of APIs that developers can build their own UI on top of just like what we do for the desktop?
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
Accessibility may indeed be better in modern UIs. In every other way we have regressed. Window, macOS and Linux UIs look worse and and are less intuitive, mostly thanks to the Flat UI trend.
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
To me, the primary effort here feels less about trying to create a "new" standard, and about trying to consolidate and add more formal definitions/recommendations around fairly settled patterns.
Like, I think a lot of the design systems they are linking to as reference have many opinions about colors or typography or whatever, but this project feels more like it's just trying to better formalize the definition of components that everyone is already using.
Alternate title: Create a set of requirements for browser standards so burdensome that no small group of individuals working out of a garage can ever hope to disrupt and replace Big Tech's browsers.
Absolutely. I just tried Capacities app. I'm sure it can be very useful app, but the UI for completely clean project was already so bloated with headings and texts saying in all kind of ways basically "no data yet" that I felt so overwhelmed that I left it for another time. No feeling of separating different things, everything just thrown onto the page with so much wasted whitespace.
Maybe I'm getting old, but I miss the old days of concise and practical UIs
Right, what we need is some amount of physicality, not photorealism. We need to be able to guess the functionality just by looking at something, as opposed to clicking on everything in sight in case there is some hidden interactivity behind it.
Just a coincidence this occurred after the Justice department sold Google to sell off Chrome, right? I, for one, welcome W3C instead of big tech dictating web standards.
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.
Customisable select I believe is the first to come out of it.
https://developer.chrome.com/blog/rfc-customizable-select
https://github.com/whatwg/html/issues/9799
The first ones are Exclusive Accordion, Invoker Commmands, Popover. See graduated proposals at https://open-ui.org/
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.
Hopefully the user has the same freedoms to style things how they would like.
Most browsers let you extend a page’s css (at least via extensions)
I don’t think this would be immune to that.
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.
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.
if anything a standard element is easier to style on your end than everyone using a custom one right?
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.
"styling on your end" means the _user_ (not the website designer/developer) deciding how controls should be styled and that's much easier if everything uses the same controls because you only need to specify it once and don't need a library to hook all possible UI frameworks that exist.
Users deciding how input controls are styled? Who exactly asked for THAT?
Heard of userstyles?
Yes, one can style them with a userstyle as always.
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.
1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
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.
Right. You can use browser validation and extract the error messages with JavaScript (to style them yourself, e.g. [1]), but there’s no solution without JS yet.
[1]: https://github.com/notpushkin/evilmartians-exercise-auth/blo...
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.
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.
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
https://caniuse.com/mdn-api_htmlelement_popover_hint
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
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.
There are web standards and then there are web standards.
There are some that Chrome just scribbles on a napkin, throws them into standards committees, and immediately releases even if the napkin cannot even be read by anyone. Because this benefits one or other group inside Google. See basically all hardware APIs.
With others Chrome sometimes just barges ahead even if the final shape of the standard isn't fully agreed on. YOLO. The links above are quite telling. Many of those have the following disclaimer: "This feature is experimental. Use caution before using in production."
Yeah, it's unilateral strong arming.
Google is a horrible steward of the supposed open web. They treat it like it's their kingdom. It more or less is.
An unmaintainable mess in 10 to 20 years.
CommandFor just made it's way into Chrome
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.
> 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).
For some controls (I have in mind <select> and date pickers) there is also a lot of functionality missing from the built-in ones.
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.
>calendar pickers
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
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.
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.
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.
Better native standards could mean ant.design updates their components to use less js with the same ux. So everyone still wins.
I'm not in the most common browser and even for me, with a good connection, it took a while to load.
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.
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)
Standards consolidate. Business differentiates. How will openui resolve that fundamental tension?
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.
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
Allowing for nuanced CSS selectors on each part of these components would get you 90% of the way toward resolving that tension.
Yes, a la the old and famous CSS Zen Garden [0].
[0] https://en.wikipedia.org/wiki/CSS_Zen_Garden
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.
> 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.
I get where you're coming from and we all know Google as the bad example here, but looking at it industry-wide, I'm not sure it holds. Like in a lot of cases, "you're not Google" applies and the similar incentives will not be there for a large majority of companies. Software is a cost centre for almost everyone.
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.
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.
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
Differentiation on UI components adds no value. This is the place for standardization. Users want them familiar.
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.
Maybe an option is not being shit?
> 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.
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.
> 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.
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.
> 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?
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.
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
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/
It’d be nice if native date, time and number pickers were good and not super weird (in most browsers anyway).
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.
I dunno. Seems to me the organic and natural way is for these things to evolve and then become standardized de facto like TypeScript did. I guess this is kind of just that, but formalizing it? Still seems excessive.
I like the focus on accessibility. Standards & Accessibility go hand in hand, the splintering of approaches means accessibility is always playing catchup.
It's not in the business of pushing for RFCs, but the U.S. Web Design System (USWDS) has done some really cool work here: https://designsystem.digital.gov.
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.
> show me something early or I'll move on.
Tbh. you probably should, you are not the target audience, they aren't trying to sell you anything this isn't "for you".
If the project wants no attention from developers or to bring in any new people to get involved, sure, make it as complex as possible to see what is being talked about. If it's an internal document that simply doesn't need protecting, great. However they are explicitly asking people to get involved.
The site is better, and shows research on how and what is considered. https://open-ui.org/
That's the site I visited and saw the graduated proposals.
The existing graduated proposals don't even have anything strictly UI-related that needs UI prototypes or screenshots, but I do agree that as docs they should probably link to some of the discussions/proposals/prototypes more prominently.
Perhaps I'm misunderstanding but the first one I see is an exclusive accordion (https://open-ui.org/components/accordion.explainer/).
This links out to several websites to show examples in the wild. Unfortunately, this is highly dependent on sites not changing, the links are not to exactly where they need to go and the link to the pixel 7 page actually goes to pixel 8 now. One of the others goes straight into a privacy policy and never takes you to the right link unless you then close out and follow it again.
It links off to the spec for the details element, which itself actually has an example https://html.spec.whatwg.org/multipage/interactive-elements....
It feels like a great candidate to have something interactive with the explanation of the behaviour desired (but not standardised) and then the proposed code for the same behaviour when it's standardised.
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.
Personally, I don't get why there are so many standards for the web platform. Can't we just provide a minumum set of APIs that developers can build their own UI on top of just like what we do for the desktop?
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
After 35+ years, the standard for UI intuitiveness and beauty continues to be NeXTSTEP:
https://en.wikipedia.org/wiki/NeXTSTEP
How's NeXTSTEP for a11y?
Accessibility may indeed be better in modern UIs. In every other way we have regressed. Window, macOS and Linux UIs look worse and and are less intuitive, mostly thanks to the Flat UI trend.
Please, whatever you do, write a spec document, have some sort of machine readable schema, and publish versions.
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
A standard for UI will never work because UI is so closely tied to marketing of a product.
But the field sure needs a list of deadly sins.
OpenUI, OpenUI5. I wish people would check names before they start using it. Starts to get so confusing
Sorry, friend. I see OpenUI5, I downvote. It seems I'm not the only one.
Only the uninitiated could confuse it with literally anything else.
> I see OpenUI5, I downvote.
Why?
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
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
Is this a xkcd: Standards situation? https://xkcd.com/927/
To me, the primary effort here feels less about trying to create a "new" standard, and about trying to consolidate and add more formal definitions/recommendations around fairly settled patterns.
Like, I think a lot of the design systems they are linking to as reference have many opinions about colors or typography or whatever, but this project feels more like it's just trying to better formalize the definition of components that everyone is already using.
Alternate title: Create a set of requirements for browser standards so burdensome that no small group of individuals working out of a garage can ever hope to disrupt and replace Big Tech's browsers.
Is it just me or does the first bullet of “Scope” contradict the first bullet of “Out of Scope”?
I’m not sure what the objective is then based on the conflicting narrative.
UI Anti-patterns: Everything flat, no distinction between clickable buttons / text-entry fields / plain text.
UI patterns: Buttons with raised borders, entry fields with sunk borders, etched lines between sections and to group radio buttons, for example.
We had this right 30 years ago. "Material" (Edit: and others) ruined it.
Absolutely. I just tried Capacities app. I'm sure it can be very useful app, but the UI for completely clean project was already so bloated with headings and texts saying in all kind of ways basically "no data yet" that I felt so overwhelmed that I left it for another time. No feeling of separating different things, everything just thrown onto the page with so much wasted whitespace. Maybe I'm getting old, but I miss the old days of concise and practical UIs
Skeuomorphism https://en.wikipedia.org/wiki/Skeuomorph#Virtual_examples
I don't think it is as extreme as that.
Raised buttons maybe, but we don't look for sunk physical pages to write on, for example.
I just want a convention showing me what I can do with a UI.
We had a working UI convention, but the Arty types threw it away by putting form over function, and modern UIs are harder to use because of that.
Right, what we need is some amount of physicality, not photorealism. We need to be able to guess the functionality just by looking at something, as opposed to clicking on everything in sight in case there is some hidden interactivity behind it.
We also need to bring back the principle of least surprise. Exploring modern UIs is dangerous because irreversible actions are not clearly identified.
Apple on iOS ruined it too
Just a coincidence this occurred after the Justice department sold Google to sell off Chrome, right? I, for one, welcome W3C instead of big tech dictating web standards.
The project is at least four years old.