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



On 7/17/13 2:57 PM, "L. David Baron" <dbaron@dbaron.org> wrote:

<snip>
>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'd be more inclined towards osx-font-smoothing or macosx-font-smoothing;
mac is too general (one can run other OSx on Mac hardware) while
coregraphics requires more typing without adding much value.

>
>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).

+1

>
>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.

Is there any basis to the assumption this would be temporary? Has Apple
offered any clues they might address this?

Fwiw I'm not overly fond of the idea of adding CSS properties to work
around OS-specific issues, though I understand this is already an
established -webkit fact on the ground i.e. it really is a cross-browser
compat fix for OSX. I'd still feel better if this came with some signals
from Apple that they do intend to take steps that will allow this feature
to be removed in a reasonable time frame.

>
>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.

Understood, though I still think the WG should attempt to ascertain
whether this is temporary or not. I wouldn't object either way, it'd just
be better to know what we're signing up for upfront.

>
>-David
>
>-- 
>𝄞   L. David Baron                         http://dbaron.org/   𝄂
>𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>

Received on Thursday, 18 July 2013 01:59:59 UTC