- From: DeeDeeG via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Feb 2018 01:56:46 +0000
- To: public-css-archive@w3.org
Thanks for the corrections and comments. Summary of this comment: If browser vendors check per-font instead of per-glyph, this gets a lot easier. That passes my mental "can it be done" test. In current practice, font vendors delivering "explicit-color" font data *always* deliver it in a designated "color font", as far as I've seen. (As in, "Here's this cool font. it has explicitly-designed multi-color glyphs! [or colorful emojis.] wow!" like it's the main distinguishing feature of the font. And it happens not to be mixed in with traditional outline "inherited color" stuff except maybe as a fallback.) So I think color features could be detected on a per-font level, and fonts themselves could be designated "text-[only]" or "graphic" (or whatever the names end up being...). That makes the needed code simpler. It makes it a one-off font sorting task before font selection, and avoids having to do many checks of whether individual glyphs are "explicit color." Browser vendors in that case would essentially be saying: >If you include one glyph with explicit-color technology in your font, please don't make your font predominantly black/white (or "inherited color"), because it'll confuse our CSS implementation into thinking your font is mostly for explicit-color purposes and we'll treat it as such. Or if browsers want to, they could set up some threshold for how much "explicit color" content there can be before the font flips over into the "graphic", "fancy", "rich" whatever category... My point is, implementing this sounds *possible* at least. -- GitHub Notification of comment by DeeDeeG Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1092#issuecomment-363976927 using your GitHub account
Received on Thursday, 8 February 2018 02:05:39 UTC