A property for font antialiasing control on Mac OS X

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.

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.

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.

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.

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/   𝄂

Received on Wednesday, 17 July 2013 21:58:02 UTC