3 ms·

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

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;

pdenya 15y ago
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');"
zethraeus 15y ago
Actually not. In the current W3C draft (http://www.w3.org/TR/2011/WD-css3-fonts-20111004/#font-feature-settings-prop 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.
- underwater 15y ago
  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.
thristian 15y ago
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.
ronaldj 15y ago
Or no commas, similar to transform: font-features: kern(0.5px) ligatures small-caps;
lifthrasiir 15y ago
Unfortunately there are lots of OpenType features without a good representative name. http://en.wikipedia.org/wiki/List_of_typographic_features 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.
- hessenwolf 15y ago
  So make one up, but there's no excuse for 4-letter abbreviations replacing six-letter words.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
tumultco 15y ago
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.

pdenya 15y ago

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');"

zethraeus 15y ago

Actually not. In the current W3C draft (http://www.w3.org/TR/2011/WD-css3-fonts-20111004/#font-feature-settings-prop 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.

underwater 15y ago
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.

thristian 15y ago

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.

ronaldj 15y ago

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

lifthrasiir 15y ago

Unfortunately there are lots of OpenType features without a good representative name. http://en.wikipedia.org/wiki/List_of_typographic_features 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.

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

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

tumultco 15y ago

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.