sindresorhus/modern-normalize

🐒 Normalize browsers' default style

^{My open source work is supported by the community}

^{Special thanks to:}

Differences from normalize.css

• Smaller
• Includes only normalizations for the latest Chrome, Firefox, and Safari
• Sets box-sizing: border-box
• Improves consistency of default fonts
• Sets a more readable tab size
• Fully tested

All credit should go to normalize.css. I just removed some cruft and added some improvements. If you have questions about the source, check out the original source and this for details.

The goal of this project is to make itself obsolete.

Browser support

• Latest Chrome
• Latest Firefox
• Latest Safari

Install

$ npm install modern-normalize

Download

• Normal
• Minified

CDN

• jsdelivr
• unpkg
• cdnjs

Usage

@import 'node_modules/modern-normalize/modern-normalize.css';

or

<link rel="stylesheet" href="node_modules/modern-normalize/modern-normalize.css">

FAQ

Can you provide Sass, Less, etc, ports?

There's absolutely no reason to have separate ports for these. They are just CSS supersets and can import CSS directly.

Related

• sass-extras - Useful utilities for working with Sass

modern-normalize's Issues

Update CSS to be on par with Normalize v8.0.1

Delta: necolas/normalize.css#730

Consider a version without forcing box-sizing

Counter to the common trend, it is not always 'awesome' or 'FTW'. It wreaks havoc with expectations stemming from normal browser defaults, which makes it harder to integrate into existing properties and makes it harder to integrate anything created by third parties that are not operating off of the same opinionated principle.

It's also a total pain in the ass to selectively undo with override rules, as it's reapplied on every element. At the very least you could use box-sizing: inherit I'd think, which makes it at least somewhat easier to selectively cut this awesomely annoying behavior out?

`h1` style contradicting comment

/**
 * Correct the font size and margin on `h1` elements within `section` and
 * `article` contexts in Chrome, Firefox, and Safari.
 */

h1 {
	font-size: 2em;
	margin: 0.67em 0;
}

Noticed my h1 elements were being reduced in size unexpectedly. Is this supposed to be:

article h1,
section h1 {
	font-size: 2em;
	margin: 0.67em 0;
}

Fix `tab-size`

