> 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.
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...
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.
I don’t think this would be immune to that.
I'll go back to shouting at clouds now... Sorry.
* 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
Edit: https://developer.chrome.com/blog/anchor-positioning-api?hl=... this one
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 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."
Google is a horrible steward of the supposed open web. They treat it like it's their kingdom. It more or less is.
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).
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)
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.
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.
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
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 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.
The things that standards consolidate and the things on which business differentiate are entirely different things.
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.
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.
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.
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.
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.
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?
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.
* 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'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.
The people proposing deliberately bad UI on reddit as a joke make GIFs, just saying.
Tbh. you probably should, you are not the target audience, they aren't trying to sell you anything this isn't "for you".
Heresy!
Happy to see this and imagine this with htmx could be clean minimal and maintainable. Front end bloat is ridiculous imo
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
Only the uninitiated could confuse it with literally anything else.
But the field sure needs a list of deadly sins.
I’m not sure what the objective is then based on the conflicting narrative.
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.
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.