Closed Bug 857142 Opened 11 years ago Closed 11 years ago

Add CSS property for author control over antialiasing on Mac OS X, for cases where fonts appear too heavy

Categories

(Core :: Graphics: Text, defect)

Product:
Core
Component:
Graphics: Text
Version:
19 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla25
Tracking Flags:
Tracking Status
relnote-firefox --- -

People

(Reporter: bugs, Assigned: jtd)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: css-moz, dev-doc-needed)

Attachments

(6 files, 1 obsolete file)

screenshots showing the contatta font as rendered in TextEdit.app
110.79 KB, image/png
Details
screenshot, closeup of testcase on various browsers
47.14 KB, image/png
Details
web inspector in safari showing the use of -webkit-font-smoothing
209.45 KB, image/png
Details
screenshot, Apple website page using font-smoothing for body text
1.08 MB, image/png
Details
patch, implement -moz-font-smoothing
18.84 KB, patch
dbaron
: review+
Details | Diff | Splinter Review
patch, v1b - add osx-font-smoothing reftest
4.04 KB, patch
m_kato
: review+
Details | Diff | Splinter Review 
When viewing pages in FFOX, the fonts appear heavier than specified. This is especially troublesome with icon fonts. Even when specifically set to normal/400 weight (or even any weight lighter), they appear to be bolded. 

In jdaggett's demo: http://people.mozilla.org/~jdaggett/tests/social-waterfall.html

You can see that with no font smoothing (webkit), Safari comes in somewhere between Chrome (the lightest) and FFOX (the heaviest). http://screencast.com/t/fqQHN5Ktob7

