Normalize.css: On the "Opinionated rules"

[ahmadalfy]

I understand that Normalize isn't a classical CSS Reset but removing those that you call _opinionated rules_ is harsh. It's 2017 everybody is setting their box sizing to border-box. Leaving the body margin? How many websites don't have this set to zero?

For me Normalize is considered a reset for the non useful stuff like the body margin and a way to make the different browsers behave consistently. I don't really like the new update and I am sure that there are a lot who disagree with it.

Currently the stuff that I could spot was:

• removing box-sizing setting to border-box
• removing setting the body margin to 0
• removing setting the font family to sans-serif

I wonder if you can share with us a more detailed list of the removed features. For now I think I am sticking the projects I am working on to version 5.0 and I am sure that the frameworks that depends on Normalize will do the same.

[thierryk]

It's 2017 everybody is setting their box sizing to border-box

Nope!

Leaving the body margin?

Why not using a reset for that? I don't think Normalize should be the only styles sheet devs should include as their base.

removing setting the font family to sans-serif

If we look at Normalize as a sheet that addresses differences between User Agent styles sheets then it becomes easier for devs to understand what to expect from it.

[russmaxdesign]

Totally agree with @thierryk. The aim is to set a "level playing field" only. If normalize works well, developers should not have to override anything in the normalize file. This leaves developers free to define their own base styles - including font family, margins etc - for themselves.

[Toddses]

I know this is a little off-topic, @thierryk but do you have a preferred reset you use along with normalize?

[thierryk]

@Toddses I'm the wrong person to ask as I'm extremely picky when it comes to CSS. For example, when working at Yahoo!, I removed from Normalize all the rules I considered irrelevant to our project. We did not onboard Normalize "as-is" because we were following this approach.

For what it is worth, I think we should not have to un-style things, hence why I'm not a big fan of using the universal selector (*) in base styles sheets.

[thierryk]

Here is another reason why Normalize should not reset margin on body:

If we think "Mobile First" then margin:0 on body may not be the best way to go. I believe such styling starts to make sense on "large" viewports. In my opinion, a page that only loads Normalize should look good/same across browsers and devices—and that would not be the case if we reset the margin on body.

[ahmadalfy]

@russmaxdesign @thierryk I am starting to see your point of view now with the mobile and the body margin example. Perhaps the problem was that I was treating Normalize as a _reset_ while it is not.

[necolas]

I think the move to prioritize philosophical purity over practically in v6 has been a mistake. Removing body { margin: 0 } is baffling and inconvenient; I don't think mobile has anything to do with it.

[thierryk]

From the README:

What does [Normalize] do?

• Preserves useful defaults, unlike many CSS resets.
• Normalizes styles for a wide range of elements.
• Corrects bugs and common browser inconsistencies.
• Improves usability with subtle modifications.
• Explains what code does using detailed comments.

To which of the above points the margin reset on body belongs to?

I don't think mobile has anything to do with it.

I'd argue that preserving the default margin on body fits the "Preserves useful defaults" category.

[necolas]

Heh, are you quoting my own project back at me? Like I said, my position has always been practicality over philosophical purity. I don't think there's anything useful about a default 8px margin around the body, for example.

And FWIW, this change probably means half the internet's most used websites have to do a bunch of work when updating to v6.

[jonathantneal]

The README.md should be updated. I get that it's easy and exciting to share our opinions on the matter, but this change is based on the fact that this is neither a normalization back or a normalization forward, and there is no evidence that browsers will change this. If someone presents new evidence, I'd be willing to reconsider this rule.

To draw comparison, at this time, numerous leadership voices in the webdev community call for border-box on every element. I'm not adding that either, for the same reason listed above. Drawing the line on rules based on our opinion at this time of what preference has a greater visual impact on a page or a greater strain on the coding of a page is a philosophical task best left to libraries which leverage the normalize.css core.

[necolas]

The border-box issue is a straw man argument. I think this change (a regression, IMO) has been driven by your opinions and not practicality or developer feedback.

[leeoniya]

FWIW, i always found the old behavior of normalize to be at odds with its mission statement - and in fact with the name of the project. It should do the bare minimum to remove differences between vendor defaults. FULL STOP.

If there is sufficient agreement between vendors about the default values, then normalize should only make these defaults explicit across the remainder of non-conforming ones. The only discussion worth having is when there is significant disagreement between vendors and which vendor normalize anoints as most favorable with regard to UI/UX.