I would like to change the tab-size from 8 to 4. I realize it's not strictly a normalization, as all browsers use 8, but it would improve the experience for everyone, so I think it's worth an exception. 8 is just a really really bad default. It has, for example, made tab-indented code on the web unreadable (isaacs/github#170).

I propose adding the following:

:root {
	-moz-tab-size: 4;
	tab-size: 4;
}

Using :root so users can easily override it on a per-element basis.

Thoughts?

(If you 👎 please also share your thoughts on why)

<img>, and <video> display block and max-width 100%

What I'm always doing is img display block and max-width 100%. I'm sure this can only be added to a new major version.

Even if you don't added I'm curious what do you think why it should not be added or what you prefer as defaults for img tag?

Outdated `:-moz-focusring` makes form elements less accessible

The package applies an outdated inaccessible focus ring to form elements in firefox:

/**
Restore the focus styles unset by the previous rule.
*/

:-moz-focusring {
	outline: 1px dotted ButtonText;
}

This thin dotted gray line is inaccessible, outdated. Browsers have updated their default focus styles to be much more accessible, including Firefox.

Here an unstyled, focused textarea (without modern-normalize):

https://codepen.io/rickymetz/pen/ZrbXqJ

It would be fantastic if modern-normalize could undo the custom application of an inaccessible legacy Firefox focus style.

Double "monospace" font-family

Here https://github.com/sindresorhus/modern-normalize/blob/master/modern-normalize.css#L67 and here https://github.com/sindresorhus/modern-normalize/blob/master/modern-normalize.css#L99.

Is this wanted 🤔?

Provide system fonts

Are there any downsides to setting this by default?

body {
	font-family:
		'-apple-system',
		'system-ui',
		'BlinkMacSystemFont',
		'Segoe UI',
		'Roboto',
		'Helvetica Neue',
		'Arial',
		'sans-serif',
		'Apple Color Emoji',
		'Segoe UI Emoji',
		'Segoe UI Symbol';
}

Users then get good defaults but can override it with their own body selector if they want.

Alternatively, if this gets a lot of resistance, we could provide a CSS variable, so users who want it can just do:

body {
	font-family: var(--system-fonts);
}

Thoughts?

(If you 👎 please also share your thoughts on why)

Use `system-ui` in the default font stack

It was not included in the initial PR, as per this blog post, it's not yet safe to use. We need to move on soon though, as Chrome plans to deprecate the BlinkMacSystemFont font name, per #16 (comment).

Also see: primer/css#408

box-sizing: inherit

The box-sizing: border-box; fix is one of the first normalizing techniques I use when starting from scratch. But since I discovered the improvement by CSS-Tricks and Paul Irish improved the original post, this is the best modern recommendation:

/* apply a natural box layout model to all elements, but allowing components to change */
html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

So, my suggestion here is to update the style to follow that. I can do a PR if needed.

What about Safari? Edge?

Includes only normalizations for the latest Chrome and Firefox

What about Safari (macOS and iOS)? Edge?

Use of `all`, `:where()`, and `:not()` could make a better reset

See: https://github.com/elad2412/the-new-css-reset

Only show dotted underline on abbr[title] if @media (supports: hover) media query

Currently we have this:

abbr[title] {
  text-decoration: underline dotted;
}

This means that abbr tags have dotted underline even on iPhone and iPad where its impossible to see the title as browser doesn't support hover - even with a mouse connected.

I propose to change this to:

@media (hover: none) {
  abbr[title] {
    text-decoration: none;
  }
}

@media (hover: hover) {
  abbr[title] {
    text-decoration: underline dotted;
  }
}

Built-in support for CSS-inJS

See #31 (comment)

Normalise button styling

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:

Placeholder opacity in FireFox

FireFox (latest version as of posting) has a slightly lower opacity for input placeholders. See my screenshot below. You fix this with:

input::placeholder { opacity: 1; }

I suggest adding it to your normalizer.

How to revert normalized css styles to their original form?

I have a css file which, probably, the tool has been applied to. Is there a way to revert it to its original form? Does the normalize support this?

Can you provide a compressed version?

eg: modern-normalize.min.css

vs code gives warning about modern-normalize

I dont know if this is really an issue or not, but nonetheless kind of distracting warnings

Search outline style in Chrome looks weird

On all the other input types in chrome the outline is on the outside, when you get a a search type of input, and looks out of place changing to the inside, and its due to the below outline-offset rule:

/**
1. Correct the odd appearance in Chrome and Safari.
2. Correct the outline style in Safari.
*/

[type='search'] {
	-webkit-appearance: textfield; /* 1 */
	outline-offset: -2px; /* 2 */
}

Move font-family to html from body

font-family styles should be placed as high up in the hierarchy as possible.
In many projects, fonts are installed for the whole site in html or in :root

Add some tests

It could be useful for this project to stay up to date with the default values of the declarations which are normalized here within the supported browsers.

This should be possible by testing the output of window.getComputedStyle() against what is expected from each browser, and the results can be used to remove rules which are no longer needed in recent versions.

If we want to be more ambitious, it can potentially also be used to find new differences between other elements that should potentially be normalized as well.

---

IssueHunt Summary

rafaelfbs has been rewarded.

Backers (Total: $40.00)

• issuehunt ($40.00)

Submitted pull Requests

• #35 Add acceptance tests

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

---

IssueHunt has been backed by the following sponsors. Become a sponsor

Edge support?

If you want it to take off this is vital.

Differences from normalize, 'Doesn't force font-family...' is no longer valid

As of recent, Normalize.css now uses font-family: inherit; for input elements.

necolas/normalize.css@ca8a357

Don't use `-webkit-font-smoothing: antialiased` globally

https://www.zachleat.com/web/font-smooth/
http://usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/

While it can be used to manually fix some light text on dark backgrounds on Macs, it should't be used on the entire page. It often leads to overly thin text with smaller weights, such as this example:

If you look at how DirectWrite and Cocoa work on Windows and Mac native elements, they use subpixel AA on normal DPI screens, and default to greyscale on high DPI screens. The same is true with Chrome, which disable subpixel AA when the device DPR is over 2.
Twitter did a similar thing on their site:

@media screen and (-webkit-min-device-pixel-ratio: 2), screen and (min-resolution: 2dppx) {
	body {
		-moz-osx-font-smoothing: grayscale;
		-webkit-font-smoothing: antialiased;
	}
}

Add `-webkit-overflow-scrolling: touch`?

when you have something like overflow: auto;, on desktop browsers and Android the scroll is natural. Only on iOS it stops scrolling immediately when you release your finger. According to mdn, -webkit-overflow-scrolling is not standard so I feel like this is a missing default feature on iOS.

Improvements

Hello,
First of all, love this project!

I have a couple of personal suggestions tough:

• Maybe it is an idea to add an pre compiled minified version.
• Maybe a scss/less version.
• Add to common cdn providers (don't know it this is easy).
• Maybe for the people that live under a stone add it to bower.

Add comparison table section

minireset.css is another solid alternative to normalize. I think you should consider adding a section that explains why users choose this one over minireset.

We should add a comparison table to README to explain the differences over other projects, such as minireset.css, reboot.css and such.

Normalize HR tag

Suggestion:

hr {
border: 0;
margin: 0;
}

Browser support?

Are any versions of IE supported or just Edge?

Fix the browsers!

The goal of this project is to make itself obsolete. We should try to get browsers to fix their own styles so we don't have to work around them indefinitely.

If you want to help out:

• Pick a style in modern-normalize.css
• Go to the relevant browser issue trackers (Chrome, Firefox, Safari), search for an existing issue, and if none, report it (Ensure you follow the guidelines for reporting).
• Comment here with a link to the issue so we can track it, even if it's an existing issue.

`font-variation-settings` is not inherited for button, input, etc. when using variable fonts

Should using font: inherit be appropriate so that font-variation-settings is inherited by button, input, etc. if the font is variable?

body {
    font-family: "Recursive", sans-serif;
    font-variation-settings: "CASL" 1, "CRSV" 1, "slnt" var(--recursive-slant, 0), "MONO" var(--recursive-mono, 0);
}

button,
input,
optgroup,
select,
textarea {
-       font-family: inherit; /* 1 */
+       font: inherit; /* 1 */
	font-size: 100%; /* 1 */
	line-height: 1.15; /* 1 */
	margin: 0; /* 2 */
}

Remove parentheses surrounding links

The IDE (Netbeans 21) and some text editors that I am using include the closing parentheses in the url of the links.

2. Correct the inheritance ... (https://bugzilla.mozilla.org/show_bug.cgi?id=190655)

Solutions:

• Adding a space

• Removing the parentheses (Seems better)

  2. Correct the inheritance ... https://bugzilla.mozilla.org/show_bug.cgi?id=190655

Why there are two properties of body?

Line: 46
Line: 54

Remove more outdated styles

I've already removed a lot of outdated styles (c2e7aa3 b52144d), but I'm sure there are more things that are fixed in browsers by now. We should go through the styles and check whether they're still valid in latest Chrome and Firefox.

More accessible line height

Hey,
first of all, nice project.

I am just wonder why you set the line-height to 115% (https://github.com/sindresorhus/modern-normalize/blob/master/modern-normalize.css#L25)? Is it because the default leading for most browsers is between 110% to 120%?

The line height typically recommended in typography is 120–145%. Do you have a special reason? Otherwise I would recommend something like 130%, because it still looks nice, but greater leading is actually a good practise for accessibility. You could even go all the way up to 150% which is the recommended leading by the W3C accessibility guidelines.

I would think if we want to normalize, we could also try to normalize not just to the defaults, but also a little bit in the direction of an overall accessible web. Looking forward to your thoughts. 👋

heading and paragraph margin top

Would it be worth setting all h1 and p etc. tags to have 0 margin on the top?

By default Chrome sets "margin-block-start: 0.67em;" on to heading elements and "margin-block-start: 1em;" on to p.

I find it pretty useless as the margin top collapses away if the element is preceded by another heading or paragraph element. But also the first heading or paragraph that you add to any container that has padding ends up too far away from the top.

For context, the popular (yet older) "normalize.css" does not get rid of the margin top, but Bootstrap's "reboot" does get rid of it.

1.1.0 is not available on cdnjs.com

There is no version 1.1.0 on https://cdnjs.com/libraries/modern-normalize.

Form margin bottom in chrome

I was using Tailwind CSS and was wondering why my search form styles were messed up. Turns out chrome has a margin-block-end on form elements by default, and Tailwind's preflight (including modern normalize) doesn't set these margins to 0.

Fix Logo (transform text to shapes)

The logo has render problems, as least on Firefox:

While using SVG for a logo is great, when (or before) exporting, all text should be transformed to shapes so that the rendering is the same on each browser/viewer and don't depend on the text rendering machine.

What is this `ButtonText` keyword?

Reading through the code and I stumble upon:
https://github.com/sindresorhus/modern-normalize/blob/master/modern-normalize.css#L209

Never seen this keyword before... did a search in Issues and didn't see anyone else asking, nor did I find any useful google results.

Would love to read a bit of info on this 😄 ... perhaps its even worth adding to the comment of this style block to inform consumers what this keyword is all about.

Thanks for another excellent contribution. Have followed your work for a long time - forever awesome ✊

Accessibility fix: Allow iOS browsers to auto-scale fonts based on user preference

Please add font:-apple-system-body to the HTML element CSS to allow iOS devices to auto-scale font sizes based on user preference set in Accessibility > Display & Text size.

Consider preventing overflow of replaced elements

In the unreleased modern-base stylesheet, there are rules to normalize the behavior of replaced elements like img, video. svg, iframe, canvas and audio. According to the related issue of normalize.css, one of the reasons behind not adopting these rules is that it can "trigger certain bugs in IE 8", which modern-normalize doesn't support.

On the other hand, I would be interested in use-cases where applying max-width: 100% causes undesired behavior for replaced elements.

Set `border-style` for `<hr>` elements

By default, a <hr> element is styled with border-style: inset; which makes it turn out like this:

By adding border-style: solid; we can make the line act like users would expect it to.