By default WebKit sets a negative default outline-offset on certain form elements:

input:focus, 
textarea:focus,
select:focus {
    outline-offset: -2px
}

And resets it to 0 for specific input types:

input[type="button"]:focus,
input[type="checkbox"]:focus,
input[type="file"]:focus,
input[type="hidden"]:focus,
input[type="image"]:focus,
input[type="radio"]:focus,
input[type="reset"]:focus,
input[type="search"]:focus,
input[type="submit"]:focus,
input[type="file"]:focus::-webkit-file-upload-button {
    outline-offset: 0
}

normalize.css sets input[type="search"] to have the appearance of a textfield so that styles can be properly controlled. However, the outline-offset is different to that for a default input.

The options are:

1. Set input[type="search"] to use outline-offset: -2px so that it matches the default text input. This has makes no difference if the appearance isn't set to textfield (so it's "safe" either way). However, the outline position still varies between text input and all the submit button types.
2. Set all input, select, textarea to use outline-offset: 0 but have the halo focus ring not wrap quite so snuggly around textarea and text inputs.

Another consideration is that if the outline-offset is left at -2px for some elements, it can look a bit odd if you use a custom focus outline.

I noticed that you set margins and paddings for fieldset so that they are consistent across browsers but you don't do the same with the actual border.

I'm sure you're aware that IE (all versions) styles the fieldset much differently from the other browsers. Specifically it's a light blue-greyish border with rounded corners (ironic isn't it), whereas the rest of the browsers do a grey square border. There are two more issues with it - the exact color of the border between the rest of the browsers is not consistent, and they all seem to have a bug with the left bottom corner of it, whereby the two lines don't actually meet.

I propose a simple style addition to the fieldset tag - border:1px solid #999

This makes the border style and color consistent across all browsers, and fixes that corner bug as well.