it's fully possible to have different normalization behaviors between mobile and desktop - though implementing it may be tricky since media queries only account for viewport/screen size.

[necolas]

The only discussion worth having…

Excuse me, but you don't get to tell me (or anyone else) what discussions are worth having.

The mission statement intentionally mentions "useful defaults". I think the benefits of that decision, and the pragmatic balance I took while developing normalize.css, are one of the reasons this project has been widely relied upon.

[leeoniya]

@necolas i didn't mean to offend anyone; probably should have added "just my $0.02".

there is utility in having two layers here anyways - one that makes common defaults explicit and a second one that adds the "useful defaults". normalize always had both together, and the move away from that in recent versions is the controversy here, right?

i have no particular opinion about what normalize.css (the project) should do. if anything it probably makes sense for BC to stick to the original blended model. but there is a lot of use in splitting the layers so devs can cherry pick what's "useful" to them from the second layer, while knowing that the first layer solves a known minefield cross-vendor issues.

/my $0.02

[jonathantneal]

@necolas, since you’ve re-opened the issue, let’s schedule some time to discuss this further, possibly just us, preferably at most with the folks who have contributed many thoughts to this; @thierryk and @battaglr, and whoever else you may want to bring on from the Bootstrap/H5BP teams, as they are the chief “clients” I know of.

I’d like to digest your thoughts for the day, and I’d really appreciate no hasty changes. This PR was discussed for months, and I waited for 2 weeks without changes to the PR before I brought it in. I understand as the co-creator and previous maintainer, you have the ability to completely reject any or all of the work any of us have put into it. If you’re dead set on adding back in this change, I’m just asking for your patience.

[necolas]

Just to be clear, I have no intention to make code changes or twist any arms to get changes made. I'm certain the changes you've all been debating and making have been made thoughtfully - I haven't heard anything to suggest otherwise. While the projects I work on don't use normalize.css, I have recently been on the receiving end of numerous questions/complaints within Twitter, and externally, as people upgrade to v6. Mainly about the change to body margin, and the font sizes of form elements being "broken". That's what I want to represent, briefly, as you probably don't get input from most of the library's corporate consumers until after a release (and I happen to sympathize with their complaints). Thank you :)

[adamgruber]

Would it be possible to update the documentation to show all the "opinionated" rules that were removed/changed? Would be helpful for anyone looking to move to v6 and create their own reset.

[thierryk]

Heh, are you quoting my own project back at me?

I don't think the Mission Statement is irrelevant to the discussion.

Like I said, my position has always been practicality over philosophical purity. I don't think there's anything useful about a default 8px margin around the body, for example.

For what it is worth, I prefer what you call the "philosophical" approach, but that is irrelevant.
In the early days of this discussion I proposed to modify the Mission Statement, or simply include what could be considered as "exceptions". I really don't care one way or the other, all I've been saying is that people reading the README should clearly understand what to expect from this project.

[Sparticuz]

For those asking for a list of changes: https://github.com/necolas/normalize.css/compare/5.0.0...6.0.0

[bes-internal]

Changes in version 6 for me were shocking. I'm afraid to imagine how much time it will take for me to update all the projects to it.
For me, normalize.css has always been a kind of softreset. I welcome the desire to achieve that the name reflects the content. But this should not break the backward compatibility (even when changing the major version... or at least the escape plan should be described).
I suggest to initialize normalize-optionated.css (or normalize-softreset.css) and transfer there all the rules removed from 5.0

[s-pyadyshev]

I suggest to initialize normalize-optionated.css (or normalize-softreset.css) and transfer there all the rules removed from 5.0

• 1, I'll have to do the same.

Сan you find me a design with any body margin???...

[jonathantneal]

@bes-internal, I’d be happy to collect a list of soft resets that use normalize.css and share those I’ve had a chance to code review in the README.md.

[adamgruber]

From what I can tell, there were only 5 rules that were removed. I was thinking of just putting these together in a package that would complement normalize. Or, as suggested above, maybe this package can include both opinionated and un-opinionated versions?

[jonathantneal]

@adamgruber, from experience, expect PRs for box-sizing: border-box 😄

[adamgruber]

@jonathantneal Would you mind taking a look at this: https://github.com/adamgruber/opinionate.css? The aim is just to replace the rules that were removed, not to be a brand new soft-reset.

[necolas]

Jonathan, are you completely closed to reverting several of these changes and developing the library in the spirit its principles? (i.e., not breaking upgrade paths) Or are you intent on changing those principles and requiring people to insert additional reset code when upgrading?

