top | item 3443942

The New Web Typography

327 points| cleverjake | 14 years ago |ie.microsoft.com | reply

132 comments

order
[+] codyrobbins|14 years ago|reply
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;
[+] thristian|14 years ago|reply
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.
[+] zethraeus|14 years ago|reply
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.
[+] pdenya|14 years ago|reply
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');"
[+] tumultco|14 years ago|reply
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.
[+] ronaldj|14 years ago|reply
Or no commas, similar to transform: font-features: kern(0.5px) ligatures small-caps;
[+] Jabbles|14 years ago|reply
This is what I want! Not nice fonts, but competition!

Microsoft stepping up and implementing desirable features in their browser is exactly what we (as users of the web) need in order to move technology forward.

In the same manner, I hope Microsoft pushes hard with Windows Phone; not because I own one, but because I want the whole industry to move forward faster.

[+] ComputerGuru|14 years ago|reply
Guys, the sections change to display the actual features when you hover over them with the mouse.

I literally spent the better part of 5 minutes reading the text and comparing Chrome, IE, and Firefox to search for the kerning changes and fractions support, because I just couldn't see it.. Until I accidentally hovered over the sections and the content changed to match.

[+] kgen|14 years ago|reply
I agree, had no idea what was going on (figured I didn't have IE so it wouldn't show) until I read your comment.

Some of the examples are too subtle for this flashy animations (like kerning) and some just look bad (like the word affluent in ligatures).

Otherwise, pretty cool to see though.

[+] michaelmior|14 years ago|reply
Odd, no hovering necessary for me. Perhaps it's changed since.
[+] sc00ter|14 years ago|reply
"If you want the real deal, get a browser that supports OpenType like Internet Explorer 10+ or Firefox 8+."

Downloads IE10... "Windows Internet Explorer Platform Preview is only supported on Windows 8 Developer Preview." Oops!

PS. Microsoft: This -> / isn't a backslash, this -> \ is. (A common mistake, but not one I'd expect in article on Typography.)

[+] pornel|14 years ago|reply
It's nice that they suggest Firefox though. For me it's a refreshing change from demos that force me to use Chrome merely because they use User-Agent sniffing or only -webkit- prefix.
[+] nitrogen|14 years ago|reply
Fractions created with the backslash character can be clunky and confusing. With the Fraction property turned on, backslash-based fractions can be automatically transformed into true fractions.

If an article about typography doesn't even know the difference between a slash and a backslash, how are we ever to get people to stop saying backslash when talking about URLs?

http://public.wsu.edu/~brians/errors/backslash.html

[+] mbq|14 years ago|reply
BTW, this feature is a complete fail -- say I write 3431/5147, and what do I get? 343(1/5)147, so not only still ugly, but also incorrect mathematically.
[+] Aramgutang|14 years ago|reply
I've always disagreed with the whole "leans forward/backward" logic. I feel that a slash is a character that you draw by moving your pen _forward_ along the page, while a backslash is drawn by moving your pen _backward_. I guess the added problem with that is that probably not all people start drawing slashes from the top.

I should add that my opinion doesn't stop me from using the correct term in conversation.

[+] ned|14 years ago|reply
So it seems like we now have two way of specifying small caps:

  font-feature-settings: "smcp=1”;
and…

  font-variant: small-caps;
The later is the CSS 2.1 syntax, and will force the browser to create small caps on its own if the chosen font doesn't contain small caps glyphs.

The Open Type version is probably better, since it falls back to lower case glyphs if the browser doesn't support them, instead of an emulated version that probably won't be very legible.

[+] stan_rogers|14 years ago|reply
There was also an existing CSS implementation of ligatures:

  font-variant-ligatures: [ common-ligatures | additional-ligatures | historical-ligatures | normal | inherit ];
See http://marc.baffl.co.uk/browser_bugs/css-ligatures.html for a working example. Webkit seems to ignore it; Gecko has an incomplete implementation (common-ligatures works).
[+] wlievens|14 years ago|reply
I was reading this, thinking really nice, adhering to such meticuluous styling.

Then I saw this was microsoft. My mouth literally[1] fell open.

[1] I know what that word means

[+] tptacek|14 years ago|reply
Microsoft has an extremely respectable collection of typographic talent, and (matter of opinion, obvs) actually has done a better job with the fundamentals of typography over the last 10 years than Apple. Microsoft: several highly credible new screen faces. Apple: Market Felt as the typeface for notes on the iPhone. Hm.
[+] avolcano|14 years ago|reply
While I take issues with some elements of Metro, it's definitely a style that puts typography front and center. That, combined with some great fonts coming out from (or at least licensed by) Microsoft, shows that they have the ability to be a stylistic powerhouse - at least, when it comes to text.
[+] duhoang|14 years ago|reply
This is rad, but Microsoft handling of fonts in their browser is so terrible in the past that I hesitant to jump on this bandwagon.

They got a long way to go to convince designers to take them seriously.

[+] deepkut|14 years ago|reply
I'm with you here duhoang--

This may or may not make some designers' lives easier considering some of these additions are not cross-browser compatible.

