Seriously—that’s how you get small caps and swash? Seriously?? These look like optimization flags for a C compiler, not CSS.
I’m guessing that these are probably mapping through to the underlying OpenType features directly somehow to support arbitrary aspects of a particular type, but it still needs to be less of a mess for the “normal” stuff.
Why can’t it be something readable and self-documenting?
Actual implementations are currently CSS extensions as the functionality is not yet in a published spec.
Mozilla's CSS extension uses the syntax:
Microsoft's CSS extension however uses the same syntax as the current W3C draft, expect with the standard browser specific prefix used before a feature makes it into the official spec.
-ms-font-feature-settings: "kern" 1;
Whether this syntax is ideal or not is still, imho, contestable. Either way it isn't Mozilla's parameter-esque style (which I agree stands very much in opposition to the usual CSS syntax style), and as long as the syntax in the draft reaches finalization, said parameter-esque syntax should go away for good.
There's a trend towards lists in new CSS values (see transforms, transitions, etc.), but this seems to go against making site styles easily customizable using cascading/inheritance. It is a bigger pain to programmatically control. How about one value for one property:
font-caps: small; /* or none */
font-swash: contextual; /* or none */
This also gives room for future flexibility in values.