[bes-internal]

@necolas After some time of indignation, I once again thought everything over and realized that in a situation where all browsers have a body margin of 8px, and one 0px mission of this project make it everywhere 8px. So that novice developers do not destroy their world, in which they do not know about the default body margin.
I think the list of projects with soft resets should be described in the readme. Next to the list of breaking changes between 5.0-6.0

[klonos]

@adamgruber thanx for providing opinionate.css 👍 ...this is a very acceptable workaround for those that like to keep (or adjust) the opinionated rules. Can we please have that project referenced in the 6.0.0 README.md? ...or better add the opinionate.css file as part of this project?

[jonathantneal]

@adamgruber, I think opinionate.css looks great, and I’d like to include it in the README.md.

I love the way you’ve made it only include the offset rules, and I think I should do the same with sanitize.css. Would you like to make a PR to add it to the README.md? We can work together on the text, or I can get to it once I have some free time.

I think we could include this next to the note about breaking changes from v5 to v6, next to the note about breaking changes from v1 to v2.

[adamgruber]

@jonathantneal I can make a PR but I don't see where in README.md theres a note about breaking changes.

[jonathantneal]

Resolved via https://github.com/necolas/normalize.css/pull/670

[necolas]

I'm disappointed – but not surprised – that you've decided to double-down regardless of feedback.

[jonathantneal]

I'm disappointed – but not surprised – that you've decided to double-down regardless of feedback.

@necolas, I’m not sure I share your assessment — from the older response made by the original poster to the more recent work by Adam. I see a awesome collaborative effort.

Just to be clear, I have no intention to make code changes or twist any arms to get changes made.

You’ve done amazing stuff with this project, and I’m not sure your reasons for retiring from it, but you might be happier transferring the repository back to @jonathantneal and unsubscribing from notifications if this is causing you grief. I think what normalize.css is focused on now is invaluable to the web and now without the caveats of managing a subset of our own preferences.

[necolas]

I won't be transferring it (it has always been here). If anything, I'm considering returning as the maintainer and ensuring that backwards compatibility isn't willfully broken for the majority of the library's users.

[jonathantneal]

Good luck to you, @necolas. Please be less harsh to future contributors. Do you need help finding new maintainers?

[necolas]

I think I've been behaved reasonably as the project owner. After giving you commit access, I've been hands-off and open to essentially every change that has happened over the last 1.5 years. But the first time I provide feedback about small changes (to code that's been in normalize.css since pre-v1) that negatively effects many, large consumers of the library, it's ignored. A month ago I asked if you'd be prepared to soften your uncompromising position and that was also ignored ¯_(ツ)_/¯

[jonathantneal]

I hadn’t realized you’d ever revoked my access since we started this project together. We’re both fairly opinionated on the direction of the project, and not always in alignment. We’ve never even agreed on how much we did together before my/the first commit to normalize.css, but I share that because it often surprises others that I have been here since the beginning. Also, when you say “_it has always been here_” I do recall transferring the GitHub source of truth to your name so that it no longer said your normalize.css was a fork of mine, and that’s what I was referring to earlier.

I dropped off this project the first time for similar reasons as this — we have trouble communicating, but I have _tremendous_ respect for your vision here, Nicolas. I just came back because you asked for help, and with the help of many others contributors I hope I have succeeded. :)

If you wish to change direction, I’m happy to help you find other maintainers. However, I do not enjoy being told that I am ignoring you or that I am disappointing you and that disappointing you doesn’t surprise you. That’s not nice. This is a technical choice — I would rather promote opinionate.css and move normalize.css out of opinionated styles, and I think that is the right direction moving forward, even if normalize.css used to walk the line a bit more gray. And since you brought up that the code pre-dates v1, I trust you know that I know that because I added it to begin with.

None of this is intended to outshine the work you’ve done. Outside you and me chatting on IRC, my own contemporaries found this project to be a complete waste of time. With you, it became an industry standard. Thanks for that.

[necolas]

@jonathantneal I forked that GitHub repo 6 years ago after you used your name to commit code I wrote, didn't give me commit access, and ignored my pull requests. That you'd rather attempt to assert ownership over the project and authority over me than discuss the issue at hand (or soften your stance), tells me that you are not a suitable co-maintainer. Thanks for the recent help. Good luck to you.

More generally, the "direction" of normalize.css has been stable for ~6 years and I think there's little value is disruptive changes at this stage. If people want to develop and use alternative approaches, those can be worked on as separate projects (as normalize.css was to reset.css).