W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2017

Re: [csswg-drafts] [css-fonts][css-text] Variation Selection of Colorful (Emoji) or Monochrome Glyphs

From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Mar 2017 18:41:26 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-285129212-1488998484-sysbot+gh@w3.org>
A related issue is whether specifying fill/stroke for text should override full-color emoji substitutions.  Browsers are inconsistent with SVG text; I haven't tested, but I suspect the same is true with the `-webkit-` text fill/stroke properties.  

As I've argued elsewhere, extending `fill` & `stroke` to non-SVG text is going to need a property that switches between painted vs monochrome text (because the initial value for `fill` is black, not currentColor).

That painted-vs-monochrome switch would make sense integrated into the emoji-vs-monochrome switch, so the options would be:

- monochrome (glyphs that will be painted with currentColor)
- full color (from the font) — possibly this should be two values, one requiring support for custom color palettes, one accepting a default colored glyph
- fill and stroke paint (which assume a monochrome glyph shape from the font, ideally a vector although I think most renderers also support monochrome bitmap fonts)
- auto (for most characters: use the first font, in color if available; for emoji characters: look specifically for a full-color glyph).

A user agent style rule would set `svg` elements to the fill-and-stroke mode.

The definition of "emoji characters" for `auto` would be based on Unicode character classes, adjusted by Unicode variation selector codepoints in the text.

GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/352#issuecomment-285129212 using your GitHub account
Received on Wednesday, 8 March 2017 18:41:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:09 UTC