Chrome, Firefox, and Opera set `vertical-align: -0.2em`. The browser
implementations aren't great. They scale badly with font size and when
the height of the element is changed. Aligning them to the baseline, as
IE does, helps make their alignment consistent with other similar
elements.
Fix the cursor style for Chrome's increment/decrement buttons on
`input[type="number"]. For certain `font-size` values of the `input`, it
causes the cursor style of the decrement button to change from `default`
to `text`.
Fix gh-283
My hypothesis is that it's more important for a user to get the focus
style they expect *within* their browser than it is to have consistent focus
styles *between* browsers. In particular, replacing Chrome's default focus
style (esp. just for links) seems presumptuous.
Component designers/developers can make the decision on when to modify
these browser defaults.
Fix gh-216
Inherit all `font` properties.
Inherit `color` for form controls. Chrome and Safari on OS X will not
inherit `color` as they heavily restrict the author-defined styles that
will be respected for that element.
Fix gh-157
Commit: 907890983e
The change caused problems with `body` background color no longer
bubbling up the the `html` element.
It also prevented you from setting `color` or `background` styles on
`html` before the normalize.css styles.
It might not be possibly to safely address – within normalize.css –
the problem that it was trying to avoid.
Fix gh-188
System color schemes (in particular, custom themes in Windows and Linux
distros) affect Firefox, IE, and Opera. Normalizing the web site/app's
root background and text color prevents these unwanted settings from
being used. Chrome doesn't apply system-level schemes to websites.
Fix gh-170
By default, browsers set `text-transform:none` on most form controls in
order to prevent `text-transform` being inherited from ancestor nodes.
However, the `button` and `select` elements are exceptions.
* Firefox and Opera do not apply `text-transform:none` to `select`.
* Chrome, Safari, and IE 8+ do not apply `text-transform:none` to
`button.
It's not suitable to set `text-transform:inherit` because all other form
elements intentionally avoid it. Safari will not honour that style for
`select`, and Chrome will only do so when the `select` element is
clicked.
Further details:
http://tjvantoll.com/2012/07/10/default-browser-handling-of-the-css-text-transform-property/
Chrome, Safari, and Firefox all adjust the margin of `h1` at several
levels of nesting within HTML5 sectioning elements. This change ensures
that the margin, like the font-size, does not vary in these contexts.
Fix gh-160
Firefox uses different `box-sizing` and `height` values to all other
browsers. Firefox doesn't currently support `box-sizing` without the
`-moz-` prefix, so we use both the vendor-prefixed and unprefixed
properties to ensure that it matches the `content-box` value of other
browsers. It also requires the `height` to be set to `0`.
Fix gh-133
The Android 4.0.* work around - `html input[type="button"]` - requires
the addition of `html` to the selector for disabled inputs, otherwise
disabled button inputs still have the `pointer` cursor.
No longer supports IE 6/7, Firefox < 4, and Safari < 5.
* Make use of `inherit` to simplify some of the rules.
* Remove a lot of padding and margin normalization, particularly for
typographic elements, because modern browsers share common base
styles.
* Add `quotes` normalization. While all target browsers support
`quotes`, they don't share a common set of quote styles. Opera and IE
use "curly" quotes whereas other browsers do not. Browsers don't
appear to set different quotes depending on the language (via the
`lang` attribute) of the content.
* Remove all list normalizations and they aren't needed anymore.
* Remove a handful of form normalizations that targetted IE 6/7 or
Firefox 3.
Make the font size for `small` not quite so small. The default value of
`smaller` doesn't scale the base font size down by the same proportion
whatever the base size. IE 6/7/8 end up rendering small text larger than
most modern browsers. Opera can render it slightly smaller than Chrome
and Firefox when the base font size is relatively large.
The previous size of `75%` was a bit too small.
This fix was first introduced to deal with Chrome < 13 destroying the
appearance of native `audio` and `video` button controls when
`-webkit-appearance` is set on `input[type="button"]`. See #20
Android 4.0.* seems to use a version of WebKit that contains this bug.
See: https://github.com/h5bp/mobile-boilerplate/issues/121
...so the fix needs to be reintroduced.
This commit reverts the following 5 commits:
49392e9df2f9572a461a79e2c16ba52691e7ab14567af2e7d6
The `:moz-placeholder` rule doesn't have the desired effect because any
subsequent rule with higher specificity will result in the Firefox bug
resurfacing. There is no way to ensure that Firefox doesn't change the
color of the placeholder text. Example: https://tinker.io/e34a2
The `:focus::webkit-input-placeholder` normalization is being removed
because the current Chrome / Safari on Lion OSX behaviour is allowed in
the spec, Firefox is set to implement the same behaviour, and other
browsers may follow suit for usability reasons.
Some browser differences like these - low importance and in flux - can
be allowed to evolve and settle before assessing whether or not they
need or merit normalization.
Correct the indentation for the WebKit placeholder focus rule and move
the placeholder rules to the bottom of the forms normalization.
Update the timestamp.
The browser-defined style for placeholder text color is overwritten by style for input elements in Firefox. Adding :-moz-placeholder style overrides that, bringing Firefox inline with other browsers.
@mathiasbynens made a test case for this @ https://tinker.io/be2f2
This change improves consistency of placeholder style between Chrome, Safari, and Firefox browsers.
A bug in iOS5 means that `audio` elements without controls are not
entirely hidden. They retain some height, as demonstrated in this test
case: http://jsbin.com/ios-audio-bug/3
The fix is to add `height: 0` to the rule.
Fix#69
Legacy browsers, including IE6/7 and Firefox 3, do not make the
new HTML5 `summary` element block-level by default. This is
contrary to the HTML5 recommendations and the behaviour of modern
browsers.
Recommend that people supporting IE6/7 do not use the `hr` element
at all. It requires far more work than just normalizing margins.
IE6/7 do not collapse margins set on `hr` with margins of pre- or
proceeding elements.
Separate the margin normalizations for `p` and `pre` from that for
`h3`. Despite sharing the same margin value, headings are
qualitatively different from these other elements. Both in terms
of customisation and debugging using browser tools, it is cleaner
to keep the margins of heading separate.
The margin of many elements in IE6/7 is set by 'pt', not relative to the root font-size. This is contrary to the HTML5 spec and all other modern browsers, including IE8+.
If people need to customize margins, they can either edit normalize.css directly or override later in the source. But at least any non-customized elements will behave consistently now.
The margin of lists in IE6/7 is set by 'pt', not relative to the root font-size. This is contrary to the HTML5 spec and other modern browsers, including IE8+.
If people need to customize the list margin, they can either edit normalize.css directly or override later in the source. But at least any non-customised lists will behave consistently now.
There are various inconsistencies surrounding headings that make
this change worth trialing. The font-size of headings in IE6/7
isn't relative to the root font-size (see #61). Modern browsers
set the `h1` font-size based on the depth of nesting in certain
HTML5 sectioning elements. This change overcomes both the issues.
At the same time, the margins are being normalized so that they
are consistent and `em`-based. If people need to customise the
heading font-size and margin, they can either edit normalize.css
directly or override later in the source. But at least any non-
customised headings will behave consistently now.
Close#41
Remove the default padding. In theory, the correct normalization
would be to add the padding to IE6/7 rather than remove it from
all browsers. However, the most common use case is going to be
for legends within unstyled fieldsets, and the presence of 2px
of horizontal padding is likely to be unexpected.
Allow text wrapping in Firefox 3. Modify the default white-space
value to allow long legends to wrap. No simple fix to allow this
in IE6/7/8.
Prevent the addition of vertical margins on nested lists without
interferred with author expectations when customising margins
directly on 'ul' or 'ol' selectors later in the stylesheet.
Left margin needs to be normalized to remove it from IE6/7.
Close#57
Inclusion of these normalizations can result in unwanted or
unexpected consequences. This is because `a:visited` has a
specificity of 0,0,1,1. Therefore, the pseudo-class has to be
included in every author link-style with a lower specificity.
This is not expected behaviour when building up link styles from
the browser defaults. Very little is lost by removing the link
color normalization.
Applying *overflow:visible to button/input causes text inputs to
grow to fit their content, even if an explicit, fixed width is
applied. It was originally included to remove excess inner
spacing on buttons and submit/reset/button-type inputs in IE6/7.
Fixing this bug in IE6 requires dropping the fix entirely because
there is no way to avoid it being applied to text inputs. If
there is a need to fix this excess spacing bug in IE6, then it
should be done using a class that is applied to the
necessary elements.
For IE7, the excess spacing fix can be moved into the ruleset
that targets button and submit/reset/button-type inputs. This
prevents text inputs from growing.
IE renders rounded corners on fieldsets by default.
All browsers - even those that use the same border value of
2px groove threedface in their UA stylesheet - have different
final rendering colors, widths, and joining of the border.
The chosen value of 1px solid #c0c0c0 takes the most common
visual border width (IE, Firefox, Opera), removes the problematic
groove width value, and takes the computed color value from Chrome.
