[helloguillecl]

I highly support this initiative.

One of the many reasons of why frameworks like React are used so extensively is because they provide a bridge for the lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs.

Now what we see around the web as "controls" are just a group of <div>s with hidden JS behaviour, lacking both accessibility and deeper integration. With hundreds, if not thousands, of implementations for things like calendar pickers, search selectors, etc.

We need better native controls for the web.

[sumtechguy]

> lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs

It was about the spot where CSS popped up then everyone decided native controls was not useful. Every framework since then has basically reinvented them. They had to as the browsers and standards didnt help. Plus the fact that for awhile the junk would just not render correctly at all or weird between the different browsers.

> We need better native controls for the web.

The reality is people want all of these controls with a nice simple way to skin them. But the browsers made it very 'interesting' to do. There is no real reason at this point other than 'i just want to' for these controls being recreated yet again (and they will be with the next framework).

[nicoburns]

For some controls (I have in mind <select> and date pickers) there is also a lot of functionality missing from the built-in ones.

[RobotToaster]

>calendar pickers

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

[helloguillecl]

I know this exists, but while the implementation in iOs is excellent, I see that a very awkward-looking datepicker shows up in Chrome.

Some things that one can think of as missing:

- Masking (Being able to display "Wednesday, 12th of March 2028")

- Callbacks for enabling/disabling days (for dates)

- Ranges for searches.

[homebrewer]

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.

[spartanatreyu]

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)

[osullivj]

Standards consolidate. Business differentiates. How will openui resolve that fundamental tension?

[madeofpalk]

I just rebuilt a custom Select/Combobox component in react for a Business, and I promise you I had no intention of differentiating. I wish I could have used more native browser behaviour.

[brookst]

Too reductive.

Businesses differentiate to create revenue. Standardization and commoditization are important strategies as well. “Commoditize your complementary goods” and all that.

A web design shop may want to visually differentiate and therefore not use openui. But a restaurant that just wants to have a simple website probably doesn’t want either 1) a crappy looking website, or 2) to invest heavily in web design

[pembrook]

Allowing for nuanced CSS selectors on each part of these components would get you 90% of the way toward resolving that tension.

[viraptor]

Businesses differentiate when there's a good reason or no common solution. Nobody creates a new calendar picker or database or... "just because" but because there's no easy alternative. Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.

[williamdclt]

There’s no tension, you’re just wording this to make it sound like there’s one.

The things that standards consolidate and the things on which business differentiate are entirely different things.

[whstl]

Most business just adopt something existing, we saw this with Bootstrap, then with Material UI. Now things are a bit more diverse but still.

I feel like the pressure to differentiate is coming from internal design departments rather than business itself in 90% of cases. It's just people generating extra work for other people.

[troupo]

No one prevents businesses from using their custom implementations if they so wish. Just as nothing prevents them from doing so on literally every platform from desktop OSes to mobile OSes

[esafak]

Differentiation on UI components adds no value. This is the place for standardization. Users want them familiar.

[prisenco]

This leads newer devs to "learn React" instead of learning web dev, so even after the web catches up, they still reach for React components when a simple html element would do.

[cap11235]

Maybe an option is not being shit?