I have a JS modal plugin that implements a facebook-style modal window (that is, it removes the body's scrollbar to use a custom one that fits the modal window).

To achieve such effect, one has to disable the document's scrollbar using body { overflow: hidden; }. Due to normalize.css setting overflow-y: scroll; in the html tags instead of body, the alternative would be to use html { overflow: hidden; }.

Here comes the problem:

In Firefox (9.0.1 at least) setting the html tag makes the page automatically scroll to the top. I provide a small example (limiting html scrolls to the top, limit the body doesn't).

I don't know the reasoning behind using html instead of body in normalize.css. Could this be changed? Would any new issues emerge as a result of this?

Thank you

/*
 * Add display for embedded HTML5 elements
 * Addresses display not defined in IE6/7/8/9 & FF3
 */

audio[controls],
canvas,
video {
    display: inline-block;
    *display: inline;
    *zoom: 1;
}

This code won’t work in IE6 because the selector audio[controls] isn’t recognized in IE6, making the whole rule ignored.

This really isn't an issue so much as a question. Would you clarify in the README whether this is intended to be used in place of a CSS reset, or after a CSS reset?

Is this block of code correct?

 * Addresses FF3/4 setting line-height on 'input' using !important in the UA stylesheet
 */

button,
input {
    line-height: normal; /* 1 */
}

The full CSS specificity order used by FF3 is:

!important declarations, user.css, author.css, agent.css, #id, .class, element

The normalize.css rule (0, 0, 1, 0, 0, 0, 1) is overridden by the firefox rule (1, 0, 0, 1, 0, 0, 1). -- http://yfrog.com/h7fs7lp

It's possible to fix it by adding an !important declaration to normalize, but I think it just makes a firefox problem cross browser.

The lines that go body, button, input, select, textarea should be html, button, input, select, textarea.

This way styles on html will overwrite normalize.css.

Using normalize.css (through h5bp) I noticed an issue when I explicitly set a <h1> tags' margin. I'm not sure if this is within the scope of normalize.css to fix or if this is a browser bug. Anyway here is how it can be reproduced:

On normalize.css demo page you can simply enter the following css:

body > h1 { margin: 21px 0; }

It will set the margin to 21px which is exactly how big it is with the default browser setting (0.67em). Although applying this rule apparently affects other elements in the document even though the actual margin doesn't change. You can see this most effectively by toggling the above rule on and off in firebug. I've tested this in FF6, IE9, Chrome 13 and Opera 11. Only FF and IE behaves unexpectedly.

I've tried figuring out exactly what is happening, but I'm afraid it doesn't make much sense to me. I first thought that it causes other blocks to align their inline content differently. Another thought is that the rendering engine uses decimals to calculate margins internally and that setting the margin to pixels removes the partial pixels that resulted from calculating the 0.67em. It's most likely the latter.

Would this issue be something that normalize.css could attempt to.. well.. normalize?

Sadly, I haven't found a good way to normalize this myself otherwise I would've just done a fork and submitted pull request. The possible fixes I thought of has all manner of implications when it comes to zooming and allowing for relative sizing of things.

PS. Excuse my web front-end ignorance.

A recommendation from @mathias for people who may not want to edit/adapt the code in normalize.css but include it (as is) in their site or framework , and then override later in the stylesheet or in a separate stylesheet.

This isn't my preferred way to use normalize.css because one of the points of the project is to move away from having separate "CSS includes" or "black boxes".

However, it is probably inevitable that it will be used this way. If there is interest or arguments in favour of a minified version, please express it here.

Even though discussed before, I think normalize.css should include h1,h2,h3 etc normalization as <IE7 does not support font-size:inherit which will be a real problem for everyone who's using the http://clagnut.com/blog/348/#c790 technique (62.5% reset).

See also http://stackoverflow.com/questions/8264522/ie7-h1-tag-not-taking-css-style

In order to reproduce my problem , open the demo page and add these styles for testing.

<body style="font-size:62.5%">
<div style="font-size:1.2em;">
... all examples here..
</div>
</body>

You will now see that the sizes on h1,h2,h3 etc is dfferent in IE7 and other browsers.

I guess it could also be a question about normalize.css supporting resets like the 62.5% one. I hope you will, it will be harder for bigger projects to embed normalize.css unless they change everything in terms of font-sizes.

Here's the HTML4 default styles:
http://www.w3.org/TR/CSS2/sample.html

HTML5 User Agent Style Sheet and Presentation Hints:
http://www.w3.org/TR/html5/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints

Some clickable form elements, such as...

<label>
<select>
<input type="checkbox">
<input type="radio">

...and (maybe up for debate)...

<input type="file">

...are missing visual feedback that they are clickable.

Shouldn't this be added?

[hidden]  { 
    display: none; 
    visibility: hidden;
}

When putting element inside table, IE would strangely overlapping table cells.

See example: http://jsbin.com/uxuzo3/12

While working on implementing a new HTML5 default markup scheme I discovered the Firefox UA stylesheet is already/actually using the proposed any() selector to adjust the size of h1 tags nested in html5 sectioning containers (from html.css in FF 6):

h3, *:-moz-any(article, aside, nav, section) *:-moz-any(article, aside, nav, section) h1 {
    display: block;
    font-size: 1.17em;
    font-weight: bold;
    margin: 1em 0;
}

Unfortunately only Firefox is doing this. The result for richly semantic html5 markup is FF 6 h1 tags sized dramatically smaller from all other browsers (only tested Chrome and IE). I discovered it while working on an improved default markup structure for projects, especially WordPress projects. Specifically when creating a section for the main content of a page with it's own h1 and then displaying many articles within it and their own h1 (i.e. a blog index) in order to achieve a semantically appropriate html5 outline. At that level there are now 3 nested h1 section headings.

I am working around it in my tests with:

*:-moz-any(article, aside, nav, section) h1 { font-size: 2em; font-weight: bold; margin: 0.67em 0; }
*:-webkit-any(article, aside, nav, section) h1 { font-size: 2em; font-weight: bold; margin: 0.67em 0; }

I included webkit because I read somewhere they had implemented the any() selector, though at this time they aren't actually imposing styling on. But I thought I would just play on the safe side in case any() is accepted in the specs. I guess I should add -o and -ms if I'm going that far?

While I can get behind the any() selector (and would indeed like to use it for similar cases) the result of Mozilla implementing this at this juncture within the UA stylesheet seems like something your project would be interesting in knowing about.

I would send a pull request but I haven't done enough testing on my "normalization" for this. But I wanted to bring it your attention because surely I am not the only one starting to implement more semantic rich html5 pages that might be affected by the inconsistency.

Admittedly I haven't dug in too deep yet but when I read this I had mixed feelings:

"We researched the differences between default browser styles in order to precisely target only the styles that need normalizing."

Kinda made me think about UA Sniffing ... made me sad. What happens when new browser versions hit with changed default styles?

Made me also think - awesome this isn't just a sledge hammer.

I suppose because this file isn't a "black box" you just go in and make a change - but its an interesting point I would like to hear your thoughts on.

Also I should note that the reset.css files floating around the web have all needed updates since HTML5 hit the scene.

Include various embedded media elements in the demo.

This is just a thought that crossed my mind after reading this article on A List Apart:

http://www.alistapart.com/articles/a-pixel-identity-crisis/

The article discusses differences in web page rendering that arise from devices on which a physical pixel (i.e., a "hardware pixel") is not the same as a so-called "reference pixel". For example, the following CSS code is used to normalize content across a Galaxy Tab and a Kindle Fire:

@media screen and (device-pixel-ratio: 1)
    and (device-width: 1024px)
    and (max-device-height: 600px)
    and (orientation: landscape),
  screen and (device-pixel-ratio: 1)
    and (device-width: 600px)
    and (max-device-height: 1024px)
    and (orientation: portrait)

I'm wondering if this is something that could/should be incorporated into normalize.css?

This really isn't an issue so much as a question. Would you clarify in the README whether this is intended to be used in place of a CSS reset, or after a CSS reset?

In IE9 SVG elements can go beyond the outside of the svg tag. Where most browsers treat the svg tag as overflow: hidden IE9 does not.

An example of this can be seen in the reset.css from 960 at https://github.com/nathansmith/960-Grid-System/blob/master/code/css/reset.css#L197.

Is this something that should or can be incorporated here as well?

Thoughts on a semantic versioning for this project? Is v1.0.0 ready?

the default means of hiding audio elements without controls, wasn't having the desired effect in safari mobile. forcing its height to be zero made it go away proper.

in case it's of use to someone. old code:

audio:not([controls]) { display: none; }

updated:

audio:not([controls]) { display: none; height: 0; }

Why do you feel there should be only one focus outline for every visitor of a site using normalize.css?

a:focus {
    outline: thin dotted;
}

This line will successfully erase native blue focus ring available system-wide on a Mac. Besides, declaring it with a shorthand reuses color from current element, making it inconsistent throughout the site for links and form widgets or different color.

Reported by MoOx : http://dl.dropbox.com/u/14108185/Screenshots/normalize.css-search.png

input type="search" includes extra WebKit decoration on OSX. Fix by including more overrides for -webkit pseudo-elements

Webkit uses this tap color to highlight tapped form elements, links, and elements with various js events.

The current normalize.css removes the tap color, in order to solve an issue with delegated events outlined on the YUI blog. But removing the tap color entirely disables the valuable feedback that it provides when the user clicks a links or form element. I propose adding the highlight back in those cases.

The CSS would become:

input, select, textarea, button, a {-webkit-tap-highlight-color:#ccc; } /\* I think this is the right shade of gray... The opacity is not specified so that the native value will be used.. */

This still isn't perfect:

1. When one of the elements listed above (input, select, etc.) is used to handle event delegation, the problem described at YUI will come back.

2. Any element which isn't one of those excepted above won't get a tap highlight when tapped (whether it's the true target of a delegated event or was tapped directly).

But both of these problems are somewhat rare and avoidable with good HTML/JS (make clickable elements <a>s with event handlers that preventDefault and don't use an <a> as your delegation handler), so I think the above CSS is acceptable.

We don't like hacks. Why should compliant browsers load hacks to fix old IE browsers? We should load our hacks for IE using conditional comments. Then you can hack ie.css as much as you like without affecting other browsers and reducing their download.

Is there any chance of separating the IE hacks into normalizeIE,css as an option. The star and underscore hacks are easy to distinguish but you will know best what other rule belong only for IE browsers.

What is the purpose of normalise.css beyond it's function? Is it to educate or is it to be blindly used?
Do you need to include everything to suit everybody? No.
Do you need a build script? No.

Please don’t become the disaster that is HTML5 boilerplate and retain some semblance of elegance.

See: https://github.com/paulirish/html5-boilerplate/issues/263

If text-align is set on a parent element of <th> (such as <table>) , then <th> does not inherit this property in IE8/IE9.

• An elegant description of the problem
• HTML WG discussion
• My simple text-align demo: Compare this page in Gecko or Webkit and IE8/IE9.

I would recommend something like: th {text-align:inherit\0/;}
The attribute hack is for IE8/IE9 only. Borrowed from http://paulirish.com/2009/browser-specific-css-hacks/

First of all, I love the idea of this project, so thanks for making it happen.

So, I had a whole thing written up about this issue and then I realized how edge case this is...
Conditions that cause this issue for jQuery UI and Firefox (3x & 8x):
html { overflow-y:scroll; }
.container-for-dragable { position:[anything other than inherit] }

(issue discussed here: http://forum.jquery.com/topic/sortable-offset-when-element-is-dragged-and-page-scrolled-down-ff)

I think this is worth noting because the declaration "overflow-y: scroll;" does not only tell the browser (firefox in this case) to just add a vertical scrollbar, it can affect the calculation of positioned elements as well. Though it is important to make enhancements and make browsers more user friendly if possible, consideration for breaking things down the dom are also important.

"Keeps page centred [sic] in all browsers regardless of content height"
Oh, line 61, centered is spelled wrong.

Thanks again!

I love normalize.css, but the one glaring missing piece is no line-height normalization for headers and other text elements. Why is that?

If the body font-size is changed to use em units it will trigger a text-resize bug in IE6/7

http://clagnut.com/blog/348/#c790

Sounds like a good idea to move font-size:100% into the html ruleset to avoid any risk of people accidentally triggering this bug if they change or override the body font-size to use em. Patrick's comment (see link above) suggests that a further font-size declaration is required for table. I couldn't immediately reproduce the table problem, so it requires a bit more testing before making the change.

Hi Necolas,

Love the solution many thanks! Any chance of you providing it as a NuGet package so that the Visual Studio users can benefit from update notifications?

Cheers!

Hi

following code displays a second scrollbar in Chrome, Safari and Firefox. Can't say if some of my code interfers, but site is scrolling and the normalize code inserts a second scrollbar which is, despite the page size not scroll-able.

overflow-y: scroll; /* 2 */ -> Row 76

Thanks!

keep up the good work

The -ms-text-size-adjust property will be ignored where the viewport tag is present.
ref MSDN: http://msdn.microsoft.com/zh-cn/library/ff462082.aspx

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;
}

input[type="button"] { -webkit-appearance: button }

This breaks Chrome, turning this:

http://i.imgur.com/Ilrg7.jpg (Pass)

Into this:

http://i.imgur.com/QnCTb.jpg (Fail)

The offending rule is here:

https://github.com/necolas/normalize.css/blob/master/normalize.css#L343

Hi,

I went to csslint.net and figured out there were some warnings.

I invite you to check it out ;-)

Mainly I want to see a version number so I can know when things have changed ^_^

The "Option 01" selector and the textual inputs & buttons which follow it (not the textarea and image input) appear narrower (200px) than all the other sized inputs (which appear 212px wide) - see screenshot @ http://s1.postimage.org/gd1tmplwu/Normalize_CSS.png

body
button,
input,
select,
textarea {
    font-family: sans-serif;
}

Ideally, this part should be moved to another rule

textarea {
  font: inherit;
}

instead of picking a sans-serif font family. The reason is that form controls use system font for UI elements and by changing it to Arial (or Helvetica) you successfully break the native feel.

You can declare font-family: sans-serif, 1 line below for IE6/7 compatibility.

The section that adds "display: block" to the HTML5 block elements does not add it to the "menu" element.

When you have the situation in which code is put in <pre><code>...</code></pre> blocks -- a fairly common practice -- the explicitly set word-wrap: break-word on pre is problematic, as it will be inherited by the code element (in which it tends to be very undesirable).

Two options in my opinion:

• remove the explicit word-wrap: break-word on pre, or;
• add an explicit word-wrap: normal to code.

Many browsers remove top and bottom margins on nested lists (ul & ol) to make lists flow more naturally

li ol,
li ul
{
    margin: 0;
}

should be sufficient to fix this, although:

margin-bottom: 0;
margin-top: 0;

could be used instead.

Due to a bug in IE7 when giving an ordered list item width the number displayed is always '1'. (See issue here: http://thedesignspace.net/MT2archives/000687.html#.Twwpg289Us8)

Therefore I'm suggesting incorporating a change to reset all li's to 'display: list-item'

There seems to be an issue with the input fields in IE6, the fields grow as you type.

Take a look at the screenshot https://skitch.com/rodolfocaldeira/f5nyq/windows-xp-ie6.

I think the problem is with this line:

button, input { line-height: normal; *overflow: visible; }

I fixed this by targeting IE6, and rewriting the overflow property.

button, input { line-height: normal; *overflow: visible; _overflow: inherit; }

Thank you

Section heading size is smaller on firefox 4 than ie7 and chrome.

(Didn't have a good firefox 4 to show.)
Firefox 5.0 / Debian Testing (Lenny)
http://api.browsershots.org/png/original/44/443932bb84dc98aff23acaa80a7c55a0.png

MSIE 7.0 / Windows XP
http://api.browsershots.org/png/original/6a/6a22d2ce9840780fa8bcc446efb28d6b.png

Chrome 9.0.597.107 / Windows XP
http://api.browsershots.org/png/original/11/11054c923b1014da6c520880540e09ee.png

http://browsershots.org/http://necolas.github.com/normalize.css/demo.html#
I didn't look for other inconsistencies yet... or figure out which versions of Firefox. may be gecko issue?

line #356 (#3)

"Corrects inner spacing displayed oddly in IE7 without effecting normal text inputs"

should read

"Corrects inner spacing displayed oddly in IE7 without affecting normal text inputs"

I know, it is not a big problem and nobody cares about it, but I have an idea and I was curious will it work or not. :)

It works, but it uses css expressions so this is only a little experiment not a real solution. :)

http://devidens.hu/dev/20110923/normalize.html

And it's a proof that IE6 can do everything. ;)

It was already done for a:hover, a:active, please expand this to cover the input element as well (perhaps button as well).

In internet explorer annoying dotted outlines appear when pressing buttons.

The styles for button, input, select, textarea specify margin:0 but do not specify padding:0, this results in extra space around checkboxes and radio buttons in IE8/9 (haven't tested other ones). You can see a quick example of that.

This probably should be fixed, unless I'm missing a reason for why the padding should stay.