Normalize.css: Standardize font aliasing on mac os

[equinusocio]

On Mac OS, webkit and mozilla render every fonts with an extra bold aliasing

Bugzilla related issue (CLOSED): https://bugzilla.mozilla.org/show_bug.cgi?id=857142
Other references:

• http://www.dave-bond.com/blog/2009/11/fonts-too-bold-on-mac/
• https://stackoverflow.com/questions/8053389/how-to-reduce-font-weight-in-firefox-on-mac-with-css
• https://stackoverflow.com/questions/5082632/same-font-except-its-weight-seems-different-on-different-browsers
• https://css-tricks.com/forums/topic/font-appears-a-lot-bolder-on-mac-than-pc/

The solution is to add the font smoothing options (to the html {}) to prevent extra bold fonts on mac os:

html {
   ... 
   -webkit-font-smoothing: antialiased;
   -moz-osx-font-smoothing: grayscale;
}

On windows these properties are ignored. Note that will be a VISUAL breaking change if you add these rules to a project that is already developed on normalize.css.

PR https://github.com/necolas/normalize.css/pull/684

[equinusocio]

@necolas

[gouch]

I don't think you're describing this accurately. What your rules technically do is tell the browser to turn off subpixel antialiasing (a technique that improves text rendering on standard resolution LCD displays) in favor of grayscale-only antialiasing.

So _standardize_ is not the right verb here, since you're changing the default browser rendering for _every_ macOS browser to your grayscale preference. (Windows browsers also default to subpixel AA, as far I know.)

I think what you're suggesting is that the thinner grayscale AA on macOS looks closer to subpixel AA on Windows when compared side-by-side. Which may or may not be true. But what is true is that this rule would make text on a site looks _slightly off_ compared to every other site a user browses. (And compared to the text everywhere else in their browser, like menus and tabs).

This is a _*-box-sizing-border-box_ kind of change in terms of opinion and impact.

[equinusocio]

_Normalize.css makes browsers render all elements more consistently_ and in line with modern standards. It precisely targets only the styles that need normalising.

This way you can see fonts in the same way on each browser and on each display.

* -box-sizing-border-box change a normal CSS behavior that is not a "default" and that is subjective. Instead, fonts rendering should be nomalised across browsers and platforms that render fonts like shit.

[simonsmith]

this rule would make text on a site looks slightly off compared to every other site a user browses.
(And compared to the text everywhere else in their browser, like menus and tabs).

I would agree with this. It makes text harder to read. I'm not sure windows font rendering should be a goal. Quite the opposite in fact.

[equinusocio]

So it's better have a different font rendering based on the OS instead of normalise it? I can't see anymore the goal of normalize.css. If these properties can't be added, we should remove also

  line-height: 1.15;
  -ms-text-size-adjust: 100%; /* 2 */
  -webkit-text-size-adjust: 100%; /* 2 */

from the html because these rules changes the default behavior provided by the browser/OS (That are completely subjective)

[simonsmith]

Whilst it should normalise certain properties it should not be at the cost of causing a worse user experience just to be 'pure'. That is how we ran into the last issue of body having the margin reset taken away.

I don't think text-size-adjust is comparable in this example either.

[jonathantneal]

@equinusocio, I understand your position, and how you are saying this change would “normalizes” the visual experience between operating systems.

As @gouch points out, this isn’t _really_ solving the problem you are experiencing, which makes is suspect for being “hacky”. To that end, would you know know if this change is “falling forward”, meaning, would future browsers or operating systems want to render like this _without_ normalize.css in the future? An example of a “falling forward” normalization right now is abbr[title]. Finally, as a matter of philosophy, avoiding OS specific styles has been a normalize.css tradition, which is why it also stays out of things like form styling or auto-hiding the scrollbar in IE.

(ironically, @simonsmith and I agree for opposite reasons :P as I see adding font smoothing as yet another unnecessary opinionated change, like body margin, box sizing border box, etc. hehe)

[equinusocio]

Ok, but i think there are a lot of declarations that are opinionable, like line-height: 1.15; inside html. Why i should "start" with a 1.15 line-height?

Also this h1 declaration. It change the dafault font-size and margins... for all H1, not only inside a section and article like comment say..

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

Also this..firefox what see?

/**
 * Prevent the duplicate application of `bolder` by the next rule in Safari 6.
 */

b,
strong {
  font-weight: inherit;
}

/**
 * Add the correct font weight in Chrome, Edge, and Safari.
 */

b,
strong {
  font-weight: bolder;
}

And many others..

I understand your position, and how you are saying this change would “normalizes” the visual experience between operating systems.

@jonathantneal this, for me, should be the main goal of normalize.css...

I have no problem, i just wanted to explain my opinion. I have been using normalize.css since some years, but i like also this ideology:
http://jaydenseric.com/blog/forget-normalize-or-resets-lay-your-own-css-foundation

[jonathantneal]

@equinusocio, if the comment associated with the normalization uses the term “Correct” then it means it is _fixing_ something. In your example, the fix applies to “all browsers”. There should be _very few_ normalizations that affect all browsers. I’ll explain, hopefully for posterity.

AFAIK, normalize.css relies on:

1. The CSS Spec, then;
2. The HTML Spec, and then;
3. The testing results from a majority of browsers.

And it typically relies on that order. In the case of line-height: 1.15, it comes from the later two, aligning with the spec’s direction to use a “value for 'normal' between 1.0 to 1.2.” and how most browsers float around 1.15 when they *all assign a line-height of normal to the root (html).

Now, if you discovered that a majority of browsers never floated around 1.15, or if the spec never specified that styling, then it could be addressed. Exceptions to the rule are anything explicitly marked as “opinionated”.

Everything I’ve said should apply to the h1 example you also pointed out. Does this help? That’s my intention, because I have no authority over this project, but I recognize that not many people take the time, as you have, to really dig through the normalize.css source. It’s awesome you do that! Folks like you are extremely helpful. I hope you are not scared away, especially _if_ this change doesn’t make it in.

[necolas]

Thanks for the suggestion. I think the existing responses cover a variety of reasons why this style has not been included.

[equinusocio]

👍

[equinusocio]

Finally, as a matter of philosophy, __avoiding OS specific styles has been a normalize.css tradition__, which is why it also stays out of things like form styling or auto-hiding the scrollbar in IE.

Really? @jonathantneal

Safari on MacOS

/**
 * Remove the inner padding and cancel buttons in Chrome and Safari on macOS.
 */

[type="search"]::-webkit-search-cancel-button,
[type="search"]::-webkit-search-decoration {
  -webkit-appearance: none;
}

Safari on iOS

/**
 * 1. Correct the inability to style clickable types in iOS and Safari.
 */

::-webkit-file-upload-button {
  -webkit-appearance: button; /* 1 */
}


/**
 * 2. Correct the inability to style clickable types in iOS and Safari.
 */

[type="reset"],
[type="submit"] {
  -webkit-appearance: button; /* 2 */
}

/**
 * 2. Remove gaps in links underline in iOS 8+ and Safari 8+.
 */

a {
  -webkit-text-decoration-skip: objects; /* 2 */
}

I see a lot of inconsistency, my 2 cents