[+] jorisw|14 years ago|reply
Exactly. Any lead Microsoft wants to take on the Web, I will have a hard time ever taking seriously given their history of anything Web related.
[+] spiralganglion|14 years ago|reply
"Once-inaccessible design features such as small caps, swashes and fractions are now access through CSS"

On a website drawing attention to type, one should be extra attentive to the content of their writing.

It'd be just like grossly aliased images on Adobe's Photoshop site, or a pile of computer parts around the genius bar.

[+] hm2k|14 years ago|reply
TIL Google Chrome doesn't support OpenType.
[+] micheljansen|14 years ago|reply
Does anyone understand why ligatures do not appear to work on Webkit? From what I understand, setting "text-rendering: optimizeLegibility" should enable ligatures on Webkit [1], but I cannot see them on Chrome and Safari where I do see them on Firefox.

[1] https://developer.mozilla.org/en/CSS/text-rendering

[+] bzbarsky|14 years ago|reply
If the text is styled with a font that has common ligatures, then "text-rendering: optimizeLegibility" does enable them for me. Doesn't seem to enable discretionary ligatures, which is what the liga=1 thing does in IE and Firefox (which have common ligatures on by default to start with).
[+] bdunzer|14 years ago|reply
Chrome/Webkit will start to support the OpenType features version 18 from what I have seen - no idea about Safari yet. The current Canary build has support built into it but at this time it is only for Windows and not on the Mac. Not sure about the issues around the Mac and why they might not support it out of the gate but I assume they are working on it.

They will use the -webkit- prefix for the font-feature-settings. So like most new things we will have -webkit -ms and -moz until it settles down.

[+] kibaekr|14 years ago|reply
I feel a little stupid in not really understanding the significance of this blog post. So what are the examples suggesting? I can't seem to notice anything too radical.

One thing that I've noticed/learned of web typography is that fonts with edges (Times New Roman) work well offline on actual paper, but is extremely hard to read on-screen. After realizing this, I started to notice that most fonts meant for on-screen reading were edge-less (sans-serif).

[+] shuzchen|14 years ago|reply
This is pretty cool. My wish-list of typographic features were kerning and alternate glyphs, both of which are on this list. However, I'm still hoping for the day when we get a real baseline grid.
[+] ChuckMcM|14 years ago|reply
Does anyone know the definitive patent status of OpenType?
[+] pash|14 years ago|reply
The only definitive way to find out the status of any patent is through litigation:

"The [US] PTO grants most patent applications, then lets people fight over their validity later on. ... Almost half of patents litigated to judgement are invalidated; of those found valid, half are found not to be infringed." [1]

1. Michael Heller, The Gridlock Economy, p. 53

[+] smackfu|14 years ago|reply
At headline size, some of those ligatures look terrible.
[+] shuzchen|14 years ago|reply
I generally reserve ligatures to body text, in cases where it improves readibility. I don't know if anybody actually uses ligatures for headers.
[+] Samuel_Michon|14 years ago|reply
They use all-caps Verdana in their headlines, how am I supposed to take their views on web typography seriously?
[+] ugh|14 years ago|reply
(Yeah, sarcasm, but) You don’t have to take any of their views seriously. All they are doing is implement OpenType features. They are not in any way pushing for new features. You can already do that stuff pretty much everywhere except on the web. (Can you imagine how happy the long neglected typography on the web nerd inside me is about this? Well, took ’em long enough.)

InDesign could do all that stuff since forever (literally!). I’m not sure, but I think OS X could, too.

The only fear you can have is that they screw it up. That, however, seems pretty unlikely, considering the trampled path – scratch that – superhighway they are driving on.

[+] tle9|14 years ago|reply
This is beautiful. Web 2.0 getting another design remake. This time with the content we use most, text.
[+] pothibo|14 years ago|reply
Very cool stuff.

However, it would have been cool if they included font-stretching so you can manipulate glyphs.

[+] rabidsnail|14 years ago|reply
While we're on the subject of @font-face, _please_ only use it as a replacement for images. I'm tired of waiting 30 seconds for any text to show up on the screen because my computer's busy loading a font file. The web is not a magazine stand. Don't treat it like one.
[+] gkoberger|14 years ago|reply
Why not? I don't get why beauty should be relegated to print.

Additionally, eventually things will get faster -- even now, with proper caching using a good CDN, it should be completely unnoticeable.

[+] tjpick|14 years ago|reply
The web is well overdue for proper typography.
[+] bdunzer|14 years ago|reply
The fact you are waiting 30 seconds is agreeably a poor experience but this should not be the case. Font files on the web range in size from 20kb to 120kb depending on the details in the font - I consider this file size to be nothing more to wait for than say a normal image size. Technically fonts can save on total downloads if you think about the number of images that can be replaced. Fonts from services like WebINK, Typekit, Fontdeck, Fonts.com are all served from global CDN's that have these files located regional servers that should be bring the fonts down to your browser in 500ms to 2 seconds at the most. Of course connection speed matters.
[+] klausa|14 years ago|reply
Which browser does that? My Opera just shows text in 'default' font, and then switches it to @font-face'd when it's finished loading.

It also seems like an easy thing to change.