[HN Gopher] Open-UI: Maintain an open standard for UI and promot...
___________________________________________________________________
Open-UI: Maintain an open standard for UI and promote its adherence
and adoption
Author : ksec
Score : 336 points
Date : 2025-03-09 11:53 UTC (4 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| helloguillecl wrote:
| 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.
| osullivj wrote:
| Standards consolidate. Business differentiates. How will openui
| resolve that fundamental tension?
| troupo wrote:
| 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
| madeofpalk wrote:
| 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.
| williamdclt wrote:
| 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.
| brookst wrote:
| 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
| whstl wrote:
| 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.
| pembrook wrote:
| Allowing for nuanced CSS selectors on each part of these
| components would get you 90% of the way toward resolving that
| tension.
| rapnie wrote:
| Yes, a la the old and famous CSS Zen Garden [0].
|
| [0] https://en.wikipedia.org/wiki/CSS_Zen_Garden
| esafak wrote:
| Differentiation on UI components adds no value. This is the
| place for standardization. Users want them familiar.
| viraptor wrote:
| 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 wrote:
| > 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.
| viraptor wrote:
| 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.
| sumtechguy wrote:
| > lack of modern HTML implementation of basic control elements,
| like multi-selectors, search selectors, calendar pickers, and
| autofill inputs
|
| It was about the spot where CSS popped up then everyone decided
| native controls was not useful. Every framework since then has
| basically reinvented them. They had to as the browsers and
| standards didnt help. Plus the fact that for awhile the junk
| would just not render correctly at all or weird between the
| different browsers.
|
| > We need better native controls for the web.
|
| The reality is people want all of these controls with a nice
| simple way to skin them. But the browsers made it very
| 'interesting' to do. There is no real reason at this point
| other than 'i just want to' for these controls being recreated
| yet again (and they will be with the next framework).
| nicoburns wrote:
| For some controls (I have in mind <select> and date pickers)
| there is also a lot of functionality missing from the built-
| in ones.
| sumtechguy wrote:
| Totally. It is like the browser venders just kinda stopped
| iterating on them. When the reality is people just want the
| controls and the ability to skin them. Also with all of the
| events that all of the newer controls have.
| RobotToaster wrote:
| >calendar pickers
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
| helloguillecl wrote:
| I know this exists, but while the implementation in iOs is
| excellent, I see that a very awkward-looking datepicker shows
| up in Chrome.
|
| Some things that one can think of as missing:
|
| - Masking (Being able to display "Wednesday, 12th of March
| 2028")
|
| - Callbacks for enabling/disabling days (for dates)
|
| - Ranges for searches.
| homebrewer wrote:
| Compare the native picker to e.g. one from antd:
|
| https://ant.design/components/date-picker/
|
| Actually, compare everything they have to native elements. If
| the project can afford it (in terms of bundle size, etc --
| it's fine for intranet), I don't even bother with native
| controls anymore.
| neogodless wrote:
| 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.
| spookie wrote:
| I'm not in the most common browser and even for me, with
| a good connection, it took a while to load.
| test6554 wrote:
| Better native standards could mean ant.design updates
| their components to use less js with the same ux. So
| everyone still wins.
| Y-bar wrote:
| 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.
| prisenco wrote:
| 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.
| cap11235 wrote:
| Maybe an option is not being shit?
| spartanatreyu wrote:
| 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)
| troupo wrote:
| 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
| gyomu wrote:
| 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.
| madeofpalk wrote:
| 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
| troupo wrote:
| The first ones are Exclusive Accordion, Invoker Commmands,
| Popover. See graduated proposals at https://open-ui.org/
| extra88 wrote:
| Customizable selects will be the first that adds a new
| element, rather than new attribute behaviors or new
| attributes. Those have still been significant, of course.
| AyyEye wrote:
| Hopefully the user has the same freedoms to style things how
| they would like.
| dartos wrote:
| Most browsers let you extend a page's css (at least via
| extensions)
|
| I don't think this would be immune to that.
| slowmovintarget wrote:
| 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.
| vlad-roundabout wrote:
| Yes, one can style them with a userstyle as always.
| nemomarx wrote:
| if anything a standard element is easier to style on your end
| than everyone using a custom one right?
| nartho wrote:
| 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.
| devit wrote:
| "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.
| rerdavies wrote:
| Users deciding how input controls are styled? Who exactly
| asked for THAT?
| ErikBjare wrote:
| Heard of userstyles?
| test6554 wrote:
| We have <input> and <label for=""> elements, but what about
| <validation for="" condition="" message=""> elements?
|
| Condition could be a wide range of possible built-in validation
| functions or a custom regex or js function.
|
| Instead of adding all these validation attributes to <input>
| elements you could have zero or more <validation> elements,
| each with their own message.
|
| The message could automatically appear when its conditions
| fail. Unless you call preventDefault() inside an "invalid"
| event handler. The invalid event could have a list of all
| "validations" for that element and you could check their status
| via js, disarm/ignore them individually, or get their messages
| etc.
| blacksmith_tb wrote:
| Don't we already have that basically, with HTML5 form
| validation[1]? Often just using the pattern attribute is
| enough to make sure you don't get a phone number in your
| email field etc.
|
| 1: https://developer.mozilla.org/en-
| US/docs/Learn_web_developme...
| extra88 wrote:
| 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.
| notpushkin wrote:
| 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...
| pembrook wrote:
| This is sorely needed and best path forward out of the OS-
| specific walled gardens and rent seeking of Big Tech. If building
| interactive applications wasn't so difficult I think we'd see a
| big revival of the open web.
|
| We basically have teams independently re-creating the entire
| MacOS UI component suite in the browser out of various duct-taped
| libraries every time somebody wants to build an application. And
| don't even get me started on Rich text editing.
|
| Arguing against this is like arguing against supporting images on
| the web in the early 90s.
| darkwater wrote:
| > 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?
| kittikitti wrote:
| 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.
| dfc wrote:
| The project is at least four years old.
| IanCal wrote:
| 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 wrote:
| 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 wrote:
| The site is better, and shows research on how and what is
| considered. https://open-ui.org/
| IanCal wrote:
| That's the site I visited and saw the graduated proposals.
| troupo wrote:
| 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.
| lyu07282 wrote:
| > 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".
| smjburton wrote:
| > 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.
| damnitbuilds wrote:
| 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.
| brulard wrote:
| 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
| mirkodrummer wrote:
| Apple on iOS ruined it too
| RobotToaster wrote:
| Skeuomorphism
| https://en.wikipedia.org/wiki/Skeuomorph#Virtual_examples
| damnitbuilds wrote:
| 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.
| breadwinner wrote:
| 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.
| mulmen wrote:
| We also need to bring back the principle of least
| surprise. Exploring modern UIs is _dangerous_ because
| irreversible actions are not clearly identified.
| jefftk wrote:
| 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 wrote:
| 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.
| jadbox wrote:
| CommandFor just made it's way into Chrome
| itishappy wrote:
| 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
| echelon wrote:
| 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.
| troupo wrote:
| 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. "
| echelon wrote:
| 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.
| test6554 wrote:
| An unmaintainable mess in 10 to 20 years.
| merb wrote:
| 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
| INTPenis wrote:
| 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.
| desertmonad wrote:
| 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
| upcoming-sesame wrote:
| 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 wrote:
| 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
| Nesco wrote:
| 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
| breadwinner wrote:
| After 35+ years, the standard for UI intuitiveness and beauty
| continues to be NeXTSTEP:
|
| https://en.wikipedia.org/wiki/NeXTSTEP
| gavmor wrote:
| How's NeXTSTEP for a11y?
| flowerlad wrote:
| 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.
| infogulch wrote:
| Is this a _xkcd: Standards_ situation? https://xkcd.com/927/
| bpev wrote:
| 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.
| lacoolj wrote:
| 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.
| vlad-roundabout wrote:
| Some fruits of this project have already landed in some browsers:
|
| * Popovers: https://open-
| ui.org/components/popover.research.explainer/,
| https://developer.mozilla.org/en-US/docs/Web/API/Popover_API
|
| * Exclusive accordion: https://open-
| ui.org/components/accordion.explainer/
|
| * New select, already in Chromium only: https://open-
| ui.org/components/customizableselect/
| doug_durham wrote:
| 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.
| wdb wrote:
| OpenUI, OpenUI5. I wish people would check names before they
| start using it. Starts to get so confusing
| boomskats wrote:
| 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.
| hu3 wrote:
| > I see OpenUI5, I downvote.
|
| Why?
| bilater wrote:
| I think the more critical thing is an open UI protocol.
|
| Let me explain - imagine generative AI is good enough we can just
| generate a UI on the fly. Take to its extreme every user can have
| a personal block of UI components catered to their preferences
| (dark mode, blue color scheme, bigger fonts etc). Then instead of
| every business designing their own UI for their website they just
| send over the information and the UI is compiled for every user
| baed on their own personal set of blocks.
|
| We would very quickly need to have some sort of standard protocol
| to make this work. I think that would be a way more efficient
| world because companies can focus on the content and not on
| tweaking design. And every user has a lot more control over their
| user experience.
|
| Of course a lot of companies may want to control the experience
| themselves so maybe its not one way or the other but a good chunk
| of websites cna use this pattern and in time it may actually
| become an advantage as users expect you to follow this UI
| protocol.
| lelandfe wrote:
| Saw a talk from a dev at Amazon along these lines recently.
|
| The general concept is called "server-driven UI" (SDUI) and
| they talked about experimenting with a _completely_ AI /LLM-
| powered frontend. It has too many problems today for practical
| use (LLM FE sucks with accessibility, not to mention the
| overall cost!) so they instead tried a half measure.
|
| Their FE team makes a series of generic components
| ("primitives") and the AI then picks among them to "build" the
| FE on demand. That's the "control the experience" thing you're
| getting at.
|
| They then (hand wave) allowed the LLM access to a customer data
| DB.
|
| This unused experiment would let customers search things like
| "what movies will I like?" and get a cogent FE despite no
| engineer shipping that specifically.
| jmholla wrote:
| Wouldn't the ability to style the existing HTML-native elements
| and user stylesheets handle most of this ask? It seems that the
| former is a major goal of this initiative.
| alzamos wrote:
| 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.
| reactordev wrote:
| 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.
| andy_ppp wrote:
| It'd be nice if native date, time and number pickers were good
| and not super weird (in most browsers anyway).
| skrtskrt wrote:
| 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.
| cratermoon wrote:
| 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.
| xp84 wrote:
| > 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(tm) 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.
| chenzhekl wrote:
| 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?
| exabrial wrote:
| Please, whatever you do, write a spec document, have some sort of
| machine readable schema, and publish versions.
| 90s_dev wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-13 23:02 UTC)