[css-fonts-4] Should font-variant-emoji be included in the font-variant shorthand?

[jfkthame]

The spec text for the font-variant property says that it

is a shorthand for all font-variant subproperties

and its value syntax almost reflects this.

However, it does not include the keywords auto | text | emoji | unicode that would be the possible values of font-variant-emoji as specified in the Color Font Support section of the spec.

Is this an accidental omission that should simply be added to the font-variant values, or is font-variant-emoji not supposed to be a subproperty of font-variant, despite its name?

My current opinion: the -emoji values should be supported by the font-variant shorthand; they don't clash with values of any of the other subproperties, and I think authors would naturally assume this should work.

However, this does raise the point that all the other font-variant subproperties have the initial value normal, so that it's very natural for font-variant: normal to set them all to their initial values of the same name. But font-variant-emoji is currently specified to have initial value auto, and has no normal. It would still be possible for font-variant: normal to reset it to its initial value (auto), but this suddenly seems less intuitive. So I wonder if we should rename this value to normal for consistency with the other font-variant-* subproperties? (As far as I'm aware, no-one has yet shipped support for font-variant-emoji, so renaming the value should be possible without compatibility concerns.)

[jfkthame]

Pinging @litherum @svgeesus @nattokirai as editors of Fonts 4 ... was this just an editorial oversight, or is it an issue that needs a CSSWG discussion to sort out?

[svgeesus]

I believe this was an oversight, we forgot to update it.

I think renaming auto to normal as you suggest makes sense, but would like to hear from others.

[litherum]

Yeah, font-variant-emoji came later, doesn’t use the same implementation mechanism as the rest of the font-variant longhands, and used to be named something like emoji-presentation (but got renamed to its current name).

I don’t know why it got renamed to its current name. As things lie now, I don’t think I have an opinion on this shorthand issue.

[jfkthame]

font-variant-emoji ... doesn’t use the same implementation mechanism as the rest of the font-variant longhands ...

Agreed, from an implementation POV it's rather different; however, I think that from an author's POV using font-variant-emoji to choose between presentation styles for symbols is very similar to using font-variant-numeric to choose between lining and oldstyle numerals, or using font-variant-east-asian to choose between traditional and simplified forms.

So to my mind, the font-variant-... naming makes sense for this feature, and given that name, it seems like it should be included in the shorthand.

(I don't care strongly one way or the other, really, this just seems most logical to me. But mostly, I'd like the spec to be clear on it so that we all know what to expect.)

[svgeesus]

I agree with @jfkthame that from an authoring point of view it is consistent with the other font-variant properties and thus, the renaming that happened was correct.

I therefore think it should be included in the shorthand, and reset when the shorthand is used.

I also (still) think we should auto -> normal for consistency.

[svgeesus]

used to be named something like emoji-presentation (but got renamed to its current name).

I don’t know why it got renamed to its current name.

It used to be called font-presentation and was changed because that name sucked. This was the issue where we changed it

• [css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji) #1092

[svgeesus]

I believe this was an oversight, we forgot to update it.

Indeed, the previous CSS WG discussion where we changed the name did not consider the impact on the shorthand at all (it was mostly about the values, which we didn't resolve on until later).

[svgeesus]

We didn't get to this on today's call, can we resolve here in the issue?

@jfkthame suggested three things:

1. was the renaming to font-variant-emoji a correct decision
2. if so, should it be added to the font-variant shorthand
3. and also if so, should auto be changed to normal like all the other font-variant-* longhands

My answers to that are yes, yes, and yes. It was just an editing oversight that this wasn't already done.

@litherum stated they don't have an opinion on 2. And it was their issue that resulted in 1.

@litherum any opinions on 3. ?

[litherum]

I have no opinions.

[svgeesus]

Hearing no objections, I plan to make the edits as @jfkthame suggested.

[cdoublev]

@svgeesus, can you please update the initial field from auto to normal?

csswg-drafts/css-fonts-4/Overview.bs

Line 6612 in a2e50cb

Initial: auto

EDIT: fixed by 87a2abd.