Hacker News Reader

Comment by flyingswift | Hacker News Reader

Can someone explain to me why they would spend effort on this kind of thing? Other than minimalist websites like HN, I can't remember the last time I saw completely unstyled form inputs in the wild.

If every web developer is going to immediately reach for CSS/JS to style these things, who cares what the default style is?

View on HN

If I could use unstyled controls and know that most browsers would have reasonable defaults, I would. I think a lot of line-of-business developers would agree. I see an opportunity to eliminate one thing that adds bloat to web applications.

I tend to agree with you but I can also tell you that 100% of web designers will not and would rather redesign them.

Even with these 'improvements' I would not use these in a line of business app

I often do use the unstyled input for say range sliders and color pickers. Most component libraries don't include them but they are complicated enough to make you not want to reimplement them. Even if you choose another external library it will be thematically incompatible anyway so you might as well go barebones and accept the OS style.

In general, it's definitely possible to go too far with styling. Sometimes the look and feel of your app does add value but for the vast majority of apps, how your scrollbars and file pickers look doesn't ever matter.

I guess one area where I see custom styling as important is visual consistency between browsers. These updates only apply to Chromium browsers, so a sufficiently visually complicated UI might look good in Chrome, but bad in Firefox for instance.

I don't feel super strongly either way, but I think it is important to call out

A lot of native HTML controls cannot be styled, instead they are re-created in JS.

This causes problems with accessibility, and burdens the browser with unneeded JS.

On a very related note, Safari not supporting date and time inputs on MacOS, and not having full support on iPhone, is super irritating. Having to add a bunch of barely accessibility JS controls to my site because Apple refuses to implement a spec after a bug was filed 6 years ago (https://bugs.webkit.org/show_bug.cgi?id=119175) was rather annoying.

I'd argue that the correct solution then is to have better support to style native components if designers are going to do it anyway.

Additionally, it is not terribly difficult to make a custom checkbox , for instance, accessible. It may require JS and ugly DOM, but I wouldn't say it's difficult.

Date and time pickers are harder. All the platforms have a native control, and all major browsers except Safari on MacOS expose it.

That one omission means the control is basically unusable without some sort of polyfill, at which point you might as well just use the same JS implementation everywhere because why not. :/

The the drop down on select not being customizable is also famously irritating.

Nearly all browsers have a native date/time control, true. Also true - many browsers do it quite badly. So eventually I always end up using the JS solution...

e.g. There's no way (by design!) to override in CSS the browsers' date format detection - and the method differs by browser/OS combination. Some customers can't manage to configure it, so end up with the american format when they want the european format. Also more than a few native browser date controls are very underfeatured (e.g. current Edge).

Date time is a nightmare.

I am thankful for momentjs literally every day I do web development. I know it gets a lot of flack for it's bundle size, but it makes so many things easy.

Heck the native JS Date object can't even give an ISO time string in the same time zone the date object was created in. Not to mention a dozen other deficiencies.

Dealing with time had always and probably will always be painful.

And then there is China, where they use YYYY-MM-DD, but 12 hr time with an AM/PM equivalent. So close to doing it the correct way!

Ugh.

The article makes several points that a lot of this effort came out of Accessibility requirements. Microsoft is very serious about Accessibility. They can't stop a web developer from breaking Accessibility, but they certainly care if the defaults are Accessible.

Reply on news.ycombinator.com