Commit: 121c08273b
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 6+ 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 and IE 6/7 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/
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`.
Known issue: this does not normalize IE 6/7 as `hr` cannot be reliably
styled in those browsers.
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.
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
