Remix.run Logo
▲ fodkodrasz 4 hours ago

Wow even more fancy border styles! Infinite complexity for useless eyecandy. Date pickers are still barely working, last time i needed to build a touch optimized interface (gloves, industrial setting) with date picker, time picker, and numeric up/down style input fields it needed custom components and js...

But who needs these, when we can have bezel and whatnot...

Who needs ways to reliably trigger the display of the touch platform-native keyboard, to be notified if it is displayed and to move the input field in view so it is not obscured by the keyboard?

This is why the web is a terrible platform compared to Windows Forms for getting stuff done. Because those making the standards only work on creating gimmicks.

▲user43928 9 minutes ago | parent | next [-]

It's probably easier to standardize small CSS utils than it is for a date picker.

What would the API even look like?

One could want to select a single date, multiple dates, a date range, multiple date ranges.

Perhaps some dates should be disabled, but should they just be greyed out or should there be a message when the user tries to select them, and if so, how can it be provided?

Then there are questions about different calendars and locales.

Perhaps third-party date picker libraries are more appropriate here than trying to address this in standards.

▲btown 2 hours ago | parent | prev | next [-]

One small glimmer of hope is that customizable selects are indeed being worked on: see https://open-ui.org/components/customizable-select.explainer... and the broader work of the Open UI group at W3C.

I'd love to see this level of customization come to date and datetime-local popups, finding a meaningful path that preserves compatibility with the design languages of various platforms. If and when that happens, it will be because of the work of standardization working groups like Open UI and Interop.

▲hollowturtle 2 hours ago | parent | prev | next [-]

> Because those making the standards only work on creating gimmicks.

Totally agree, but afaik we are a very small minority. My tinfoil hat theory is that all of this is intentional to keep monopolies and making it impossible to compete in the browser space

▲jorisw 2 hours ago | parent [-]

A completely non-sensical non-sequitur. What are you even trying to say?

What does one (CSS tech) even have to do with the other (competition in the 'browser space')?

▲tomaskafka 2 hours ago | parent | next [-]

https://news.ycombinator.com/item?id=50177605

And I believe the OP is right. Keep people busy working with changes that don’t move the needle, each of the three large platforms wants to lock in the serious use cases into their native apps.

▲nkrisc 2 hours ago | parent | prev | next [-]

If web was as good as iOS native, for example, Apple wouldn’t get their cut.

▲jorisw 2 hours ago | parent [-]

What does that mean as related to 'competition in the browser space' ?

▲KPGv2 22 minutes ago | parent [-]

Apple has a browser. Apple sits on the CSS steering committee.

The assertion is that the major browser owners (Apple, Microsoft, Google, Mozilla) don't want competition, so they keep CSS complicated.

All four of these companies are members of the CSS Working Group. So the ability to do this is within their power.

▲oblio 2 hours ago | parent | prev [-]

This is a known consequence of standards bodies: they get infested by vested corporate interests who generally, in the best case scenario, want the standard to include their entire pre existing implementation. In the worst one they just filibuster and veto proposals until they can't.

This is a phenomenon that dates back to IBM doing this in the 60s-70s-80s.

▲silvestrov an hour ago | parent | prev | next [-]

date pickers are something that quickly gets overly complex and site specific.

They are only simple when you have no restrictions on which dates that can be selected.

But a date picker for a hotel, airplane travel, restaurant, ... might have to show some days as disabled or some days that are "cheap offer" dates.

To this add anything that needs to select an interval, like an airplane return ticket.

▲Narretz a few seconds ago | parent | next [-]

that's true. But even for some of the easiest cases some browsers don't support them. input[type=month] for example still has no custom UI in Firefox or Safari. And Chrome has had one for 14 years!

▲xnorswap an hour ago | parent | prev | next [-]

And then there's the nightmare of any interval that runs over daylight savings boundaries, and what that really means if you want not just a date-picker but date/time picker.

▲troupo 41 minutes ago | parent | prev [-]

> date pickers are something that quickly gets overly complex and site specific.

I'd settle for a browser specific picker that works in 80-90% of use cases. Instead it took browser several years after introudcing type=date to make a datepicker that is actually usable, and not a throwaway tiny design cooked up by an underpaid intern

▲jorisw 2 hours ago | parent | prev | next [-]

> Windows Forms

Rage bait, don't engage

▲4b11b4 4 hours ago | parent | prev [-]

Ignorance and generally a hater position

▲fodkodrasz 4 hours ago | parent [-]

Yes, web people don't know about the outside word, and generally hate it, and its usecases.