4 ms·

I agree with this entirely. The problem boils down to managers/designers hating default. As an example, take form behaviors. Default forms work. Built-in bro

by Nadya 10y ago

I agree with this entirely. The problem boils down to managers/designers hating default. As an example, take form behaviors. Default forms work. Built-in browser verification (for supported browsers) works. You can even have it match a regex! Built into the browser! Dropdowns in browsers? Those work too! So do radio buttons and checklists! Instead, people are tasked to reinvent the wheel and create their own hacky dropdown lists because they want things sorted into groups (what is an <optgroup>?) and they want super precision over how the list ends up getting styled. As a consumer: I absolutely hate this. I love browser defaults because I can expect all forms to just work. If I hit the letter "G" in a dropdown list I know how it will function! All of this knowledge is tossed to the side unless the reimplementation tries to remain faithful to the browser defaults. I know some developers are guilty of wanting to make custom things too - but by far it is a problem with clients and management. I always have to fight against anything that would change default browser behaviors because the UX on such things is terrible 99% of the time or whatever implementation via JS is going to either take a large amount of time or be buggy as hell.

Keats 10y ago
Some defaults are pretty damn ugly though, just missing or not consistent between browsers. For example the input type date or range to only name 2. The browsers errors on html5 validation are equally ugly imo.
- Nadya 10y ago
  You can still style them differently! I was focusing on functionality. Your users are going to primarily be using a single browser (per device) and expect each device to be, at least, consistent with itself. This is an area I feel devs make the largest mistake: they want browsers to conform to one another. That means they'll break default functionality to get there! I'm of the opinion the browser should change. That allows users of the browser to adapt to the new default (because every site will then be consistent for the user!) Functionality can differ between browsers [0] and your IE users will expect the numeric input field to function like it does in IE. Not like it does in Chrome/FF/Safari. Meanwhile, your Chrome/FF/Safari people will expect it to function how it does by default in their browsers. You shouldn't override or change this functionality because it breaks user expectations. Overriding IE because it is the "odd one out" will break expectations for users using IE! It doesn't matter so much if the experience is different for each user so much as the experience is consistent for each user within their environment. [0] https://css-tricks.com/numeric-inputs-a-comparison-of-browser-defaults/ https://css-tricks.com/numeric-inputs-a-comparison-of-browse...
  - CM30 10y ago
    Well you should be able to style them differently. Problem is, outside of basic text fields, textareas and buttons (which can be styled completely through standard CSS), many form elements like select menus, sliders, radio buttons, checkboxes and others can only be styled through browser specific prefixed code, ugly hacks and the not quite official and not quite obsolete appearance property. If all these fields had nice clean ways to style them so they looked the same cross browser (even with different defaults and behaviour), then there would be less people using these giant scripts and frameworks.
tajen 10y ago
> default forms work No they don't, in my opinion. They're sensitive to XSRF attacks, a breach nicely kept open by browsers so you can embed a MailChimp form on your website and it gets posted to MailChimp. 90% times I program a form in Ajax is to use JSON content type, hence suppressing the cross-site risk. The other option is to put an encrypted token in your form, but I don't like keeping things in session. > Dropdowns work Aaaaaaand that's why design can ruin a feature. <select> work indeed excellently for 90% situations, but it repels your customer, more than using an unprotected ?clientId= in the URL. If browser used a Select2 design by default, I bet it would be used more often.
- Nadya 10y ago
  You brought up a perfect example of breaking default functionality for design! :) Here is the very first thing I tried (and is how I fill out forms) to select my State from their examples. Tab (to focus field) -> AA -> Tab The default select field? Gives me Arizona as expected. The select2 drop down? Fails to give me anything. It doesn't expect "AA" it expects "Ar" and tab doesn't set the value, so even typing "AR->Tab" doesn't give Arizona, it expects "AR -> Return". Minor - and very possibly worth the trade off for the search functionality. But I detest breaking defaults when possible, even if I disagree with a default personally.

by Nadya 10y ago

Keats 10y ago

Some defaults are pretty damn ugly though, just missing or not consistent between browsers. For example the input type date or range to only name 2. The browsers errors on html5 validation are equally ugly imo.

Nadya 10y ago
You can still style them differently! I was focusing on functionality. Your users are going to primarily be using a single browser (per device) and expect each device to be, at least, consistent with itself. This is an area I feel devs make the largest mistake: they want browsers to conform to one another. That means they'll break default functionality to get there! I'm of the opinion the browser should change. That allows users of the browser to adapt to the new default (because every site will then be consistent for the user!) Functionality can differ between browsers [0] and your IE users will expect the numeric input field to function like it does in IE. Not like it does in Chrome/FF/Safari. Meanwhile, your Chrome/FF/Safari people will expect it to function how it does by default in their browsers. You shouldn't override or change this functionality because it breaks user expectations. Overriding IE because it is the "odd one out" will break expectations for users using IE! It doesn't matter so much if the experience is different for each user so much as the experience is consistent for each user within their environment. [0] https://css-tricks.com/numeric-inputs-a-comparison-of-browser-defaults/ https://css-tricks.com/numeric-inputs-a-comparison-of-browse...
- CM30 10y ago
  Well you should be able to style them differently. Problem is, outside of basic text fields, textareas and buttons (which can be styled completely through standard CSS), many form elements like select menus, sliders, radio buttons, checkboxes and others can only be styled through browser specific prefixed code, ugly hacks and the not quite official and not quite obsolete appearance property. If all these fields had nice clean ways to style them so they looked the same cross browser (even with different defaults and behaviour), then there would be less people using these giant scripts and frameworks.

tajen 10y ago

> default forms work No they don't, in my opinion. They're sensitive to XSRF attacks, a breach nicely kept open by browsers so you can embed a MailChimp form on your website and it gets posted to MailChimp. 90% times I program a form in Ajax is to use JSON content type, hence suppressing the cross-site risk. The other option is to put an encrypted token in your form, but I don't like keeping things in session. > Dropdowns work Aaaaaaand that's why design can ruin a feature. <select> work indeed excellently for 90% situations, but it repels your customer, more than using an unprotected ?clientId= in the URL. If browser used a Select2 design by default, I bet it would be used more often.

Nadya 10y ago
You brought up a perfect example of breaking default functionality for design! :) Here is the very first thing I tried (and is how I fill out forms) to select my State from their examples. Tab (to focus field) -> AA -> Tab The default select field? Gives me Arizona as expected. The select2 drop down? Fails to give me anything. It doesn't expect "AA" it expects "Ar" and tab doesn't set the value, so even typing "AR->Tab" doesn't give Arizona, it expects "AR -> Return". Minor - and very possibly worth the trade off for the search functionality. But I detest breaking defaults when possible, even if I disagree with a default personally.