[csswg-drafts] [css-fonts-4] font-presentation property lacks an unopinionated, standardized default

DeeDeeG has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts-4] font-presentation property lacks an unopinionated, standardized default ==
### Background

This issue is regarding the draft "font-presentation" property, which specifies how to handle text-style or emoji-style rendering of otherwise ambiguous, "emoji-or-text" code-points.

(background from Unicode: http://unicode.org/reports/tr51/#Presentation_Style)

Draft: https://drafts.csswg.org/css-fonts-4/#font-presentation-desc

With this draft property we have 3 values: 
>Value:  auto | text | emoji

and auto is the default:

>Initial:  auto 

Auto is understandably rather flexible, allowing the browser some discretion with how to render emoji code-points and still be compliant with the spec. This lets platforms innovate more readily, or project their desired brand image/make style choices as they wish. (Indeed, the entire `auto` value is defined with MAY statements, and can behave fully arbitrarily and still be *technically* compliant with the draft spec.)

Unfortunately, though, users must specify that they broadly prefer text presentation, or that they broadly prefer emoji presentation, in order to be guaranteed any actually standard behavior. (i.e. `font-presentation:text`, or `font-presentation:emoji`).What if a web author just wants a standard default, and decides to follow the Unicode guidance? Right now the author must "pick a side" (text or emoji default) or expose themselves to deliberately unstandardized implementations of `font-presentation:auto`. Where is the "just make it work" aka "just follow the Unicode spec" option?

### Suggestion

I would advocate for an additional ("strict," or "unicode," etc. whatever name) value for the `font-presentation` property, which behaves as follows: the browser first understands any VS 15 to mean text presentation, understands any VS 16 to mean emoji presentation, and then otherwise falls back on the default guidance by Unicode. This allows developers to count on a sane default, and banish platform inconsistencies, without having to be opinionated about wanting to err on the side of text or err the side of emoji. And to put it another way, allows content authors to have the option to consistently follow the Unicode guidance.

One could apply `font-presentation:strict` to the \<body> and have access to easy standardized emoji behavior throughout their site, in a general-purpose kind of a way. One line of css and you're done.

Ideally `auto` might come to be seen as the "integrate better with the platform/browser" option, and `strict` could be seen as a no-fuss unbranded fully-standard choice.

### Issues

- This kind of shoots `auto` in the foot, making "strict" seem like the obvious choice for content authors in my opinion. But it's hard to predict what browser vendors would do with `auto`, and hard to predict web content authors' choices, so I don't really know.

- `auto` and `strict` might be too similar, or identical, if browsers follow the standard guidance for `auto`. They might not be distinctly useful apart from one-another. 

- `strict` would be the only value requiring knowledge of the Unicode default presentations of emoji, so slightly more technically complex to implement. Browsers might not find this worthwhile enough to implement, option to just support the other values. Or might be the part of the spec with the most typo-related bugs in browsers. Or default presentation list might become out of date with new unicode versions, etc.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1223 using your GitHub account

Received on Saturday, 15 April 2017 11:22:51 UTC