Hacker News new | past | comments | ask | show | jobs | submit login
The New Web Typography (microsoft.com)
327 points by cleverjake on Jan 9, 2012 | hide | past | web | favorite | 132 comments



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;


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;


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.


Sad that all this mystery meat is making a comeback on the web. http://www.webpagesthatsuck.com/mysterymeatnavigation.html


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.


I thought the ligature examples looked pretty bad as well. It may have just been the font they used.


Yeah, the /fl/, /ffl/ ligatures in that font are atrocious.

Hoefler Text has much nicer ones: http://imgur.com/ofE3Z


Odd, no hovering necessary for me. Perhaps it's changed since.


Incidentally, the title they chose is an ambitious non-coincidence:

http://www.ucpress.edu/book.php?isbn=9780520071469


"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.)


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.


We're probably at a point where Microsoft considers Chrome, not Firefox, to be the biggest threat to IE.



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


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.


No, it's not. It works like it's suppossed to do for any (not actual regex) /d+ \/ /d+ . See screenshot here: http://imgur.com/gwlHJ

Fonts supporting the frac feature have a separate set of smaller numbers, and these get dynamically composed into fractions once you type them.


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

Edit: Spelling.


That's actually an issue with that specific font. Try editing the first Verdana Example (3/4 Ale..), that works for me for 1234/5678.


Got me; I tested 3431/4147 and then made an error when posting a comment; this is my original screenshot: http://imgur.com/MajJD


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.


The only way to guarantee it is to have an HTML tag to identify the fraction - <frac>11/63</frac> or similar.


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.


You still use a pen? :)

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.


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.


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).


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


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.


Marker Felt. It's the new Comic Sans.


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.


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.


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.


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.


"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.


... because the Apple "geniuses" would never actually look inside their computers? Sometimes I cry for what geek culture has become.

(edit @awda: That's exactly how I interpreted it too, which is why I'm crying.)


Because part of their company image is that computer internals are an abstract concept, unsuitable for fiddling by mere mortals.


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...


TIL Google Chrome doesn't support OpenType.


I wonder if this explains the ugly non-aliased text I see so often with chrome.


I'm pretty sure that's the renderer and has nothing to do with opentype support.


Do you know if there's a specific reason why the renderer is showing non smooth text?


The render is OS-dependent. On which operating system do you experience this issue?


Can't speak for the OP but I see it on Windows XP with cleartype turned on when viewing webfonts.


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.

I'm a Chrome user btw.


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).


Well, Firefox enables "common" ligatures by default, unlike Chrome. so yes, font rendering does tend to be better in Firefox....


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.

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


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.


Sorry I should have said Chrome 15+ on Windows. I was thinking of another feature in the Canary build.

So today you can use the -webkit-font-settings to get some of the OpenType features into Chrome for Windows today


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.


Does anyone know the definitive patent status of OpenType?


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


FreeType doesn't seem to care: http://www.freetype.org/patents.html


At headline size, some of those ligatures look terrible.


I generally reserve ligatures to body text, in cases where it improves readibility. I don't know if anybody actually uses ligatures for headers.



They use all-caps Verdana in their headlines, how am I supposed to take their views on web typography seriously?


(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.


This is beautiful. Web 2.0 getting another design remake. This time with the content we use most, text.


Very cool stuff.

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


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.


The web is well overdue for proper typography.


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.


I think we hit that point years ago with sFIR and it should have worn off by now.


See also: Widespread use of Comic Sans.


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.


Browsers should [edit: have an option to] download and load fonts after the page.


Then you've got a flash of unstyled content, which just looks plain ugly.


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.


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.


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.


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.


Firefox, Chrome, and Safari


Incorrect. Firefox at least displays the text with the second-in-line font and then switches over to @font-face when the font is downloaded.


Those browsers show default text for me and then switch over to the font-face.


Opening that page in Firefox crashes my Gnome session! Linux Mint.


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.


This isn't different for difference's sake.

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.


Your second point appears to be a weirdly pervasive myth. Excellent article at http://www.microsoft.com/typography/ctfonts/WordRecognition....

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'.


Well, not so much a myth as research and theory that has since been refuted. Good link.


"If anything, all fixed height numerals are the newer invention"

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.


Roman numerals were upper case, but arab numerals were introduced in latin after lower case letters had evoved.


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.


As usual, Wikipedia has a good into article about this, if you know where to look:

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


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.


Those aren’t f’s, they’re long s’s: http://en.wikipedia.org/wiki/Long_s.

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.


Ironically the site features don't work in IE8.


They do inform you that it's only supported in IE10+ and FF8+.


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?


For me it appeared at the top of the linked page.


It doesn't work on Firefox 9.0.1 on Windows XP, either. In fact, it pops up a little message saying that my browser doesn't support OpenType...


Is that a message from the browser, or the site?


It worked for me with that setup.


worked okay here in FF 6.0.2 in Ubuntu


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.


"Ironically the site features don't work in IE8."

How is that ironic? Even Microsoft doesn't like to be reminded of IE8.


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.


Will Microsoft truly favor OpenType over ClearType: http://en.wikipedia.org/wiki/ClearType


ClearType is a technique used to smooth fonts on LCD displays. OpenType is a font format. Perhaps you meant to say TrueType?


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?


It's almost too bad microsoft squandered any credibility they had on web standards years ago.


[deleted]


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.

Also, please use normal English.


[deleted]


They just disagree about the syntax and will have to try and come to some sort of compromise in the future. It happens.

By the way, if they didn’t use pre-fixes we would be truly fucked now because of the differing syntax. Because they don’t it’s not a big deal.


There's no standard on how the values should be set yet, and we all know how well different browser vendors communicate...




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: