Hacker News Reader

Comment by codyrobbins | Hacker News Reader

I am completely, wholeheartedly, emphatically, and unabashedly in favor of finally bringing control over OpenType features to CSS—finally!!

But this syntax they’ve come up with is an absolute horrifying mess. Ugh. Please say it ain’t so!

  font-feature-settings: "smcp=1”;
  font-feature-settings: "swsh=1,cswh=1”;

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?

  font-features: small-caps, contextual-swash;

View on HN

According to the CSS3 Fonts spec linked in another comment, you get small-caps with:

    font-variant-caps: small-caps

...and contextual alternates (such as swashes) with:

    font-variant-alternates: contextual

If you want to configure a bunch of variations at once, there's a short-hand property:

    font-variant: contextual small-caps

The font-feature-settings option is only there for the wild and crazy OpenType features too esoteric to have CSS attributes.

Actually not. In the current W3C draft (http://www.w3.org/TR/2011/WD-css3-fonts-20111004/#font-featu...) the syntax for font features is as such:

  font-feature-settings: "kern" 1;

Actual implementations are currently CSS extensions as the functionality is not yet in a published spec. Mozilla's CSS extension uses the syntax:

  -moz-font-feature-settings: "kern=1";

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.

Both are horrible. Mozilla's because the string is a transparent blob that's parsed separately to the rest of the CSS syntax and Microsoft's because it's dependent on ordering.

I don't see why a boolean value wasn't an option; the values is either defined or it's not. Otherwise "kern(1)" would have been more consistant with other properties.

I don't know what mozilla is doing but at least IE has improved since "filter:progid:DXImageTransform.Microsoft.AlphaImageLoader (src='images/image.png',sizingMethod='scale');"

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.

Unfortunately there are lots of OpenType features without a good representative name.

http://en.wikipedia.org/wiki/List_of_typographic_features

As thristian points out, font-feature-settings should be a last resort for rarely-used features without a separate syntax. It is not meant to set all features down.

So make one up, but there's no excuse for 4-letter abbreviations replacing six-letter words.

Or no commas, similar to transform: font-features: kern(0.5px) ligatures small-caps;

Reply on news.ycombinator.com