I've got a version of normalize.css that removes legacy browser support. This would not affect the ability to download the existing version of normalize.css. I'm looking for:

• Feedback on how much this non-legacy version is wanted now
• Feedback on the specifics of the proposal below

Intended browser support

• Chrome
• IE 8+
• Safari 5+
• Opera (latest)
• Firefox 4+ (in practice, latest few versions)
• Mobile Safari
• Other common mobile browsers that should be catered for

In essence, dropping IE 6/7, Safari 4, and Firefox 3.x

Plan of attack

• ~~Tag existing normalize.css as 1.0.0~~
• ~~Use semantic versioning going forward~~

I'd like to avoiding modifying 1.0.0 as much as possible in the future, and plan around how I'd like to manage the project 12-24 months down the line (i.e., not with a "legacy" branch hanging around). So using tags feels simpler, and AFAIK, would still leave me the option of hotfixing version 1 if absolutely necessary.

NOTE: Please avoid comments like "IE < 8 sucks, who uses that?".

I have a search form where the parent element sets a line height to vertically centre the text in the form. The following rule brings that line height to the text inside the input in the form:

button, input, optgroup, select, textarea { font: inherit; /* 1 */ }

Perhaps this was overlooked? I don't think it's a great 'normalisation' as I don't think anyone would expect this particular aspect of the font style to come through. Perhaps we could be more specific and inherit just the font-face?

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.

What's the rationale behind html { line-height: 1.15 }? I thought it was supposed to be just the headings? And wouldn't such a drastic change warrant a major version bump?

It's time to add: font-family: -apple-system,system-ui,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,sans-serif

This solution is harmless and very useful. It is used by GitHub, Wordpress, Bootstrap, Medium, Ghost, etc.

The main reason for using "system" fonts is performance. Fonts are typically one of the largest/heaviest resources loaded on a website. If we can use a font already available on the user’s machine, we can completely eliminate the need to fetch this resource, making load times noticeably faster. The beauty of system fonts is that it matches what the current OS uses, so it can be a comfortable look.

• -apple-system targets San Francisco in Safari (on Mac OS X and iOS), and it targets Neue Helvetica and Lucida Grande on older versions of Mac OS X. It properly selects between San Francisco Text and San Francisco Display depending on the text’s size.
• system-ui represents the default UI font on a given platform.
• BlinkMacSystemFont is the equivalent for Chrome on Mac OS X.
• Segoe UI targets Windows and Windows Phone.
• Roboto targets Android and newer Chrome OS. It is deliberately listed after Segoe UI so that if you’re an Android developer on Windows and have Roboto installed, Segoe UI will be used instead.

The bottom line: It's truly the ultimate solution for any website/webapp in any OS.

More info

Can you maybe somehow normalize/fix this. This is realy bad.

<input type="text" style="width: 200px">
<textarea style="width: 200px"></textarea>

Looks great in IE, both boxes have the same length, but in Google Chrome the textarea has 2px more width ;(

Best regards

I'm considering normalizing headings in some way after all. Mainly because I caught myself out while developing a project which used HTML5 elements, because of the way modern Firefox and Chrome resize h1 (coincidently to the size I needed) when nested within sectioning elements...while other browsers do not.

It would be pretty simple, just use the existing defaults and it will override the -webkit-any() / -moz-any() rules and kill off h1 resizing in sectioning elements. But then one might as well normalize all the headings and margins too, I suppose. It's likely that every project is going to modify these styles to match the design.

Thoughts?

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

h2 {
    font-size: 1.5em;
    margin: 0.83em 0;
}

h3 {
    font-size: 1.17em;
    margin: 1em 0;
}

h4 {
    font-size: 1em;
    margin: 1.33em 0;
}

h5 {
    font-size: 0.83em;
    margin: 1.67em 0;
}

h6 {
    font-size: 0.75em;
    margin: 2.33em 0;
}

Not sure if this issue is within normalize.css' idea but nevertheless. I suggest that body gets background: white because by default, or at least in Firefox it's transparent. This means it's filled with system-default color (clWindow?) which by default is white but depends on user's theme. I was surprised when a visitor sent me a screenshot with my design filled with gray instead of white which made the page look entirely different.

At the very least, [role="button"] should be styled with cursor: pointer, but I think it would make sense to style other elements the same way, for example:

[role="button"],
button,
input,
label,
select {
    cursor: pointer;
}

If menu was considered in nomalize, then we could also add menuitemin there.

Might be worth building the normalize.css file from several parts. Perhaps web components would want to import the section of styles their component needs normalized as a base.

Is there a way to unset this opinionated rule back to each browser's default value:

/**
 * Remove the outline on focused links when they are also active or hovered
 * in all browsers (opinionated).
 */

a:active,
a:hover {
  outline-width: 0;
}

So far I haven't found a way (there is no 'auto'). If this is the case, please can we remove it?

The current display style applied to the summary element results in unwanted list-item styling for instances where the summary element is not used properly.

summary {
  display: list-item;
}

This should rather be something like details > summary:first-of-type - which matches how modern browsers are treating the element.

I'm using Microsoft Edge version 107.0.1418.56 and I'm noticing it adds a couple of margin rules to just about any text element. Here's an unstyled <h2> as an example. See how there's a little bit of top and bottom margin?

Just to double-check I opened the styles tab and yes, the "user agent stylesheet" added a couple of rules.

I'm wondering if these rules should be added to normalize. If so, I'd be happy to create a PR.

Summary IOS sets the text color of buttons in the useragent stylesheet to blue. No other browser does this, and it should follow suit. Normalize.css should set the button to inherit the color from it's parent by default, similar to how other properties are done ie. font-family. I've added a screenshots to show that in our case, we're setting the base color to black, and then IOS safari is actually overriding that.

Task Add color: inherit to the button tag to override the useragent styles applied by IOS

Hi, @necolas :wave:

First thank you for this amazing package :heart_eyes:

in your :link: blog article you referenced to the :link: normalize.css ghpage.

What is Problem? Nothing, Just, Github page deployed to .io top level domain and and not in .com so... change to

❌ https://necolas.github.com/normalize.css/ :heavy_check_mark: https://necolas.github.io/normalize.css/

When I use normalize.min.css v8.0.1 as my only css file for fairly ordinary HTML, I get different renderings for Firefox vs. Chrome.

Here are the differences:

font face (Arial vs. Times New Roman, I'm guessing), font size (possibly), and definitely overall zoom factor.

Also, both show an extra top margin, although no margin at left. I looked at elements with dev tools, and cannot find any correction by normalize for the initial top margin. When I experiment with dev tools, I find that the rule "margin-top:-1.4rem" works perfectly to remove the top margin in FF.

Normalize is a great idea, and I appreciate all your work, but I'm not seeing it working as expected on my Windows 10 Home 64 computer.