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:
-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.
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.
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.
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.
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.
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?
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.
Maybe things will change with how the browser implements fractions but 112/3 = 11(2/3) and 3431/5147 = 3431/5147 (there is no 1/5) http://imgur.com/a/4FFNy
Yeah, it can only support those fractions that are included in the specification and the font itself, like 1/2, 3/4, 5/8. It's a typographic special case.
I know -- the problem is the syntax. You can't safely apply this to any document, because it may change the meaning of it. Such things should only exist as unicode characters or character entities.
I'm not sure your argument is valid. How is the decision made to convert x/y to fraction form? Is it white-space/punctuation+whitespace on either side? If that's the case, then: xxx/yyy will never become fraction form; however, x/y and x/y. (as in the end of a sentence) will.
But this does not work this way -- it seems it just blindly consumes char before and after / and converts if this fraction has a glyph in the font. Also, what you suggest is hard to implement since there are numerous localisation-dependent options what a whitespace/punctuation is and where to search it.
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.
When explaining this I usually use add one detail: just as a stick leans from a point on the ground, so does a slash lean from the baseline of the typeset.
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.
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.
Yup; or when they actually created a vector font to reproduce bitmap design: http://www.fonts.com/aboutfonts/verdana.htm Later they were lagging with smoothing techniques because of this pixel-perfection.
Segoe UI is so good that I have Firefox set to use only it (which of course renders this entire page meaningless for me). I can even read light text on a black background in it, which previously has always sent me scurrying for Readability.
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.
When you think that Jobs asked for the interior of the Macintosh case to have the team's signature and that he insisted on even those hidden parts to be clean and beautiful because an engineer has to be proud of the beauty of the hidden parts...
Rendering of web fonts on Windows XP is one big issue that there are solutions for but it really takes a lot of tweaking. First, it starts with a well designed and created font. Second, hinting can be applied that helps shift around the pixels on the screen to better map the outlines to the pixels on the screen, ClearType does help in some instances but mostly with small text, using tricks like sending WOFF/CFF to turn on GDI grayscale anti-aliasing is another that is employed when a font is a certain size - usually larger sizes.
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.
Windows XP's version of ClearType doesn't respect hinting in the Y-direction, which gives you those horrible jaggies on typefaces that aren't designed with this in mind.
Chrome does suck at rendering. Not just the fonts. I recently found a bug where Chrome constantly eats 12% of an 8-core CPU because of an animated GIF, some transparency and shadows. The latest IE and FF have no such problems.
Kind of disappointed, really. I wonder if the font rendering really is better in FF? I hardly open it anymore other than to browse sites that I feel to be shady (as I have FF much more hardened than Chrome).
Similarly, it doesn't seem to work in Safari on my iMac, or in Safari on my iPad 2. (This isn't surprising given the names of the CSS selectors, i.e. -moz-stuff and -ms-stuff but never -webkit-stuff.)
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.
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).
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.
A quick look at their code samples reveals the issue samples - as browsers have not yet standardized the syntax, in order to use this feature you need to use versions of the CSS property names with browser-specific prefixes for example (for Firefox) "-moz-font-feature-settings" instead of just "font-feature settings". For some reason, this demo doesn't include the "-webkit"-prefixed versions - might be they don't exist, might be Microsoft's people just didn't think to.
That was exactly my question: is this one of those rare cases where IE10 is "ahead" of Webkit (and thus Chrome)? The fact that Firefox supports it too rules out the notion that this could just be some crackpot Microsoft-only technology like DX transforms. My question remains: does Webkit not yet support this?
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).
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.
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]
(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.
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.
I suspect the more likely median result will be a decline in typographic standards, like what happened immediately after desktop-publishing software became widespread: huge overuse of newly available features just to use them, gratuitous mixing of five typefaces in a document, etc.
Even if you're in a rare situation where you can't make do with Helvetica or Georgia or one of the other standard fonts, the long load time that your custom font imposes is going to affect my impression of your page much more than any improvement in readability or expression that the font may provide. You only have a few seconds to make a first impression.
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.
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.
It's fairly common for font delivery services like TypeKit to use JavaScript in order to prevent display of text until the webfont has been downloaded.
I really, really dislike that style of numerals. It just looks like they're bouncing all around the baseline. Please don't use that, designers. Different != good.
The comments here are generally calling these “old-style” figures, but—while I’m aware that this is what some people call them—I think the term is a poor one. The old-style figures are better referred to as text figures and the so-called “usual” ones—which @funkah prefers—as lining or titling figures.
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.)
We may be witnessing a kind of aesthetic path dependence. Text figures may be better, but if you have lived your whole life without seeing them then they will look out of place.
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.
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'.
I don't think there is a direct correlation between letter case and old-style vs lining numerals. Most examples of early hand written numerals seem to be variable height, but regardless I'm more concerned with actual type, not hand lettering.
I know that this numeric style is old, I'm used to seeing it in older texts. But it's one of the (many) things that was lost in the web's super-simplified typography, and I personally don't want it back. I just think it looks bad and is hard to read.
I couldn't read them (they don't work in Chrome) but were those text figures (with ascenders and descenders, and the bowls aligned with the bowls of "b" and "p") vs. lining figures?
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.
Georgia (the best serif font everyone has) actually has Old Style Figures. They are really nice (but they certainly don’t work in isolation, like in tables).
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.
How did I not notice that before? Thanks for pointing that out.
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.
Well, its usage is different for different's sake in the context of the web, and that's what I meant. I know this style of numeral is old, but I'm saying that its age does not make it good. We also used to substitute "f" for "s" in some scenarios, but we stopped. Let's stop doing this too.
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're getting downvoted a little unfairly. I disagree with you that old-style figs are like long S's. I strongly disagree that we're better off not having the option. I'm inclined to believe that people with visceral negative reactions to old-style figs are really just reacting to being conditioned to lining figures.
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.
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.
I went back to the link and couldn't find that disclaimer. Can you tell me where it is? Edit: never mind, it's not on the linked page, it's on the parent page. And how was I supposed to know that?
Did you check that it actually looked as it's supposed to? I almost thought it was correct until I realized that NoScript was blocking the fonts for me. Looked even better when I changed that.
Thanks, I've never even seen that "Blocked Objects" menu item before. Curious, though, that there's no option to permanently allow blocked objects like there is to allow blocked sites.
I opened my Firefox after a few months and upgraded it to 9.x just to see what Microsoft have achieved. Great work indeed but I'm not sure it is worth changing and messing the CSS standards. Some of them were already achieveble by doing a few tricks like using different fonts IMO.
I am not certain about this, but I think true TrueType fonts are only slightly improved by font smoothing technologies like ClearType and Quartz. Where as fonts made specifically to be used with ClearType look like utter crap on LCDs without it.
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?
They use prefixes for experimental features. It's not part of an official spec yet, so each browser is implementing different features with different syntax. Eventually, when they agree on a feature set and syntax, they will move it into the common namespace by dropping the prefixes.
But this syntax they’ve come up with is an absolute horrifying mess. Ugh. Please say it ain’t so!
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?