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.)