- From: DeeDeeG via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Feb 2018 16:49:24 +0000
- To: public-css-archive@w3.org
Hi all, I hope it's not too late to bring this up: Given that the technical aspects this property would depend on, and the aspects of font tech it would toggle on/off, are *not* emoji-specific, I'd like to suggest the Working Group consider *not* limiting the property to emoji only. I think the approach in this draft property is just as good a match for generally toggling on/off new color font tech for all text (all codepoints), rather than being emoji-specific. I also laid out my reasoning below. --- As far as I can tell, a "baked-in" (`graphic`) /"inherited" (`text`) / `auto` color split is what this property is looking like it will specify. Given how broadly applicable a "baked-in color" (`graphic`) / "inherited color" (`text`) logical split is (beyond emoji), it seems like there is a nice opportunity to apply the property for text in general, rather than limiting it to just emoji. The fonts that web authors currently work with are generally OpenType (and all the new "color font" formats are OpenType). And the color font formats in OpenType are designed to seamlessly host both emoji and whatever other arbitrary multicolor content authors want to include. So it seems unnecessarily complicated to check if a codepoint is emoji before applying this property. It also seems like this draft is effectively going out of its way to make the property do less, not more. The case I could see for keeping it limited to emoji are: 1) usage of this property might turn out to be emoji-specific for this property, and in that case matching author expectations/demand could make the property a better match to authors' expectations of how it will work 2) narrow scope may have a smaller "domino effect" impacts on font rendering implementations, (narrower performance implications, cause fewer adjustments to existing web dev habits) 3) A meta-reason: The working group has already decided on the property name, too late to change it now? Some more of the case for broadening this to handle text in general: 1) It seems like it's already been decided not to override Variation Selectors (VS-15, VS-16) so there's not much tying this down to needing to be an emoji-only feature. (Ignoring VS-15 and VS-16 is another GitHub issue, which seems to be separate from this draft property) 2) From an implementation perspective, doing this for all code points woud be *simpler* than only doing it for emoji code points (although applying it over potentially more text could make it worse for performance?? speculating here.) 3) Doing it more-broadly now addresses more use-cases; Down the line, an emoji-specific version of this property might overlap with a future, broader CSS property for controlling (not necessarily emoji) baked-in-color vs inherited-color content. -- GitHub Notification of comment by DeeDeeG Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1092#issuecomment-364489922 using your GitHub account
Received on Friday, 9 February 2018 16:49:32 UTC