Normalise button styling

[luxlogica]

One of the issues that normalize.css never addressed very well is the discrepancy in the styling of some form elements in different browsers. It would be awesome if modern-normalize could address at least the discrepancies in the <button> elements that still exist.

As an example, right now after applying modern-normalize, this is what buttons look like on Safari:

...and this is what they look like on Firefox:

[sindresorhus]

Would be awesome if you could look through the normalize.css issue tracker and see if you can find some relevant discussions about it and link them here.

[luxlogica]

Latest discussion: necolas/normalize.css#729

The main discussion seems to have taken place almost 4 years ago: necolas/normalize.css#646

In the old discussion, one of the normalize authors dismisses the whole idea of normalising form element styles, as he believes that would interfere with OS UI guidelines. He suggests perhaps using an additional normalize/reset stylesheet, as an option, just for forms. Sorry, but I strongly disagree, because:

1. Different browsers on the same platform - e.g. Safari on Mac and Firefox on Mac - display form elements in very different styles. This clearly shows that these elements don’t follow platform UI guidelines, but rather, are simply styled inconsistently by each browser as they feel like. Normalising these differences is exactly the purpose of projects like these.
2. When was the last time you saw a call-to-action button on a hero banner, which actually followed the OS UI standard guidelines? Web developers need to custom-style form elements MUCH more frequently than they need to follow arbitrary OS UI standards. Once again, the whole point of projects like these is to make the developer work easier and less buggy - and we’re coming up short big time where forms are concerned.
3. OS UI guidelines are ever-changing, and highly opinionated. If we were to style our sites according to OS UI standards, a site on the Mac would look substantially different to a site in Windows, or Linux, or Android. Again, that’s the very opposite of what projects like these aim to do - which is to provide a starting point to styling that is as stable and reliable as possible.

In any case, the last official release/update to normalize.css was well over a year ago - and the discussion on normalising form styles seems to have been closed and forgotten. I’ve cross-posted a message there, but I don’t hold any hopes of them updating it to include it. TBH, the normalize.css project is starting to feel somewhat outdated and stale, and that’s perhaps the very reason why people are looking at alternatives - like modern-normalize!

[sindresorhus]

Are you talking about the actual look of the elements or just margin/padding/sizes? Normalizing the latter could make sense here, but I don't think UI styling should be in a normalization library. It's simply too opinionated.

[luxlogica]

@sindresorhus there are currently 2 ways to setup a 'starting point' in a CSS project:

1. you start with NO SETTINGS for anything - no styles, no default, and the designer/programmer then sets everything up from scratch. That's what Meyer's reset does, and that is what you need to do if you want to "not be opinionated".
2. you start with a MINIMAL, SENSIBLE DEFAULT for everything - which, by very definition, gives some reliable, basic styling to all elements across all browsers. This is what projects like normalize.css are supposed to do.

In 'normalize.css' we already have "opinionated" styling for elements everywhere - all the typography and typesetting conventions, for example. The point is, that designers really care very little what these 'default' values are - as long as they are CONSISTENT in all browsers. The value of projects like modern-normalize is precisely this: provide CONSISTENCY. If there are elements for which we are not providing a consistent baseline, then we should address it.

Saying that providing a consistent, minimal cross-browser style for form elements is "opinionated", but setting default styling for headings (for example) isn't is inconsistent and arbitrary.

[sindresorhus]

Setting a font-size is different than completely restyling an element.

[luxlogica]

@sindresorhus not for inline text elements - and even for block elements, we also have margins, paddings, and other settings. For the designer/developer, the only difference is that the settings for these elements are consistent on all browsers, and they can rely on what modern-normalize is doing. When dealing with form elements, we're back to being "in the browser's hands"...

[nasso]

I don't know if it is related but.. on Chrome, align-items is flex-start instead of flex-stretch...