Re: A property for font antialiasing control on Mac OS X

On Wed, Jul 17, 2013 at 2:57 PM, L. David Baron <dbaron@dbaron.org> wrote:

> Abstract
> ========
>
> The -webkit-font-smoothing property changes the behavior of
> antialising on WebKit browsers on Mac, while having no effects on
> other platforms [5].  It is motivated by a desire to work around a
> bug in Mac OS X's subpixel antialiased font rasterization, which
> provides optimal results in some cases [2] but poor results in
> others [2].  Authors want Gecko, which doesn't implement
> -webkit-font-smoothing, to implement something similar [6].
>
> In this message I propose a strategy for having a single,
> cross-vendor property name for this functionality, but one that is
> still designed to be temporary, and designed not to use a property
> name that might be used for permanent features.  Since it is
> intended to be temporary, I do not believe the full W3C
> standardization process is necessary, but I think it should be
> discussed on this list.
>
> Background Reading
> ==================
>
> [1] http://www.usabilitypost.com/2010/08/26/font-smoothing/
> [2] http://www.usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/
>
> [3]
> http://lists.w3.org/Archives/Public/www-style/2012Oct/thread.html#msg14
>   particularly:
>     [4] http://lists.w3.org/Archives/Public/www-style/2012Oct/0014.html
>     [5] http://lists.w3.org/Archives/Public/www-style/2012Oct/0109.html
>
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=857142
>
> Use cases
> =========
>
> Antialising ("AA") of text, if done at all, can be done using
> subpixel antialiasing or grayscale antialiasing.  See [2] for more
> details.  As described in [5], the subpixel antialising on Mac OS X
> has a tendency to make the font outlines appear substanially bolder
> than intended.
>
> The most significant use case for author control is that while
> subpixel antialiasing (on all platforms) often provides the best
> results for body text [2], its implementation on Mac OS X has a
> tendency to make light text on a dark background overly or even
> unreadably bold [2].  This problem is fully cross-browser on Mac OS
> X, in that all browsers on Mac OS X using the native text
> rasterization code (all major browsers, I believe) run into this
> problem.  In other words, there are many cases where subpixel AA is
> preferable, but also a number of cases where it produces very bad
> results that authors want to avoid.
>
> A second use case for author control is to avoid "popping" that
> occurs when the browser might naturally switch between subpixel AA
> and grayscale AA.  On Mac OS X, such a switch produces a visually
> noticeable change in boldness.  However, this problem is not as
> fully cross-browser, since the cases where such popping would occur
> vary between browsers, depending on how good they are at things like
> using surfaces with per-component alpha when needed (since
> per-component alpha is needed to represent a surface containing
> subpixel antialiased text with a transparent or partially
> transparent background), or doing analysis of whether what is
> underneath text is opaque.  Nonetheless, authors sometimes wish to
> disable subpixel AA in text that they know is likely to go through
> dynamic changes that trigger this popping in at least some browsers.
>

Other cases where you might want to turn off anti-aliasing:
- animations
when animating text, you don't want to anti-alias because of performance
and also because subpixel AA will cause "jiggling" of characters when you
move a text run
- content that will end up in a 3d transform
- match canvas text
Text in canvas never uses subpixel-AA (although there are some browsers
that allow it) and an author might want to match HTML text with Canvas text


>
> Some authors have also argued that icon fonts are also a use case.
> I disagree with this; I think icon fonts are a hack -- using a
> feature (text rendering) for something other than its intended use.
> I think text rendering should be optimized for its intended use.  If
> it happens to be usable for other things, fine, but I don't think we
> should optimize it for those things, especially when those other
> things may have substantial other disadvantages, e.g., in
> accessibility or searchability.
>

I fully agree!