With font smoothing enabled, Chrome and Safari are identical, but FFOX is very heavy (of course, since it's not changed by webkit font smoothing): http://screencast.com/t/ZSYNRdpgs

Here's JD's image (blown very large) of his font vs my machine's font: http://people.mozilla.org/~jdaggett/images/stephanie-jd-comparison.png 

I have found, that on my Mac, if I go to Settings > General > and set "Use LCD font smoothing when available" to OFF (it's on by default) and restart the browsers, FFOX looks like the other browsers.

I know I'm not unique, because one of the guys at work pointed out the bolded icon font to me before I'd seen it. My personal machine is:

Mac OS X (10.7.5)
Processor: 2.66 GHz Intel Core i7
Memory: 8GB 1067 MHz DDR3
Graphics: NVIDIA GeForce GT 330M 512 MB

If you need another test case, you can view the icon font in the footer at: http://contatta.com Those are the fonts I originally noticed with the bold appearance in FFOX. 

(I was supposed to cc :brendan and :dbaron ... but don't see how to do that in the interface.)
Ooops. Meant to include my screen shots of the contatta.com footer. 

Chrome: http://screencast.com/t/x0vftk5s
FFOX: http://screencast.com/t/luIBaXg01R1
Who will take this bug? jkew, jdaggett?

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
This shows how the contatta icon font renders in TextEdit.app, as black on white and as white on black, comparing grayscale-only (left) vs LCD (right) font smoothing.

The "problem" in Firefox is simply how OS X renders the font when "LCD font smoothing" is enabled (which I think is the default). AIUI, it's widely known among the font-design community that OS X tends to fatten glyphs somewhat compared to other rasterizers. For the usual case of black-on-white text, this works OK (though some people like it more than others); however, for white-on-black, the effect can be much too heavy-handed.

It's not clear to me, though, that we'd want to disable LCD smoothing altogether, if it's enabled in the system preferences. As a general rule, we should be honoring the user's settings, and if we -don't- use LCD smoothing when it's enabled system-wide we're likely to get complaints that Firefox's font rendering looks different ("weak"?) compared to other applications running on the same system.

One option might be to disable LCD smoothing for downloaded (@font-face) fonts, on the grounds that it might provide a better match to how other browsers render the same pages. I'm not keen, though, as that puts us in a position where the exact same font will render quite differently when used via @font-face to how it renders when installed locally. I don't think that's helpful to designers, overall.

Maybe we could detect when we're drawing light-on-dark text, and switch to grayscale-only AA in that situation. Difficult to do in a fully general way, though: what would we do when drawing text with a gradient, or on top of an image or other variable background?

Or another option would be some kind of CSS property that authors can use to select which kind of antialiasing should be applied. That only works for authors who are actually aware of the issue, though, and figure out what works best for their particular font. And it enables authors to ride roughshod over the user's preference for how fonts render on their system, which is something I think should normally be under the -user's- control.

In short: while I sympathize with the reporter's complaint, and agree that example looks bad, it's not at all clear to me what would be the most appropriate solution in Firefox.
FWIW, viewing the contatta.com site in Opera (v12.14) on OS X shows rendering that looks very much like Firefox's. With Opera switching from Presto to Webkit, I suppose that's likely to change, but it serves to demonstrate that this isn't really a Firefox issue, it's an OS X font-rasterizer issue.

I realize this may seem like trying to duck the issue, but my recommendation to authors would be -not- to use "icon fonts" for things like this. They do seem to be a hot topic in the web-authoring world at the moment, but font and text-rendering APIs and technologies have been optimized for -text- rendering, and things like the Twitter or Facebook or Youtube logos are -graphics-, not text. As such, the appropriate web technology to deliver them would be SVG or PNG graphics, not @font-face. And that will give you much better control over exactly how they appear (as well as ensuring the intended logos appear even for people who have turned off the option to "allow sites to use their own fonts").
While I agree that users should have control of their experience, I'm not sure the answer to this issue is just "don't use icon fonts". The ease of use/upkeep/advances in @font-face/etc mean they're likely here to stay.

It seems to me that giving a developer the ability to fine tune the experience on their site is important. Please don't say that because there are some ignorant devs out there, we can't have nice things. (If that were the case, we could throw out lots of the advancements of HTML5 and CSS3 — because people are building things that are really no different than Flash. ;) 

Having something like I have in webkit, with font smoothing/antialiasing/etc would be my optimum solution — as a dev who keeps the user's best interest in mind. 

The problem is large enough, that if you Google the issue, you'll find lots of folks floundering around with font issues — and no solution. Help us to make FFOX look awesome? Please? :)
Assignee: nobody → jdaggett
Summary: Fonts in FFOX OSX appear heavier than specified → Fonts in Firefox on OSX appear heavier than other browsers
Magnification of the reddit icon from the testcase.  The top row shows Firefox/Safari/Chrome on Stephanie's machine, the bottom row shows it on my Retina Mac Book Pro.  Notice that Chrome uses subpixel antialiasing on my machine but grayscale antialiasing on Stephanie's machine.  Safari on Stephanie's uses subpixel antialiasing, so this isn't a system setting issue (i.e. disabling the LCD font smoothing setting in Prefs or any of the other low-level means of doing this).  On my machine there are slight variations in the pixel values across the three browsers (Safari and Chrome don't match).
(In reply to Stephanie Sullivan Rewis from comment #0)

> I know I'm not unique, because one of the guys at work pointed out the
> bolded icon font to me before I'd seen it. 

Could you ask them to view the testcase I made on their machines?  Do they see the same results as you?  Walking around the office yesterday at Mozilla Japan I couldn't find anyone who showed results similar to the one you're seeing, nor could I reproduce it on an iMac running 10.6.  In all cases, results across browsers Firefox/Safari/Chrome used subpixel antialiasing.

> My personal machine is:
> Mac OS X (10.7.5)
> Processor: 2.66 GHz Intel Core i7
> Memory: 8GB 1067 MHz DDR3
> Graphics: NVIDIA GeForce GT 330M 512 MB

What flavor of Mac is this?  iMac/MacBook Pro/mini?  Are you using an external monitor?  If so, what model/make?

Thanks for your help with this!
Looks like the mid-2010 15" MacBook Pro used the NVIDIA chipset has on her machine:

http://support.apple.com/kb/SP582
> If you need another test case, you can view the icon font in the footer at:
> http://contatta.com Those are the fonts I originally noticed with the bold
> appearance in FFOX. 

This is different from the Chrome rendering on your machine, the difference you're seeing on Contatta is the use of -webkit-font-smoothing: antialiased to force grayscale antialiasing rather than the default subpixel antialiasing.
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> I realize this may seem like trying to duck the issue, but my
> recommendation to authors would be -not- to use "icon fonts" for
> things like this. They do seem to be a hot topic in the
> web-authoring world at the moment, but font and text-rendering APIs
> and technologies have been optimized for -text- rendering, and
> things like the Twitter or Facebook or Youtube logos are -graphics-,
> not text. As such, the appropriate web technology to deliver them
> would be SVG or PNG graphics, not @font-face. And that will give you
> much better control over exactly how they appear (as well as
> ensuring the intended logos appear even for people who have turned
> off the option to "allow sites to use their own fonts").

I definitely agree with you to some degree here, the naive insertion of graphics into fonts can lead to poor results in some cases, for example the eyes of the Android icon in my testcase at small sizes.  But I think there's definitely a utility in being able to package a set of graphics into a font and that's why these sorts of fonts are gaining popularity.

I think it would be worthwhile to define and support some form of the 'font-smoothing' property so that authors can get rendering similar to what they get in Webkit browsers with -webkit-font-smoothing.

How about:

  font-smoothing: auto | antialiased

where 'auto' is what happens today, user agents try to optimize the rasterization of text based on display parameters and 'antialiased' explicitly forces grayscale antialiasing.  The original 2003 flavor of font-smoothing had 'none' and 'subpixel-antialiasing' but I don't think those make sense in practice.
Hi John... My machine is a 17" MacBook Pro. I do have an external monitor (I use them as duals), but I don't see any difference in weight from one to the other. It's a Samsung. 

The guy at work that showed me the bold fonts previously (but is no longer here) had a MacBook Air (I THINK). I do remember it was small. =\

The rest of our office (being a startup) are all on newer MacBook Pros—most under a year old. They do not see a difference in the top row of your example, but of course DO see better rendering in Safari and Chrome in the anti-aliased group below.

That said, they all see the overly bold Contatta icons in FFOX — especially evident with YouTube and Google+ - http://screencast.com/t/L5sgTB7co (And yes, I do have webkit font smoothing on in Contatta since it's needed.)

I would be thrilled with the ability to set the font-smoothing in FFOX as well. Thrilled. Tickled pink!

(We have a huge assortments of icons in our platform — having the ability to change their color and add text-shadow, etc, just as we do for a font is a big time/maintenance saver. Getting rid of huge sprite sheets also makes our lives much simpler.)

Thanks, John.
Firefox needs to implement the equivalent of -webkit-font-smoothing: antialiased; if you want people to be able to use icon fonts.

See this screenshot:

http://aralbalkan.com/images/firefox-icon-font-rendering-bug.png

The browser on the top is Safari, with font smoothing set to antialiased, rendering the IcoMoon (http://icomoon.io) icon properly. The same behaviour is observed in Chrome on Mac. (I haven’t tested on any other platforms at the moment.)

The browser on the bottom is Firefox. The icon font is unusable and there is not way to get it to render properly. (The same problem occurs in Opera on Mac.)

This basically means that I cannot use icon fonts on my site until the font-smoothing is implemented in Firefox (as I don’t want to give Firefox users such a subpar visual experience).
If we're going to do something like this, let's at least give it a sensible name.

AFAICT, -webkit-font-smoothing: antialiased actually means "use grayscale antialiasing, but do not use subpixel (ClearType, LCD-style) antialiasing".

A more logical set of property values might be something like:

  (-moz-)font-smoothing: none | grayscale | subpixel | auto

where "auto" would be the default, and would mean "use the system-wide default setting".

I think we should push back against using the term "antialiased" to mean *one specific kind* of antialiasing, to the exclusion of others. Both grayscale AA and subpixel AA are valid implementations of antialiasing, so a setting of "font-smoothing:antialiased" has no reasonable grounds to choose between them.
+1 on Jonathan’s suggestions.
This isn't exactly a problem with Firefox. It's caused by Apple's LCD anti aliasing/font smoothing. More information about this problem from Tab Atkins: http://lists.w3.org/Archives/Public/www-style/2012Oct/0014.html
(Read the replies to it, too)

It comes down to this: Chrome and Safari have a workaround for this OS X issue. Would be great if Firefox had something similar.
Yes, I just read that WHOLE thread (whew!). I think this email summarizes it the best: http://lists.w3.org/Archives/Public/www-style/2012Oct/0109.html  And yes, Opera is about to NOT have a problem as they switch to Blink, so FFOX is the only current browser without a way to control an icon font via font-smoothing of some kind.
(In reply to Stephanie Sullivan Rewis from comment #11)
> Hi John... My machine is a 17" MacBook Pro. I do have an external monitor (I
> use them as duals), but I don't see any difference in weight from one to the
> other. It's a Samsung.

Were all the screenshots taken on the external monitor or on the built-in screen?  It would be interesting to compare the browser combinations together on each screen rather than comparing on different screens.  If the OS doesn't "know" the monitor it will often default to grayscale anti-aliasing for that monitor.  Apple's support sites lists lots of people reporting issues with 10.6 and 10.7 about the OS not knowing their display and how to manually force on subpixel antialiasing via a defaults tweak.

> The rest of our office (being a startup) are all on newer MacBook Pros—most
> under a year old. They do not see a difference in the top row of your
> example, but of course DO see better rendering in Safari and Chrome in the
> anti-aliased group below.

Right, this makes sense.

> That said, they all see the overly bold Contatta icons in FFOX — especially
> evident with YouTube and Google+ - http://screencast.com/t/L5sgTB7co (And
> yes, I do have webkit font smoothing on in Contatta since it's needed.)

Right, Firefox ignores the '-webkit-font-smoothing' property which is why it renders differently.
(In reply to Jonathan Kew (:jfkthame) from comment #13)

> If we're going to do something like this, let's at least give it a sensible
> name.
>
> I think we should push back against using the term "antialiased" to mean
> *one specific kind* of antialiasing, to the exclusion of others. Both
> grayscale AA and subpixel AA are valid implementations of antialiasing, so a
> setting of "font-smoothing:antialiased" has no reasonable grounds to choose
> between them.

Yeah, I would agree with you that the terminology is problematic, in particular the "antialiasing" term.  But I think the underlying question here is whether this is a solution for a short-term problem for which a prefixed property would suffice (e.g. -moz-font-smoothing) or a more general problem that needs to be defined formally in a spec.  I tend to think it's a short-term problem, there's no subpixel rendering on iOS or in the Metro UI and the problem here is a non-issue on Retina resolution displays.

> AFAICT, -webkit-font-smoothing: antialiased actually means "use grayscale
> antialiasing, but do not use subpixel (ClearType, LCD-style) antialiasing".
> 
> A more logical set of property values might be something like:
> 
>   (-moz-)font-smoothing: none | grayscale | subpixel | auto
> 
> where "auto" would be the default, and would mean "use the system-wide
> default setting".

So the problem with the complete set of options here is that "auto" and "subpixel" are basically duplicates, since you can't force on subpixel anti-aliasing in all situations.  If a user has explicitly disabled it, then the author shouldn't be able to force it on via "subpixel".  Nor is subpixel anti-aliasing needed or desired on Retina resolution displays.  Chrome already disables subpixel rendering on Retina displays (curiously, Safari does not).  I also don't see a strong need for "none" either, I doubt there are many actual use cases for an author-level control like this.

Which really leaves the "antialiasing" value as the only one with a real use case.  In this one particular case, I think it might make sense to simply implement support for the "-webkit-" prefixed property and only support auto/antialiased.  This is really an OSX-specific property masquerading as a general property and I don't see great value in implementing it on other platforms.  As screen resolutions increase it will die a well-deserved death.

I'd be curious to hear if dbaron or tantek have an opinion here.
Flags: needinfo?(dbaron)
Flags: needinfo?(tantek)
One more data point for the discussion - testing with Chrome 27 (dev) running on Windows 7, the -webkit-font-smoothing property is ignored, with or without it renders using default GDI subpixel rendering.
John, the screen shots I did (with Chrome/Safari/FFOX all together in a row) were taken across one screen. I don't recall which one, however. That said, they look the same on either screen visually, so not sure that matters?

Quick question (since I'm not on a PC), you're saying that the Windows 7 font looks the same regardless — but since it doesn't have the issue with fatter text, I'm assuming that means it looks good with or without the property (so windows is ignoring what it doesn't need)?
Also, as an example of some of the uses for icon fonts, here's a recent article showing a creative implementation of multi-colored weather icons: http://conor.cc/posts/icon-stacks (It feels like they're here for the long-haul... or until we have enough support for svg ;))
(In reply to Stephanie Sullivan Rewis from comment #20)

> Quick question (since I'm not on a PC), you're saying that the Windows 7
> font looks the same regardless — but since it doesn't have the issue with
> fatter text, I'm assuming that means it looks good with or without the
> property (so windows is ignoring what it doesn't need)?

Ha! GDI rendering of the icons looks like <insert-word-not-used-in-polite-company>.  One of the gotchas of designing on OSX without considering the state of font rendering on Windows.  DirectWrite rendering (IE9+/FF) looks fine, it doesn't suffer the overbolding effects that are the concern here.

I should note that SVG would render well in all these situations, it would be scalable and would render consistently independent without all the concerns about the particulars of font rasterization differences.  The only problem would be the need to provide fallbacks for IE8 and Android stock browser 2.3 and prior.
Reading various articles on the pluses and minuses of -webkit-font-smoothing I discovered that Apple is actual explicitly setting this for body text on the pages they serve(!!!).  Right hand, meet left hand...
Strawman patch that implements -moz-font-smoothing.  It implements what I proposed in comment 10:

  -moz-font-smoothing: auto | antialiased

where 'auto' is existing behavior (best effort to use subpixel-antialiasing but sometimes only grayscale) and 'antialiased' explicitly sets grayscale antialiasing.  The logic still respects the user's "Turn off font smoothing for text sizes..." setting.  The property would be parsed on any platform but only used under OSX.  This roughly matches Chrome behavior OSX vs. Windows (I'm ignoring Safari/Windows since that's using a ported copy of the CoreGraphics rasterizer).

Also, I didn't make this part of the set of properties reset by the font shorthand nor part of the set whose value resets when a system font is used.
(In reply to John Daggett (:jtd) from comment #22)
> (In reply to Stephanie Sullivan Rewis from comment #20)
> 
> > Quick question (since I'm not on a PC), you're saying that the Windows 7
> > font looks the same regardless — but since it doesn't have the issue with
> > fatter text, I'm assuming that means it looks good with or without the
> > property (so windows is ignoring what it doesn't need)?
> 
> Ha! GDI rendering of the icons looks like
> <insert-word-not-used-in-polite-company>.  One of the gotchas of designing
> on OSX without considering the state of font rendering on Windows. 
> DirectWrite rendering (IE9+/FF) looks fine, it doesn't suffer the
> overbolding effects that are the concern here.

True, but there is an easy solution for Windows. If you prioritize loading of the SVG font before the other formats (in the @font-face rule), everything would look nicely anti aliased. See http://icomoon.io on Windows.
(In reply to John Daggett (:jtd) from comment #18)
> I tend to think it's a
> short-term problem, there's no subpixel rendering on iOS or in the Metro UI
> and the problem here is a non-issue on Retina resolution displays.

No it's not - on the contatta.com site, for example, I see a big difference in the rendering of the icons if I disable LCD font smoothing in System Prefs.

> So the problem with the complete set of options here is that "auto" and
> "subpixel" are basically duplicates, since you can't force on subpixel
> anti-aliasing in all situations.

They're not duplicates - "auto" means respect the system setting, whereas "subpixel" would mean (try to) use subpixel even if the system setting is grayscale.

The fact that we can't actually do subpixel in all situations is just a limitation of our implementation, and means we'd have to fall back in certain cases, but that's separate from the logical set of options an author could express.

>  If a user has explicitly disabled it, then
> the author shouldn't be able to force it on via "subpixel". 

If authors are enabled to override user prefs in one direction - force grayscale when the user pref calls for subpixel - then maybe they should be able to do so in the other direction as well. Not something I care strongly about, though.

> Nor is subpixel
> anti-aliasing needed or desired on Retina resolution displays.

It's used by default all over my Retina MacBook Pro.

  Chrome
> already disables subpixel rendering on Retina displays (curiously, Safari
> does not).  I also don't see a strong need for "none" either, I doubt there
> are many actual use cases for an author-level control like this.
> 
> Which really leaves the "antialiasing" value as the only one with a real use
> case.

It's still misnamed; it should be "grayscale".

>  In this one particular case, I think it might make sense to simply
> implement support for the "-webkit-" prefixed property and only support
> auto/antialiased.  This is really an OSX-specific property masquerading as a
> general property and I don't see great value in implementing it on other
> platforms.

I suspect there'd be "value" on Windows, where there can also be a significant difference between how things look with ClearType vs grayscale font smoothing.

>  As screen resolutions increase it will die a well-deserved death.

We can hope, but as noted, it still makes a big difference on a Retina Mac.
I'm not sure how hard it would be, or how much overhead it would add, but as a user I don't want websites to be able to override my font rendering settings (even for small segments of the website), so I'd want the ability to turn this off.
Try server build of Firefox trunk with patch:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.com-ab66768a5f44/try-macosx64/firefox-23.0a1.en-US.mac.dmg

I've updated the testcase to use '-moz-font-smoothing: antialiased' in the second waterfall.
(In reply to John Daggett (:jtd) from comment #28)
> Try server build of Firefox trunk with patch:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.
> com-ab66768a5f44/try-macosx64/firefox-23.0a1.en-US.mac.dmg
> 
> I've updated the testcase to use '-moz-font-smoothing: antialiased' in the
> second waterfall.

I tried it. Works perfectly and as expected! Thank you so much John for taking the time with this issue. Would be super awesome to see this in the stable version :)
So I think we need to decide here - do we want a fully spec'ed property that gives full control over the anti-aliasing applied to text with correct names for the property values or do we just want to give authors the ability to work around the problems they face on OSX?

I agree that "antialiased" is not an accurate property value but I'm not sure there's a lot of value to use a different name for the same thing that's more correct in this situation, by doing so we lessen the chance that authors will include the correct -moz- version along with the -webkit- version.

I also think this property is being completely abused by authors, the use of it for black text on white backgrounds on apple.com pages being a perfect example.  Which is why I think I'd prefer to support it only as an unfortunate necessity to work around the underlying platform OS problem and *not* encourage authors to think of this as some "make text pretty" property, something that a lot of authors seem to believe (search on Twitter for 'font-smoothing' for many examples).
I'd say stick with "antialiased". It would be easier to use and it's good enough for this short term solution to work around the OS X problem.
(In reply to John Daggett (:jtd) from comment #30)
> So I think we need to decide here - do we want a fully spec'ed property that
> gives full control over the anti-aliasing applied to text with correct names
> for the property values or do we just want to give authors the ability to
> work around the problems they face on OSX?
> 
> I agree that "antialiased" is not an accurate property value but I'm not
> sure there's a lot of value to use a different name for the same thing
> that's more correct in this situation, by doing so we lessen the chance that
> authors will include the correct -moz- version along with the -webkit-
> version.

I'd like to hear dbaron's thoughts on this from a CSS point of view.

A suggestion: if we don't think this is something that should ever end up as part of the standard, we simply support "-webkit-font-smoothing: antialiased" and leave it at that. If we -do- think it should be standardized, we implement it with a better name, as "(-moz-)font-smoothing: grayscale", and propose it to the CSS WG. We could -also- alias the "-webkit-font-smoothing: antialiased" property to it if that's deemed necessary, though I think it would be unfortunate.

> 
> I also think this property is being completely abused by authors, the use of
> it for black text on white backgrounds on apple.com pages being a perfect
> example.  Which is why I think I'd prefer to support it only as an
> unfortunate necessity to work around the underlying platform OS problem and
> *not* encourage authors to think of this as some "make text pretty"
> property, something that a lot of authors seem to believe (search on Twitter
> for 'font-smoothing' for many examples).

So how are we going to discourage authors from "completely abus[ing]" this, if we implement it at all?
(In reply to Jonathan Kew (:jfkthame) from comment #32)
> (In reply to John Daggett (:jtd) from comment #30)
> 
> I'd like to hear dbaron's thoughts on this from a CSS point of view.

I just pinged him in IRC, so I think he'll come have a look when he gets into the office. (He's leaving now.)
> 
> A suggestion: if we don't think this is something that should ever end up as
> part of the standard, we simply support "-webkit-font-smoothing:
> antialiased" and leave it at that. If we -do- think it should be
> standardized, we implement it with a better name, as "(-moz-)font-smoothing:
> grayscale", and propose it to the CSS WG. We could -also- alias the
> "-webkit-font-smoothing: antialiased" property to it if that's deemed
> necessary, though I think it would be unfortunate.

This is something I think dbaron can help decide. For my purposes, I'm happy to be able to turn it on for the specific cases where I need it (almost always icon fonts). And I appreciate you leaving it OUT of the font shorthand reset. That's a help.
> 
> 
> So how are we going to discourage authors from "completely abus[ing]" this,
> if we implement it at all?

I'm not sure you can ever keep authors from abusing a whole host of properties. There will always be ignorant people. I've spent much of my web career trying to help educate other devs through writing/speaking/training. It seems to me the best way to prevent abuse is knowledge... not the restriction of logical, balanced devs. Just my .02.

Thanks so much for working on this guys. Much appreciated.
So my feeling after reading this bug and the links in comment 15 / comment 16 is that there's a reasonably strong case here to switch our behavior on Mac OS X to avoid using LCD antialiasing (either for all fonts, or for downloadable fonts only since those are the ones where cross-platform interoperability is a more reasonable expectation), given the incompatibility between Mac OS X's LCD antialiasing with font rendering everywhere else.

I'm not convinced that the solution for an incompatibility that is problematic for authors is to add a property to "fix" things that only the most informed of authors will know about.  But if we do add such a property, then as far as the disagreement on the value space (comment 13 vs. comment 18) I think I'm inclined to agree with comment 18, except for the final paragraph about supporting -webkit- prefixes.
Flags: needinfo?(dbaron)
I would definitely not advocate turning off OSX LCD font smoothing unilaterally, it's what Mac users are accustomed to and expect and in most cases it makes sense for readable text on normal DPI displays.  The fact that it differs from GDI/DirectWrite/FreeType is just something users accept.  I'm only advocating for some form of font-smoothing property to allow authors to work around the problem of light text on dark backgrounds appearing too bold.  I think we should actively encourage authors to only use it for a narrow range of problems.

More than the posts by Chrome devs on www-style, I think these two posts are quite insightful:

http://www.usabilitypost.com/2010/08/26/font-smoothing/
http://www.usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/
I'm apt to agree with John on keeping LCD font smoothing as it currently is overall — but giving authors a property to use when it's necessary for specific fonts or color schemes.
(In reply to John Daggett (:jtd) from comment #28)
> Try server build of Firefox trunk with patch:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.
> com-ab66768a5f44/try-macosx64/firefox-23.0a1.en-US.mac.dmg
> 
> I've updated the testcase to use '-moz-font-smoothing: antialiased' in the
> second waterfall.

Hi John, how long does it take for this change to get from the trunk/patch to Aurora (my assumption is that's the next place it lands)? I'd like to use this soon... :)
Comment on attachment 733206 [details] [diff] [review]
patch, implement -moz-font-smoothing

Requesting initial review.
Attachment #733206 - Flags: review?(dbaron)
(In reply to Stephanie Sullivan Rewis from comment #37)

> Hi John, how long does it take for this change to get from the trunk/patch
> to Aurora (my assumption is that's the next place it lands)? I'd like to use
> this soon... :)

There needs to be consensus that the approach in the patch, both the property and its values along with the implementation details.  Once there's agreement then we land the patch and it goes through the existing Firefox dev cycles (i.e. Nightly ==> Aurora ==> Beta ==> Release).  If it was checked in today it would go into Firefox 23.  See this page for more details:

https://wiki.mozilla.org/Releases
Any ETA when the patch will probably been merged?
+1 Any ETA on this?
Before any ETA can be estimated, we need to have consensus around what the right feature to implement is.  I've set up a patch that proposes adding '-moz-font-smoothing' but as you can see the patch has not been reviewed yet.  A group of Mozilla devs working on layout and rendering are meeting next week, I expect we'll have a discussion then and decide then whether to implement this as proposed in the patch or not.  As you might guess, I'm for the patch ;) but others may need convincing.
Is there an ETA on this yet? It would be extremely useful to me too.
What are the other options? -moz-font-smoothing: aliased? none? Please advise. Thanks. Is this implemented yet?
Tantek's comment via email:

"Sounds like a practical necessary way to make incremental progress
while waiting for a better solution. Go for it."
Flags: needinfo?(tantek)
My site relies heavily on font-icons and it frustrates me that this issue is open for month with a possible fix, but nothing happens. Some of my customers already switched from Firefox to Chrome, because it looks much better.

Take a look at Font Awesome, a widely used font icon library: http://fortawesome.github.io/Font-Awesome/icons/

Open the page in Firefox and Chrome and you see a huge difference. The icons look way better in Webkit Browsers due to:

-webkit-font-smoothing: antialiased;
(In reply to John Daggett (:jtd) from comment #45)
> Tantek's comment via email:
> 
> "Sounds like a practical necessary way to make incremental progress
> while waiting for a better solution. Go for it."

Hi :jtd, when can we expect to see your fix? I really need this.
Sorry for taking so long to get back to this.  After reading this bug and the entire www-style thread referenced in comment 15 and comment 16:

 * I'm convinced by comment 35 that my suggestion in comment 34 was bad

 * I'm disturbed by the lack of authoritative information about Mac OS X's behavior.  The best information in the thread (linked from comment 16) seemed to be "here's what I reverse engineered".  It's hard to understand why the API behaves as it does or whether there are any plans to improve it.

 * I agree with comment 13 that grayscale is a better name than antialised, but I disagree with comment 26 saying that control in both directions is necessarily needed.  Given that the control is in one direction, though, perhaps grayscale-only or only-grayscale would be better, to indicate that grayscale antialiasing is permitted but not required by the value.

 * I'm not entirely convinced by the argument that this will go away fast enough that we don't need to standardize it.  But I suppose I'm leaning in that direction, given that the problem is Mac-specific, and Macs are high-end hardware with very low developing-world market share, and higher-density displays are likely to make the problem go away.  (If it doesn't go away soon enough, what are the odds Apple will release a better API that would allow fixing the problem a better way?)

 * Even if I were convinced by the former, I'm not convinced that that means we should be shipping new APIs with -moz- prefixes.  Then again, all competing browsers on Mac support the -webkit- prefixed form, and while I suspect we could get the Chrome team to do something unprefixed, I'm less confident about the Safari team.  But on the other side, having unprefixed support in Firefox and Chrome might be enough to get the Safari team to match.

I haven't drawn any conclusions from that yet.
Oh, and:

 * I strongly agree with comment 4, ¶2, regarding icon fonts, and I don't see them as a relevant use case.
I strongly disagree with your opinion regarding icon fonts. Icon fonts are great for small web-developer teams who don't have time to build there own icon graphics in each and every color and size.

Take a look at the Font Awesome library: https://github.com/FortAwesome/Font-Awesome

The icons look ugly in Firefox on Mac OSX, but look great in ANY other browser (webkit, ie). As you can see the lib is quite popular among the open source community (16k stars, 1.7k forks).
I won't expound here on the reasons icon fonts are gaining popularity in the front end world—many articles have been written. Upkeep and ease (now that we have fairly consistent support for @font-face) are reasons I believe they'll continue to gain steam with designer/developer types. One of the biggest reason they're not "more" popular is this very bug — they look great everywhere except FFOX. On teams where design clarity is an issue (many, many), this forces them back to sprites. (That said, the difference in the way a regular font looks in FFOX is also undesirable.) So its a chicken and egg thing. They're used less because they look like **** on FFOX. FFOX engineers say they're not used that much so they don't need to fix this.  

While I understand that many engineers continue to state that icon fonts are a hack — truth is, they may be more of an evolution. Times, abilities and needs change. Expedience sometimes wins the game. Seems a shame that there are so many designers are struggling with this font issue — while engineers tell them they're doing the web wrong. 

Maybe stepping out of the box and examining "why" these designer-types continue to write articles, post on help forums and file bugs, begging for a fix is happening. These are web workers trying to help your users have an equivalent experience to other browsers. Every popular browser has a way to deal with this — whether it's an Apple bug or not. Seems to me that Apple's "fix" may have been to simply create a webkit prefix to make their browser (and forks of it) work around the bug. I've never seen any indication that they've got an imminent fix on its way.

All we're asking for — for at least a couple years (or more — based on this bug forum & other online help forums) — is a way to allow authors to make their pages look attractive and consistent with every other popular browser. I am baffled by the continual digging in of heels here when authors are literally begging you to help them assist your browser to look like it belongs in this decade.
I completely agree with the last poster! Have some pride in your product! I did some work for a design company/ add agency over the last 12 months, and I initially suggested for them to try out Icon fonts, because with the limitations in css transitions the icon fonts give you a bit more flexibility, and when you have to support many browsers at a pixel perfect level, the icon fonts give you a quick way to achieve vector support even on browsers not supporting svg. I have been getting bug reports on my work from the designers that the icons do not look good enough on FF OSX. When I get a bug report I can not say "FF OSX is not important", or "you are doing it wrong" or "When the firefox engineers get their head out of the cloud of self indulgence, they will surly fix it", It is a bug, I have to provide a fix, and so far the only fix I can do is to go back to png icons.

I feel the prolonged discussion on this only helps marginalize the Firefox browser, and gives the impression that the FF do not take the issues of the design community seriously. (This is so last century, I have learned to respect the needs of designers, so should you!)

Since this is a problem for FF and not the other browsers, and since FF is really late to the table, I really do not see why a standardization process should be initiated, to convince the engines where this is actually working to do it in a different way, because it is more "right". What you should do is to add the moz prefix, quietly start supporting the -webkit-font-smoothing on osx for backward compatibility, and not make any more fuzz.

I got really upset when I read David Baron´s post, for me this missed the mark completely. I feel this way of over analyzing the problem is the wrong direction to go. Even if we classify this as an OS bug, working around OS bugs so a browser looks about the same on all platforms (where this is feasible), should clearly be within the scope of the firefox browser development.

Sorry for the tone of this post, I have been following this issue for the last 6 months, please know that I only say this because I care.
(In reply to Stephanie Sullivan Rewis from comment #52)
> All we're asking for — for at least a couple years (or more — based on this
> bug forum & other online help forums) — is a way to allow authors to make
> their pages look attractive and consistent with every other popular browser.
> I am baffled by the continual digging in of heels here when authors are
> literally begging you to help them assist your browser to look like it
> belongs in this decade.

Yet authors are also begging us to stop the explosion of vendor prefixes.  And they're also begging us never to implement another vendor's prefixes.

Are you saying that you're confident that in this case, authors don't mind the vendor prefixes, because this one is important?

The difficulty here, for us, is that we're going to be stuck with whatever we do, likely forever.  We'll also be stuck with authors asking to improve it (for example, asking to make it work on other platforms).  You won't, because you won't have to use it if you don't want to.  But we'll be stuck with it, and the Web will be stuck with it.  So there's value in getting it right.

So we need to be very clear on whether the property we're adding is specifically for working around an OS X bug (which seems to be what the general trend on this bug says) or is a general control for antialiasing (which seems to be the consensus response on www-style, including the small amount of developer/designer feedback there).

It seems like a bad idea to me to add a general control for antialiasing if the main reason authors are going to use it is because subpixel antialising is ugly on OS X, and authors will therefore turn off subpixel AA on all platforms (making the experience for users worse on all systems other than OS X).

My impression is that -webkit-font-smoothing isn't particularly clear about which question it's answering; it is currently implemented only on OS X, but maybe that's because that's the platform the Safari team cares about most, or maybe that's actually the intent.

If the intent here is to work around the OS X bug, and we do just that -- implement -moz-font-smoothing on OS X only, as John's patch does, and then a smaller group of authors with different use cases come and beg us to make it work on Windows too -- what will your reaction be?  Will you be upset that your workaround that was intended to affect Mac OS X only is now making the experience worse on Windows?

If everybody asking for this feature agreed on whether it should be OS X only or cross-platform, we'd have an easier time moving forward.  But in order to implement it, we actually need to know which it is.
Yes, I understand your dilemma with prefixes (tho I am a fan of them in this stage of "stuff works some places, SAYS it works others—yet they didn't quite get it right" since it allows me to turn that feature off where I'd like to).

Prefixes aside, IMHO the issue exists on Macs. And yes, it's their bug. But I see no movement toward addressing it (outside webkit/safari/chrome/opera giving us a workaround). I am simply asking for that same workaround to be available in FFOX. As far as I can tell, that's what we all want—the ability to make our web pages visually consistent in font rendering.

Since this issue does not exist on Windows, I would not expect to control antialiasing on that platform. And if later, there becomes a ground swell to give all authors control on all platforms—well, that's an entirely different thing—and should be addressed via the Standards body and written into the specs. 

But this particular issue/bug was opened to beg, beg I say, for the same thing we can do in every other browser on the Mac platform already. Help us David-wan Kenobi. You're our only hope. ;)
We should fix this competitive, author-facing bug.

/be
(In reply to Stephanie Sullivan Rewis from comment #55)
> Since this issue does not exist on Windows, I would not expect to control
> antialiasing on that platform. And if later, there becomes a ground swell to
> give all authors control on all platforms—well, that's an entirely different
> thing—and should be addressed via the Standards body and written into the
> specs. 

Would you mind saying that on www-style, where the consensus has been strongly the opposite?
(In reply to Ulrik Einarson from comment #53)
> I got really upset when I read David Baron´s post, for me this missed the
> mark completely. I feel this way of over analyzing the problem is the wrong
> direction to go.

You're talking about comment 51?

> Even if we classify this as an OS bug, working around OS
> bugs so a browser looks about the same on all platforms (where this is
> feasible), should clearly be within the scope of the firefox browser
> development.

What solution are you proposing here?  I'm not sure if you're arguing that we add a new property (as proposed in comment 5, comment 24, and comment 51), or arguing that we have an automatic fix like I proposed in comment 34 and was rejected in comment 35 for reasons I agree with (comment 48)
Flags: needinfo?(torvalde)
(In reply to David Byron from comment #58)

Yes I am talking about comment #51.

You are right that I want what was posted in comment #24

I do understand that it is a bigger picture to take into account, and I appreciate you taking the time to consider it, when you work too much with designers it is easy to become too pragmatic. I still think that for this issue a "quick fix" to make it possible to have the same presentation on firefox as the other browsers on osx. If there should come a push to have the same behavior on windows, then one could try to standardize with the other browser vendors, but I think it is unlikely that this push will ever come.

I also think that it would be really hard to get the other browser vendors to rally around this issue as it is now (Only a problem for firefox).

One could call icon fonts a hack, but one could also call sprite maps a hack and really a lot of the things we web developers do for a hack, I do not really see the point in classifying something as a hack or not, as long as it is a significant enough number of people doing it, and the result is that pages look worse than they need to in firefox.
Flags: needinfo?(torvalde)
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #57)
> (In reply to Stephanie Sullivan Rewis from comment #55)
> > Since this issue does not exist on Windows, I would not expect to control
> > antialiasing on that platform. And if later, there becomes a ground swell to
> > give all authors control on all platforms—well, that's an entirely different
> > thing—and should be addressed via the Standards body and written into the
> > specs. 
> 
> Would you mind saying that on www-style, where the consensus has been
> strongly the opposite?

Well, www-style is not my cuppa. Thing is, you proposed on www-style creating a whole new thing—not about the fix that I filed this bug for. So yes, you likely stirred the list up (not hard to do). ;) (I read the thread late last week, then got into a deadline that kept me up working till 7:30a Monday morning.)

The fix I personally am looking for is the one that :jtd created in Comment 28 (or similar), and that Keyamoon (creator of the Icomoon font) visually approved. I simply want the same ability I have within the webkit family of browsers. So that when I need to fix Apple's rendering mess, I can do it the same way in FFOX that I do in all the other Mac-based browsers.

I don't require any new features, renderings, etc. Just a fix for the blurry FFOX fonts on Mac. I'm a simple gurl, really. Thanks David.

(And if you're serious about me posting on www-style—for you, I will. But I don't enjoy the attitudes there, so I won't stick around. Life's too short. ;))
Could you explain how what I posted to www-style is different from what you filed this bug for?  As far as I know, it's proposing the same feature as what John's patch implements, except with (a) somewhat different names and (b) different parsing behavior on platforms where the property is not implemented.
I guess the biggest difference (besides the rabbit hole it led people down in discussing the minutiae of it) is that all most of us are asking for is a -moz-font-smoothing property equivalent to what exists in webkit browsers today. 

On the www-style list, you were attempting to gain consensus for a single, cross-vendor property name that other browsers would also support. And while that is certainly a noble cause (any day we can get consensus and lose a prefix is a good day), the other vendors have already dealt with this issue in their own way. So I don't see it as something you'll likely gain a lot of support for, and thus, I see it only as another thing that slows down our ability to make any text look as nice in FFOX as it does in other browser. 

This has been going on for a couple years — the posting on help forums (with the "sorry, there's nothing you can do" answer)... the filing multiple font rendering bugs here... In fact, this bug has been going on since April, with a possible fix created that month as well. So starting a campaign at this point to "get all vendors on board" when they've already dealt with it — well, apologies, but it just feels like a big delay and yet more time we designopers have to wait for something we've begged for from FFOX for a really long time. 

I honestly can't express to you how frustrating this particular bug is for those of us that do front-end work. It's my number one frustration with FFOX.
(In reply to Stephanie Sullivan Rewis from comment #62)
> On the www-style list, you were attempting to gain consensus for a single,
> cross-vendor property name that other browsers would also support. And while
> that is certainly a noble cause (any day we can get consensus and lose a
> prefix is a good day), the other vendors have already dealt with this issue
> in their own way. So I don't see it as something you'll likely gain a lot of
> support for, and thus, I see it only as another thing that slows down our
> ability to make any text look as nice in FFOX as it does in other browser. 

I think it's worth waiting a few days for feedback.

In particular, I'd be inclined to implement without a prefix (i.e., just 'osx-font-smoothing') if I got feedback from Blink developers that they thought doing so was reasonable.

> This has been going on for a couple years — the posting on help forums (with
> the "sorry, there's nothing you can do" answer)... the filing multiple font
> rendering bugs here... In fact, this bug has been going on since April, with
> a possible fix created that month as well.

This bug being filed was the first I heard of it, I think, though I admit I don't have a very good memory.  (No idea what help forums you're talking about, but I'm not aware of any official Mozilla help forums for Web development questions.)
As a user I'm worried about authors abusing this property to force greyscale AA on the entirely of pages, is there any other property that lets authors override user preferences in this way? (I can turn off images/colours/etc. and the page author can't override that). I prefer the way OS X renders text, so for me this would reduce the quality of rendered text, not improve it.

For a while WebKit had a bug where specifying a certain text-shadow setting would achieve this same affect (But in Firefox it caused "double struck" rendering), and I'm still seeing sites that have applied that hack to all text shown because the author thought greyscale text looked good when they designed it.
Reply to Alex

Since we can use custom fonts on a page, it is only reasonable that it is possible to make the fonts look the way they are intended to look in the browser.

If the font-smoothing is a really big problem for you it is probably possible to find a plugin that overrides it. (Or really easy to write one yourself.)

If we were to remove everything from css that could be abused, it would not be so much of css left...

The biggest problem for us is headings on dark backgrounds, icon fonts and color noise from the subpixel antialiasing method, do you have a better way to fix this on osx?
As a user you can override it in a user style sheet as described in http://kb.mozillazine.org/UserContent.css and also made easier by various extensions.

Which reminds me -- the patch probably should respect the useDocumentFonts variable in nsRuleNode::ComputeFontData.
A few days is one thing. But in my experience, a few days typically turns into a few months—devs get distracted by other things, and then whole thing gets dropped... just like has happened here... till someone starts squawking very loudly again. I've been needing this for months and months. 

Here's a similar bug from bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=640134 from March '11 asking for something like webkit-font-smoothing... devs here answered similarly with "what are the use cases" - can't you just change fonts? Etc...  That's over 2 years before I filed my bug. This has been frustrating many, many of us for a long time.

As to forums, I mean literally forums all over the web — anywhere devs try to help each other. You can Google it (which is what we all do when trying to solve a particularly frustrating problem). Here are a few:

http://ilikekillnerds.com/2010/12/a-solution-to-stop-font-face-fonts-looking-bold-on-mac-browsers/ from DECEMBER 16, 2010 (This guy figured out the fix for webkit... but in the comments, they're all trying to figure out what to do for FFOX — and no, the opacity trick doesn't help in my experience.)

Here's someone using a @-moz-document url-prefix() hack to reset the weight for FFOX: http://www.stormconsultancy.co.uk/blog/development/tips-tricks/dealing-with-firefox-rendering-fonts-too-bold-with-browser-specific-css/

http://www.dave-bond.com/blog/2009/11/fonts-too-bold-on-mac/ (again, the opacity trick and the url-prefix hack... but read how many people have "been looking everywhere for a fix for FFOX in the comments)

http://superuser.com/questions/306355/firefox-font-face-is-bold-in-os-x (User found font-smoothing and wants the same for ffox.)  from July '11

http://www.uv.mx/personal/gvera/stop-fonts-looking-bold-on-mac-browsers/ (Blog post explaining fonts, showing solutions for the bold issue, whereby each time he has to say, "But this doesn't work in FFOX" 

http://stackoverflow.com/questions/13636931/font-face-font-looks-bolder-in-firefox (there are plenty more on stack overflow where they basically come to the conclusion that "on FFOX you're stuck and can't do anything"...

http://stackoverflow.com/questions/11459746/css3-webfont-smoothing-and-antialiasing-in-firefox-and-opera
http://stackoverflow.com/questions/761778/forcing-anti-aliasing-using-css-is-this-a-myth

There are plenty more...
(In reply to Stephanie Sullivan Rewis from comment #67)
> Here's a similar bug from bugzilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=640134 from March '11 asking
> for something like webkit-font-smoothing... devs here answered similarly
> with "what are the use cases" - can't you just change fonts? Etc...  That's
> over 2 years before I filed my bug. This has been frustrating many, many of
> us for a long time.

It also didn't mention the use cases that were mentioned in this bug:  that subpixel AA on Mac OS X has a tendency to make fonts appear substantially bolder, especially for light text on a dark background.  This bug presents a substantially stronger rationale than anything in bug 640134.

And I really do mean a few days.
Alright, my buddy... let's shake on it. A few more days. But please, please don't let it go to even more months? 

I shall be awaiting your decision on how to implement this with bated breath.
(In reply to comment #63)

Personally I would argue for creating a -moz prefixed option, instead of an unprefixed one. Since I do not think so many browser vendors will embrace the unprefixed one I do not see how this would make things easier for anyone. With a prefixed one you atleast bulid on an established convension (Even if it don't make too much sense) People would use it as they use the webkit prefix today, and expect the same result, and on the off chance other browser vendors should want to standardize it for other platforms, it is a chance to do it together with them.

But as long as it gets fixed I do not care too much.
Pragmatic approach:

1.) Just introduce the exact same fix as webkit with a moz-prefix: -moz-font-smoothing: antialiased;

Web devs are already familiar with it, so it would be quite easy to understand and integrate.

2.) After that point you can try to find a censensus with the other browser vendors.

While (1) is really easy for you to integrate (the patch is already attached to this issue), (2) might take some time. But IMO you shouldn't waste more time on this because at the end its a FFOX only problem! 

For the end user it doesn't matter if it's your fault or a Mac OSX bug. Users only see (some) website look ugly on FFOX while they look great on any other browser.

I don't want to recommend my customers to switch from firefox to an alternative browser on Mac OSX, but that's what I've done and will do as long as this issue still is not fixed.
So, according to [1] we currently do not implement text-rendering: geometricPrecision.  How about an interim OS X-only implementation that just does the grayscale AA fix required here.

It would have the advantage of respecting the semantics a bit more, i.e. developers should not really be futzing around with the details of OS-specific AA settings, they just want the shape respected.  This encourages a narrow use on icon fonts, and leaves body text looking consistent across apps [?].

Given whatever solution is picked will hang around forever, it seems reasonably future-proof, in that a complete future implementation of text-rendering: geometricPrecision would not make things worse.

It seems fairly cross-platform, in that geometricPrecision currently uses the normal text rendering path on Windows, which is apparently OK for this issue, and would continue to do so.

Possible problems: 1) maybe lots of pages already have it set on body text, relying on its not being implemented; 2) there is already a Chrome implementation, and perhaps icon fonts look bad with that.

Sorry for muddying the waters, but sometimes a step backwards is useful.

1. https://developer.mozilla.org/en-US/docs/Web/CSS/text-rendering
(In reply to comment #72)

There are many more resons for not doing as suggested above, for example bugs in some browsers when geomp is used together with letter spacing and also other tings.
Yes, sorry, I had only paid attention to the reports of issues with icon fonts, for which a geometricPrecision fix would have been quite good, even with the issues you mention (because: single characters, font under dev control); I hadn't realized quite how many of the issues were about light body text, for which it would be inappropriate.

Apologies also for not reading the www-style links carefully, where this is brought up several times.
Comment on attachment 733206 [details] [diff] [review]
patch, implement -moz-font-smoothing

Please:

 * change the name to -moz-osx-font-smoothing (with appropriate changes to the names of member variables).  I'm not especially tied to this name if you have something better, but I think it should indicate the property is Mac-only.  (I don't have a strong opinion on whether the DOM property should be MozOsxFontSmoothing or MozOSXFontSmoothing, but somebody else might.)

 * change the value name from antialiased to grayscale (with appropriate changes to the constants)

 * put the SetDiscrete call in nsRuleNode::SetFont inside a !mPresContext->GetCachedBoolPref(kPresContext_UseDocumentFonts) condition

 * make the property pref-controlled in nsCSSPropList.h, probably under a pref layout.css.osx-font-smoothing.enabled

 * add an #ifdef XP_MACOSX section of modules/libpref/src/init/all.js setting that pref's default to true on mac and false elsewhere

r=dbaron with those changes
Attachment #733206 - Flags: review?(dbaron) → review+
Keywords: css-moz, dev-doc-needed
Summary: Fonts in Firefox on OSX appear heavier than other browsers → Add CSS property for author control over antialiasing on Mac OS X, for cases where fonts appear too heavy
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #75)

>  * put the SetDiscrete call in nsRuleNode::SetFont inside a
> !mPresContext->GetCachedBoolPref(kPresContext_UseDocumentFonts) condition

Can you comment on the reasoning here?  Why is this necessary for this property but not other font-xxx properties?
Depends on: 898267
(In reply to John Daggett (:jtd) from comment #76)
> (In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from
> comment #75)
> 
> >  * put the SetDiscrete call in nsRuleNode::SetFont inside a
> > !mPresContext->GetCachedBoolPref(kPresContext_UseDocumentFonts) condition
> 
> Can you comment on the reasoning here?

The reasoning is that there's a user preference for users to turn off the ability of the page author to choose fonts.  I think the ability of the page author to choose antialiasing settings should also be disabled by this preference.

> Why is this necessary for this
> property but not other font-xxx properties?

I think we should do the same for font-feature-settings and maybe also the new font-variant-* stuff.
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #75)
>  * put the SetDiscrete call in nsRuleNode::SetFont inside a
> !mPresContext->GetCachedBoolPref(kPresContext_UseDocumentFonts) condition

per IRC discussion, I'm ok with skipping this bit
Also, especially given bug 898267, you should add a reftest.  The obvious != test should be fine; don't forget to fails-if(correct syntax for not mac).
Test white text on black background with and without osx-font-smoothing
Subpixel AA is apparently only available on 10.8 test machines.  Having at least one around will assure that backends maintain support for this.
Attachment #782389 - Attachment is obsolete: true
Attachment #782471 - Flags: review?(m_kato)
Attachment #782471 - Flags: review?(m_kato) → review+
Tryserver build available here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.com-6c134854f904/try-macosx64/firefox-25.0a1.en-US.mac.dmg

Given the changes requested in comment 75, usage is now:

  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;

This property will be available only under OSX and will ship with Firefox 25.
(In reply to John Daggett (:jtd) from comment #83)
> Tryserver build available here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.
> com-6c134854f904/try-macosx64/firefox-25.0a1.en-US.mac.dmg

Awesome! I've tested 25.0a1 with a few Icon-Font libraries, it looks great! Thank you so much!
Presumably the problem was the two close parentheses here when you wanted one:

>+skip-if(!cocoaWidget||OSX==10.6||OSX==10.7)) != osx-font-smoothing.html osx-font-smoothing-ref.html


I'm a little concerned to see that it's not tested on 10.6 or 10.7, though.

(And I'd actually prefer a fails-if rather than skip-if, so that we test that it doesn't do anything on other platforms.)
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #86)
> Presumably the problem was the two close parentheses here when you wanted
> one:
> 
> >+skip-if(!cocoaWidget||OSX==10.6||OSX==10.7)) != osx-font-smoothing.html osx-font-smoothing-ref.html
> 
> 
> I'm a little concerned to see that it's not tested on 10.6 or 10.7, though.
> 
> (And I'd actually prefer a fails-if rather than skip-if, so that we test
> that it doesn't do anything on other platforms.)

Argh, didn't see your comment before relanding.  For whatever reason, our 10.6/10.7 test farm machines render without subpixel AA, so the test and the ref will be equivalent in that case.  This is hard to test in general because of this sort of thing but the underlying API's haven't changed so I'm more concerned about new backends (e.g. Skia) not supporting the same behavior the cairo/azurecg backends do now.  Having at least hw config where that sort of thing will be detected is a good thing.

I'll write a follow-on patch to switch from skip to fail.
(In reply to John Daggett (:jtd) from comment #88)
> (In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from
> comment #86)
> > Presumably the problem was the two close parentheses here when you wanted
> > one:
> > 
> > >+skip-if(!cocoaWidget||OSX==10.6||OSX==10.7)) != osx-font-smoothing.html osx-font-smoothing-ref.html
> > 
> > 
> > I'm a little concerned to see that it's not tested on 10.6 or 10.7, though.
> > 
> > (And I'd actually prefer a fails-if rather than skip-if, so that we test
> > that it doesn't do anything on other platforms.)
> 
> Argh, didn't see your comment before relanding.  For whatever reason, our
> 10.6/10.7 test farm machines render without subpixel AA,

I'm curious about this (and a little concerned, given that I believe subpixel AA is enabled by default on OS X 10.6/7) -- do we know why the test machines aren't using it? I'm almost (though not completely!) sure we used to have subpixel AA in OS X reftests; if we've lost it along the way somewhere, then we may be testing a configuration that is significantly different from the default that most users have, for some reason.
https://hg.mozilla.org/mozilla-central/rev/9395e867ca3b
https://hg.mozilla.org/mozilla-central/rev/7be4586c3d91
https://hg.mozilla.org/mozilla-central/rev/8c1b1da5fb4a
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Thank you, thank you, thank you, thank you. :)
Thank you for implementing this with a user control so I can turn off the property without resorting to custom user styles.
The nightly build now contains support for the new '-moz-osx-font-smoothing' property:

  http://nightly.mozilla.org/

Support for this property is based on a pref, 'layout.css.osx-font-smoothing.enabled', which is on my default only for mac builds.  Users can disable support for the new property simply by setting this pref to 'false' in 'about:config'.  Authors should note that the values for this property differ slightly from '-webkit-font-smoothing'.  See comment 83 for details.

Please report any problems by logging new bugs that reference this bug.

Details of the release schedule for Firefox 25 can be found here:

  https://wiki.mozilla.org/Releases
Testcase linked to by the URL at the top of the page updated to show line-by-line comparison of an icon font with/without grayscale AA set.
I’ve just tested the property with the nightly build and found some unexpected behaviors.

Here is my test case: http://jsbin.com/azucok/1/edit

It’s not possible to turn grayscaling on/off for specific child elements. The first child seems to define how the rest of the text will be rendered.

I’m really thankful that this property has landed and I hope this will be fixed, too.
I’ve figured out that the bug has nothing to do with the first child but with the display property. Elements with display set to inline-block or block do behave correctly.

Test case: http://jsbin.com/ohuloj/1/edit
Depends on: 900975
Yes, this seems like a flaw in the implementation. I've filed it as bug 900975.
Check comment #93 while making release notes
Apologies, this didn't make the release notes due to an already dev-centric release. This should be noted on MDN, however.
relnote-firefox: ? → -
Blocks: 640134
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: