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

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