Normalize.css: Switching font-family to inherit on form elements would create less work

[gouch]

[In reference to [this line](https://github.com/necolas/normalize.css/blob/master/normalize.css#L257)]

I think the opinionated setting of font-family on form elements causes more work in the typical case and is outside the spirit of normalize.css

As a user of this library, the most common thing I do is set a base font for a project. Usually on body. I then appreciate that font being (weakly) inherited by every element automatically. (Weakly, meaning very easy to override in special cases). This is a simple technique to achieve consistent site appearance.

I believe Normalize does have to set something for form elements’ font-family as part of its goals since browsers do set differing default values for that property.¹ But I think the normalization should be inherit, not sans-serif.

Because inherit causes less work in the majority of cases.

If my site uses Open Sans as its base font I will probably want my form elements to use Open Sans. If not, I probably have a very specific look for form elements that I’ll have to write code for no matter what. The current rule optimizes for people who 1) Don’t want form elements to use the base font family they assigned and 2) Definitely want the form element font to be sans-serif.

Is that a big group? Outside those two conditions being met, everyone else has to write more code to override the new normalize rule.

P.S. I’ve read #591 and I want to specifically say I’m only addressing font-family and not offering an opinion on font-size or line-height.

¹ As just one example, Mac Chrome sets input[type=time] to monospace while Mac Firefox sets it to -apple-system and IE 11 sets it to Arial (fiddle)

[jonathantneal]

I agree with you, and I think others should chime in, like @battaglr

[olegcherr]

@gouch Thank you for this issue and for the good explanations. I couldn't agree more.
Everything was perfect with font:inherit (before v5.0.0). I think this is the only proper behavior.
I'm trying to prove it in my comment on the thread you mentioned: https://github.com/necolas/normalize.css/issues/591#issuecomment-263698373

[kylecesmat]

I agree that setting this value to sans-serif creates unwanted-opinions in the normalized stylesheet. Whereas before v5.0.0, these elements would inherit styles from say body, which I believe is where most developers tend to define their base font-family.

I'm finding I need to override the inputs defined in this line so that they aren't set to a system font by default.. Which shouldn't be required.

I also agree with @gouch in that while there are reasons to define it as sans-serif, I agree that:

Because inherit causes less work in the majority of cases.

[jonathantneal]

I’ve reviewed this conversation as well as the previous conversation at #591 and the followup there.

The immediate solution is to switch to font-family: inherit if we want to introduce the least amount of change.

I don’t like adding convenience styles into normalize.css — even body { margin: 0 } — because I believe this project should be about making it easier to code by resolving browser differences, and should not be about reducing the amount of CSS you will have to write. That being said, I recognize a gray area when a vendor style consistently defies developer expectations, like body { margin: 0 }, and normalize.css has a long tradition of doing handling these one offs for developers.

@olegcherr, thanks for all of your work on this issue. We started normalizing line-height because recent Chrome, Firefox, and Safari browsers interprett the lack of an explicit line-height or line-height: normal poorly (comment). I will test this again.

[battaglr]

I agree, font-family IMO should go back to inherit.

When we made this change, we were trying to eliminate the unwanted side-effects of inherit, which in the past has been the reason of many opened issues. At the time made total sense to me: inherit needed to be avoided. Now I think I was wrong, at least regarding to form elements. 😓

I don't quite agree that this is a convenience style, @jonathantneal —at least not like body { margin: 0; }. Arguments like "this causes less work" or "the most common thing to do is set a base font" are true, but the most important thing to consider is that form elements don't inherit the font-family property as mostly all other elements do. That's why, in this case, I think inherit should't cause unwanted side-effects, since this is how, after all, most elements behave.

While doing some research I really couldn't find any justification for this behaviour in the specs either, not even in the suggestions for rendering HTML documents that you can find for HTML 2, HTML 4 or HTML5.

As I said, I'm in favor of going back to inherit; but let's try to consider as many aspects as we can, so we don't end-up going back and forward with this again. 😁

[englishextra]

Gosh, I've been digging why my input font family changed after moving from v3 to v5, and yes, I vote for inherit, because giving sans-serif would be an expansion on dev's territory. The only element that I really need to assign sans-serif is select, because some time ago it appeared it is not always rendering webfonts the way intended.

[thierryk]

For what it is worth, I've always been against this approach because, to me, it goes against "normalization" which relates to UA styling—not to devs' wishes.

I think authors should understand that there should be an extra layer on top of normalize to address this kind of issue—and that's where styles like these belong.

In my opinion, nothing that goes against user's expectation should go into normalize.

[jonathantneal]

Will be resolved by https://github.com/necolas/normalize.css/pull/649

[jonathantneal]

Resolved by #649

[frankwallis]

This is the original issue which triggered the opinionated/unopinionated changes. I understand that stability of this library is paramount and why those changes have been reverted, but having form controls using a different font-family from the rest of the page does not seem 'normal'. Can this issue be reopened please?