- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Feb 2018 17:49:15 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `[css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji)`, and agreed to the following resolutions: * `RESOLVED: No change for issue #2304` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji)<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1092<br> <dael> myles: This topic was discussed a few weeks ago but a commentor brought up new points. Because previous issue was resolved we moved to a new issue. So jsut the new parts.<br> <dael> myles: THis is a property that renders characters as if they have variation selectors. This property sets the default so if you don't have a selector CSS can say emoji or text style<br> <dael> myles: Question was if this property should effect color fonts.<br> <dael> myles: Color font formats have been increasingly common. The request was...the CSS should be able to turn those on and off.<br> <dael> myles: THat's the background. ANything anyone wants to say before I give an opinion?<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/2304<br> <dael> myles: Should we allow the selector to effect regular color fonts?<br> <AmeliaBR> q+<br> <dael> myles: I haven't heard an author say they used color fonts accidently. Person raising this hasn't brought a case where this is needed, jsut that it's easy to impl.<br> <dael> myles: I haven't heard an author need. Also there isn't full itnerop on varation selectors and if we added more sematics it would limit our ability to standardize. THis issue is not motivated and would hinder standardization.<br> <Rossen_> ack AmeliaBR<br> <Rossen_> bradk, lol<br> <dael> AmeliaBR: On the question of is there a use case. When it comes to color web fonts I don't think anyone is using and wanting to turn them of fin general. When it comes to native emojis there is an issue where we have inconsistancy as to how to handle interaction of fill and stroke with a native color font like and emoji<br> <tantek> uh, turning off color (or picking different contrasts) is a pretty accepted a11y use-case<br> <dael> AmeliaBR: As color fonts become more common it might be useful to use a font consistantly but turn off the color for cetain elements. But I don't have as much of a use case as I do for the emoji.<br> <dael> myles: That's a good point. It is important that we should spec interaction between fill/stroke and the color fonts.<br> <dael> myles: THis proposal could go 2 ways. Way #1 is this would effect font selection and you'd just turn off the color parts. Option #2 is when you select font you skip the color. This was about option 2 but it sounds like you're interested in 1.<br> <dael> myles: Main concern with turning off tables in the font file is 1 that we don't have a presedent. and 2 is if they want the color to work it's possible using 2 of the font formats.<br> <liam> +1 to tantek but not clear that's at the font level but at the UA level overall<br> <dael> myles: Lastly color is part of the design of these fonts. If you took the color out it would hamper the design and the font would be useless. I list fonts in the issue where you can't remove the color. It would be unfortunate for users to...it would lead to confused users.<br> <dael> AmeliaBR: Many of these color fonts are shipping with fallback plain outlines. BUt some aren't. If the font has a built in monochrome fallback it seems logical to allow web page authors a way to access it. If there is no fallback logical is to fallback to a different font. It's hard to integrate both into the font selection algo.<br> <dael> myles: Yeah and this is a case where the browser should be in the business of looking at hte outline and say if it should be able to be used.<br> <Rossen_> +1 to what myles said<br> <dael> myles: And the fallback is requred, there has to be a table. but the contents may be empty or garbage.<br> <dael> Rossen_: I agree with myles. I want to see if there are any other options or idea.<br> <fremy> @myles: just throwing a random idea here, how about we render the glyph, convert to grayscale, and use this an opacity mask on a background of the color of the "color" property?<br> <dael> Rossen_: From IRC I want to voice tantek's point about this being a a11y lever. I agree with liam this shouldn't be the thing of font selection. We normally handle high contrast etc. on a much higher level for style or a lower level for color inversion.<br> <dael> Rossen_: Back to myles what do you want to do? Close no change?<br> <dael> myles: Right.<br> <dael> Rossen_: ANy objections or alternative proposals?<br> <tantek> Rossen: TBH it's both system level and app/site level. e.g. both mobile OS's and mobile sites have "night mode" features that alter such things<br> <dael> AmeliaBR: If we close no change we keep this property that will only effect on the specific unicode characters designated as having plain text or emoji presentation?<br> <dael> myles: Right<br> <dael> AmeliaBR: And it would effect font selection to render those characters?<br> <dael> myles: It might. That's why I phrases the property as I did. In mac and iOS it does. I believe on every platform it might effect font selection.<br> <dael> Rossen_: Does that answer you AmeliaBR ?<br> <dael> AmeliaBR: Pretty much. I still agree it would be nice to have a toggle to turn off color font on generic text but I realize right now use cases aren't clear.<br> <dael> myles: If a web author wants to turn off color font they should remove it from the font family list.<br> <dael> AmeliaBR: I htink we need to wait in see how things like font variations and ways to work with existing font files. Like people making color and monochrome and swapping between the two. It's still hypotetical.<br> <dael> myles: That tech doesn't exist for any font format right now.<br> <dael> Rossen_: Okay, objections to resolve no change?<br> <dael> Rossen_: If there are more compelling use cases or additional information we'll of course reconsider.<br> <dael> RESOLVED: No change for issue #2304<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2304#issuecomment-369323232 using your GitHub account
Received on Wednesday, 28 February 2018 17:49:20 UTC