4 ms·

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 comple

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?

mwcampbell 7y ago
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.
- flyingswift 7y ago
  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
throwaway_bad 7y ago
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.
- flyingswift 7y ago
  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
com2kid 7y ago
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 https://bugs.webkit.org/show_bug.cgi?id=119175) was rather annoying.
- flyingswift 7y ago
  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.
  - com2kid 7y ago
    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.
    - yyyk 7y ago
      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).
      - 7y ago
WorldMaker 7y ago
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.

mwcampbell 7y ago

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.

flyingswift 7y ago
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

throwaway_bad 7y ago

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.

flyingswift 7y ago
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

com2kid 7y ago

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 https://bugs.webkit.org/show_bug.cgi?id=119175) was rather annoying.

flyingswift 7y ago
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.
- com2kid 7y ago
  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.
  - yyyk 7y ago
    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).
    - 7y ago

WorldMaker 7y ago

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.