The New Web Typography
ie.microsoft.com
ie.microsoft.com
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; 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.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.
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.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.
font-caps: small; /* or none */
font-swash: contextual; /* or none */
This also gives room for future flexibility in values.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.
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.
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.
Hoefler Text has much nicer ones: http://imgur.com/ofE3Z
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.)
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?
Fonts supporting the frac feature have a separate set of smaller numbers, and these get dynamically composed into fractions once you type them.
Edit: Spelling.
I should add that my opinion doesn't stop me from using the correct term in conversation.
I don't start a slash from the top or the bottom - I start it from the left, and go up or down.
The reasoning is simple: Draw a straight line. Lean it. Is it leaning left? It's leaning backward. Leaning right? Leaning forward.
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.
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).Then I saw this was microsoft. My mouth literally[1] fell open.
[1] I know what that word means
They got a long way to go to convince designers to take them seriously.
This may or may not make some designers' lives easier considering some of these additions are not cross-browser compatible.
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.
(edit @awda: That's exactly how I interpreted it too, which is why I'm crying.)
I'm a Chrome user btw.
Its one big issue and one that all of us web font service providers are trying to help solve. If we all had the resources we would be sending down one specific version for each browser / OS and screen setting combination. But that is pretty prohibitive. We are starting to see better renders built into the browsers and some tweaks that the folks at Webkit, Mozilla and IE are making.
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.
So today you can use the -webkit-font-settings to get some of the OpenType features into Chrome for Windows today
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).
"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
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.
However, it would have been cool if they included font-stretching so you can manipulate glyphs.
Of course this only applies to the copy in the body of the page. Using @font-face for logos, buttons, or even headings, isn't going to impose the performance hit (if you only include in the font file the characters that you use) that a whole page's worth of text would.
Additionally, eventually things will get faster -- even now, with proper caching using a good CDN, it should be completely unnoticeable.
It also seems like an easy thing to change.
Text figures flow better in running text. When the numbers are part of a prose sentence and when you aren't comparing them with other numbers or doing math with them, they can be more readable (and less jarring).
Since we don't have old-style numbers in web typography today, it's understandable that they look weird to you, but they aren't a case of different- for- difference- sake.
The option to use Old Style Figures should always be applauded. As is obvious from the case of Georgia, it’s never good when you are stuck with only one or the other.
I think they're fantastic for addresses and phone numbers. Distinctiveness is a win there, since the numbers are abstract and would otherwise just run together.
The '8' in for instance "Suite 1850" is a little bouncy.
As far as it being easier to read in running text, I can't see it, but if the designer of a given work truly feels it provides that benefit, then so be it. I just would prefer for this style to not be used on the web, even though it is becoming available along with other advances in web typography. I just think it looks bad and it's hard to read.
You should read up on typography before decrying things about it. Robert Bringhurst’s The Elements of Typographic Style or Warren Chappell’s A Short History of the Printed Word are two great places to start.
But having said that: the kernel of easy- to- agree- with in your comment is, for a lot of the figures that tend to get typeset on web pages, lining figures are the more appropriate choice.
That said, when set in running text and when describing things that are, effectively, proper nouns (IP addresses, street addresses, phone numbers), old-style figures often read better and are more attractive.
1. These are often termed old-style numerals. Nothing new under the sun here. If anything, all fixed height numerals are the newer invention. (conjecture, feel free to research this and refute, but I'd bet it's the case)
2. Research into how we read whole words indicates that letter height and the profile of entire words is critical to faster reading. SAME HEIGHT WORDS slow us down. The changes in word outline can help us along. 2009 2oo9. A poor example given that I'm simulating old-style numerals, but you get the idea. In blocks of text, not in tabular formatting, the changes in the numeral heights can help carry the eye along.
I doubt it, given that all-uppercase is the older style. http://en.wikipedia.org/wiki/Letter_case#History seems to agree:
"Originally alphabets were written entirely in capital letters, spaced between well-defined upper and lower bounds"
But feel free to research and refute.
Key takeaway (here): Yes, tons of research shows that people read lowercased words faster than they read uppercased words. It also shows that the difference disappears with practice -- turns out lowercase is more common 'in the wild'.
The difference between them is not really simply a stylistic choice: text figures are basically lowercase numbers and titling figures are uppercase ones. Saying you don’t like them is like saying you don’t like lowercase letters, and that you prefer everything in uppercase. Using titling figures in running text is like typing in all caps—it’s screaming at you.
It’s not so much that the text figures are old and were abandoned, but rather that typewriters simply left them off to simplify things. And since computer keyboards were based on typewriters, they never made their way to computers either. And then they started being used exclusively in newspapers and advertising. If you look at books, though, you’ll see that they never really went away. Only now are we finally getting them back—and that’s the entire point of OpenType and it’s a good thing.
Now, the difference between text and titling figures isn’t precisely the same as upper- and lowercase, since titling figures are generally used in titles despite the fact that titles can be mixed case; and they’re also used in tables of numbers. (Although there is another dimension of figure variation—namely, whether they are proportional- or fixed-width—and fixed-width lining figures are typically used in tables so that the places line up.)
How is that ironic? Even Microsoft doesn't like to be reminded of IE8.
And that is Microsoft's way to embrace and extend TrueType fonts in a proprietary way, make them look like shit without the Microsoft proprietary ClearType.
Obviously this can't be true for all fonts, but if enough people, running MS Windows on LCDs experience the difference, then perhaps Microsoft can create the perception that ClearType is essential for any font to look good.
That's what I was trying to get to above, Microsoft has clearly embraced web fonts, will it also try to extend them in a proprietary way?