>
> Temporary Web feature
> =====================
>
> Despite the significant demand for this control, the demand is
> inherently temporary.  It is demand for a workaround for a bug in a
> specific OS -- an OS that lots of designers use and care about, and
> that does particularly well in high-end markets.  I think we should
> presume that this demand is temporary and this bug will be fixed at
> some point in the future.  When that happens, I'd like to be able to
> remove this feature from the Web platform.
>
> I propose trying to achieve this by (1) implementing the control in
> a way such that it is only exposed on Mac and (2) documenting that
> the feature is intended to be temporary and may be removed in the
> future.  It's possible that this will fail, but I think it's worth
> trying.
>
> By only exposed on Mac, I mean more than the current WebKit behavior
> of -webkit-font-smoothing, in which the property appears in the
> object model on all platforms, but only has an effect on font
> rasterization on Mac OS X.  I mean, instead, that the property
> **should only appear in the object model on Mac OS X**.  This would
> mean that there will always be browsers on which the property does
> not exist in the object model, which will reduce the chance of Web
> pages depending on its presence.
>
> I recognize that this experiment to make a feature intentionally
> temporary with the intent to remove it in the future might not
> succeed.  I still think it's worth trying.  If it fails, we'll end
> up with a permanent feature in the Web platform, which isn't a
> disaster; we have many other features in the Web platform that we
> dislike but are stuck with for compatibility.
>
> Property and value naming
> =========================
>
> I'd like the name of this property to reflect that it is
> operating-system specific.  Such a name would help provide a clue to
> its temporary nature, and will also make it far less likely to
> conflict with other names that the CSS Working Group might want to
> use for standardization in the future.  Names I would consider (in
> order of preference) are:
>   mac-font-smoothing
>   osx-font-smoothing
>   macosx-font-smoothing
>   coregraphics-font-smoothing
>
> I would prefer this to be done without a vendor prefix, since the
> property will be implemented by multiple vendors.  I don't want each
> vendor implementing it to have to use its own vendor prefix (adding
> to the burden for authors, and increasing the risk of more
> browser-specific content), nor do I want to introduce the precedent
> of one browser implementing another browser's prefixes (which
> increases the chance of baking those prefixes into the Web platform
> permanently, which is even uglier).
>
> I also don't think the namespacing aspect of vendor prefixes is
> needed here because these aren't names that the working group would
> want to use in the future; they're clearly specific to an operating
> system.
>
> As far as values go, the use cases I present above only provide use
> cases for two values:
>
>   auto (initial value, equivalent to -webkit-font-smoothing: auto)
>
>     User agents are permittent to use any type of antialiasing
>     (including not doing antialiasing at all).
>
>   grayscale (equivalent to -webkit-font-smoothing: antialiased)
>     (alternative names:  only-grayscale, grayscale-only)
>
>     User agents are permittent to use any type of antialiasing other
>     than subpixel antialiasing (including not doing antialiasing at
>     all).
>
> I don't see a use case for making the values requirements rather
> than maxima (in other words, values that set the maximum type of
> antialiasing allowed, under the model that subpixel > grayscale >
> none).  I also don't see the use case for a 'none' value that would
> disable any type of antialiasing.
>

Maybe for background-clip you might want the text to be a hard clip and not
antialiased?


>
> Moving forward
> ==============
>
> Because of both the proposed temporary nature of this property and
> the proposed name (which does not occupy a part of the namespace
> that the working group is at all likely to use), I don't think this
> property needs to go through the full W3C process.  Nonetheless, I
> would like to get some amount of agreement on this mailing list
> about the approach.
>

Because of transition, animations and 3d transform, I don't believe that
this will be a temporary solution (unless of course display technology
advances so much that subpixel-AA is no longer needed)


>
> I'm particularly interested in what others think of this and whether
> other browser vendors on Mac OS X (WebKit, Blink) would be willing to
> implement both one of these names and to implement the
> platform-dependent object model aspect.
>
> I'd also note that I think this is an unusual case:  an operating
> system bug that both not reasonable for browser vendors to work
> around and also prominent enough that Web authors wish to work
> around it.  Under the maxim
> http://en.wikipedia.org/wiki/Hard_cases_make_bad_law I'd suggest
> that we avoid drawing too much precedent from this unless we find
> that it really turns out to be a recurring pattern.
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>
>