CSS -webkit-font-smoothing:antialiased is set by mdc-typography class. I'm no graphics expert, but someone who sounds like one say this is a no no. Also, MDN says no no.
stop âfixingâ WebKit font smoothing by disabling subpixel rendering. ... for main portions of text where readability is paramount please leave the default setting alone and let the operating system handle the smoothing.
- Dmitry Fadeyev 2012
Do not use it on production sites facing the Web.
Webkit implements something similar with a different name: -webkit-font-smoothing and different values, however, just like font-smooth, this is non-standard and should not be used.
font-smooth - MDN
I believe we initially included this because we were seeing some aliasing noise on Chrome and Safari, but from the looks of it now, it seems to have gone away. I'd like to hear from some of the people on our fonts / type design team and get their thoughts? @shyndman @davelab6?
I agree that we should not disable subpixel rendering by default.
Gotcha. Will add in tracker.
In my experience subpixel rendering can get very ugly with light text on a dark background. Text styled in a medium font will appear bold.
Ah, the linked article covers this.
OK, so my two cents? I'd like to see some evidence that sub-pixel antialiased text is more readable. Testing across screen densities would probably make sense, too.
I have a hard time believing that on a retina Macbook, this

is more readable than this

Also, which of those two images gives you the impression of a medium weight?
Thoughts?
The Delta between Mac and Windows renderers can not be solved, afaik, with font smoothing options. Am I also wrong about this? :)
No, you're not wrong. And worth mentioning that this is a Mac-only problem. font-smoothing has no effect on Windows.
Do the screenshots I posted above bother anyone else?
I'd like to see some evidence that sub-pixel antialiased text is more readable.
"Peer-reviewed studies have consistently found that using ClearType boosts reading performance compared with other text-rendering systems."
â http://spectrum.ieee.org/computing/software/the-technology-of-text
http://www.apa.org/monitor/2010/11/read-onscreen.aspx is nice and more recent interview with Kevin.
https://blogs.msdn.microsoft.com/fontblog/2005/12/13/cleartype-clear-mind/ is about ClearType versus _aliased_ type, but worth checking out.
I believe this type of study is what the author of the article linked above was referring to, but does it still apply when taking density into account? Text is dramatically different on a retina screen. There's no reason we can't keep this enabled for single density and disable everywhere else.
From the third paragraph of the IEEE link you posted:
The chief problem is the low resolution of computer screens. The color LCD screens on most laptops and desktops today have a resolution of only about 100 pixels per inch. You need at least two or three times that many pixels to begin to approach the quality of the printed page. The output of even a cheap laser printer is six times as good.
First Sentence of that IEEE Article says May 2007, aka the year the first
iPhone was released.
On Fri, Feb 10, 2017 at 4:40 PM, Scott Hyndman notifications@github.com
wrote:
From the third paragraph of the IEEE link you posted:
The chief problem is the low resolution of computer screens. The color LCD
screens on most laptops and desktops today have a resolution of only about
100 pixels per inch. You need at least two or three times that many pixels
to begin to approach the quality of the printed page. The output of even a
cheap laser printer is six times as good.â
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/material-components/material-components-web/issues/248#issuecomment-279086370,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMKS-84oCt7I5k3kXwhLtsWvwGoefbbiks5rbOdTgaJpZM4L23xk
.
--
Hey @rhroyston,
Right. The article's old. They're talking about this being necessary on single density displays. They acknowledge that if displays were two or three times as dense (which they now are), we'd be approaching the quality of the printed page.
To me, that suggests that the technology may no longer be required on dense displays.
Imho, enabling subpixel antialiasing by default compromises the design of the typeface and the UIs using it. With that in mind, I recommend we look at this more carefully.
Yes, I was thinking of cleartype rendering being better when it on turned on by default. Which is no longer the case; MSFT dropped traditional cleartype rendering in Windows Mobile and Windows 10 because the screens are rotated and so you'd have to reflow all the text when rotating to turn it on in landscape and off in portrait, and that's too slow, so they just used the portrait renderer everywhere
@davelab6 any final thoughts on how we should proceed here?
I have one more addition. I took a few minutes and took screenshots of how the same font (Roboto medium @ 14pt) was rendered across several native OSX applications on a retina screen.
TextEdit:

Illustrator:

Sketch:

So, TextEdit uses subpixel. Illustrator and Sketch don't appear to.
Not sure if that helps any. Just thought it was interesting.
@shyndman also interested in hearing your thoughts on how you'd proceed as well
I don't like the idea of not being able to faithfully implement designs with subpixel AA enabled (because our design tools don't support it). I also think it's ugly and I doubt the readability argument (with nothing to back that up, mind you).
My gut says not to use on high density devices. Like Dave said, it's already disabled on phones and no one seems to be complaining.
My 2 cents. Google Wallet (which uses Material Design) doesn't use it and it's more readable that way: https://www.google.com/wallet/ Especially in the Hero box.
Google Wallet is using Material Design Lite underneath, but it isn't using the typography bits at all it appears. So that's why it doesn't use the font smoothing bits.
So what I'm seeing here is largely theoretical evidence suggesting that font-smoothing: antialiased should not be applied, and largely _concrete_ evidence that shows that fonts show up better on devices when it _is_ applied (at least for Roboto, which is what mdc-typography uses as its base font). Thus, I'm closing this issue and electing to _keep the property, for now_.
Regarding the stop "fixing" article: in a perfect world operating systems would be smart enough to determine whether or not a font should have subpixel antialiasing applied based on its heuristics, but based on visual evidence provided by @shyndman that doesn't seem to be the case.
Regarding MDN's warning, we use the vendor prefixes directly because of this. And furthermore, Mozilla is pretty aggressive when it says not to use things. It also says not to use KeyboardEvent.keyCode đ which - at least until all browsers support KeyboardEvent.key - is untenable.
I'm essentially coming at this from the same place as David Walsh:
"I don't pretend to be a typography or design expert -- I just know what looks good and what doesn't"
To me, until I see some evidence that these font-smoothing applications make our components / typographic system look worse, I don't see the value in removing it.
On a final note, if you use your own fonts and font-smoothing turns out to make it less legible, simply add an override via css:
<link rel="stylesheet" href="material-components-web.css">
<style>
.mdc-typography {
-webkit-font-smoothing: none;
-moz-osx-font-smoothing: auto;
}
</style>
Following this discussionâand after some quick testsâI found defaulting font-smoothing on high-density screens to produce very balanced results. Evidently this targets only large-screen desktop users where type can indeed be made more legible.
element {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
-webkit-font-smoothing: auto;
-moz-osx-font-smoothing: auto;
}
}
subpixel font rendering is a feature controlled at the OS level, which the user expects to be able to control so that websites obey. this option deliberately overrides the user's OS-level setting, forcing a fuzzier and lower-contrast rendering method, and requiring users to use userstyles to restore OS settings and enable user control.
honestly now that Apple's removing subpixel lcd rendering, this is a somewhat moot point. I'm glad that font-smoothing cannot be disabled using this option on Windows... though some people still manage to find ways to break subpixel font rendering (against orders from user's OS) under the guise of GPU acceleration. Chrome is particularly guilty of violating user control, Firefox much less so.