W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: [css-fonts] selecting color or monochrome glyphs for emoji fonts

From: Behdad Esfahbod <behdad@google.com>
Date: Thu, 21 Aug 2014 17:28:39 -0400
Message-ID: <CAOY=jUT=FPfuiEs3f-dQ1JXJP+cHAah+3i6Gf5VBAm74OoUBqA@mail.gmail.com>
To: Jonathan Kew <jfkthame@gmail.com>
Cc: John Hudson <tiro@tiro.com>, Cameron McCormack <cam@mcc.id.au>, John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>, public-webfonts-wg <public-webfonts-wg@w3.org>
On Thu, Aug 21, 2014 at 5:11 PM, Jonathan Kew <jfkthame@gmail.com> wrote:

> On 21/8/14 21:40, John Hudson wrote:
>
>> On 21/08/14 1:21 PM, Behdad Esfahbod wrote:
>>
>>  I'd rather CSS doesn't go down that path.  CSS doesn't specify whether
>>> fonts should be hinted, use embedded bitmaps or not, render as subpixel,
>>> grayscale, etc.  It's out of the scope IMO.
>>>
>>
>> I'm in two minds on this. My first instinct was the same as Behdad's:
>> that this is a font rendering issue, and not an obvious candidate for
>> CSS level authoring control. However, we do expect CSS to be able to
>> control colour display of many page elements, including monochrome text.
>>
>
> I think the choice between text-style and emoji-style rendering is a
> legitimate option in page design that should be available to authors.
> Whether the already-available (if not yet widely supported) Unicode
> variation sequences are sufficient for this, or whether a CSS property such
> as John proposed is a worthwhile addition is a further question.
> Personally, I'm inclined to favor it.
>
> Such a property would allow authors or designers to influence the default
> rendering of these characters in the absence of variation selectors, and
> without needing to explicitly provide or specify particular fonts.
>

I think font-variant-color is one thing, choosing between text or emoji
style is another.  font-variant-color equally applies to any character.
 Text vs emoji on the other hand is a matter of enforcing variation
selectors to text, and has a completely different implementation than
preferring fonts with or without color.


> The defined variation sequences, when used, should (IMO) take precedence,
> so that we'd have:
>
>   U+2615         HOT BEVERAGE (rendered in text or emoji style
>                                according to font-variant-color)
>   U+2615 U+FE0E  HOT BEVERAGE (text style)
>   U+2615 U+FE0F  HOT BEVERAGE (emoji style)
>
> An explicit choice of "text style" or "emoji style", whether a result of
> variation selectors or of font-variant-color, would serve as an input to
> the font selection process, so if a font specified in font-family does not
> support the requested rendering style, the UA would attempt to find some
> other font (later in the font-family list, or using system-wide font
> fallback) that can support the requested style.
>
> OTOH, if neither of these mechanisms is used to explicitly choose a
> rendering style, the first font in font-family that can render the
> codepoint would be used.
>
>
>  While I can see the point of John's proposed font-variant-color
>> property, I'm actually more interested in possible CSS interaction with
>> colour font technologies that enable user-defined colour values for
>> polychromatic glyphs. For example, the Microsoft CPAL table spec allows
>> for user defined palettes, and CSS seems to me an obvious place to
>> provide for author definition of colours.
>>
>
> Yes; but that's an entirely separate topic.
>
> JK
>
>
Received on Thursday, 21 August 2014 21:29:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC