7

Pre word: initially I kept in mind only Windows, but after a while testing on Mac Air, realized it is even worse there. Though in real code it is not such a hassle, although there is some inconsistency.

here is the test http://jsbin.com/ehegaj/6/edit

In short, what's going on. I have headers where I applied line-height property, this is always one line headers so I locked up the height just to be right fit for fonts. In different browsers (and OSs) you could see text lays differently. Is any ideas how to work it out?

UPD: here http://jsbin.com/uzucuf/1/edit is very close example of the real work I do, again it is not such a bad as sample test above, but still there is moving pixels.

UPD2:

Did more tests focusing mostly on Windows 7, and there is included image with the test screenshots into the different browsers with different line heights. you could see visually inconsistency between them.

It is about 1px, so practically I could fix it by using line heeight 29px and serving different line height 30px to the IE. Although I just would leave it with 30px line height and ignoring safari, So at this point I am good.

So just curious why that happened? Forcing by this eager was spend couple hours browsing different resources:

This guy, looks got the same issue, but was just get rid of finding question why.

Other person suggested use only even values for line-height which is little bit odd at my point of view:) Please correct me if I do wrong here.

Some other but bit unrelated topic was just quite interested to read on.

And finaly, looks I find out the answer, it is bit blurry but in fact makes some sense.

1. Three sets of linespacing values
For obscure reasons rooted in the history of the TrueType and OpenType font formats, every webfont carries three sets of linespacing values.

The “old Mac” set, introduced in System 7. In the old Mac OS, if a glyph reached above or below the “old Mac” linespacing lines, the glyph would be squeezed vertically to fit in.

The “old Windows” set, introduced in Windows 3.1, wherein any part of the outline that went above or below the “old Windows” ascender and descender lines would not appear on screen (so the glyphs would be cropped). A “typographic” set, supposedly free of the limitations of the other two sets.

The problem, however, is that many Windows applications still use the “old Windows” values. Often this is done intentionally to prevent reflow from documents created with older applications. On Mac OS X, the squeezing does not happen but most applications still use the “old Mac” values.

This baggage has been brought over into browsers. Chrome on Mac OS X uses a different set of values than Chrome on Windows; Firefox on Windows 7 uses a different set of values than Firefox on Windows XP, and Firefox on Windows 7 uses a different set of values than Chrome on Windows 7. Mac and Windows versions of the same browser will use different sets of values, while different browsers on the same OS may use different values as well! In an ideal world, the simple solution would be for font foundries to make sure all three sets of values lead to the same result. But many of the existing fonts were created before webfonts were conceived, and font creation tools don’t make it easy for type designers to make these values “right”.

In short: there are many fonts out there in which the linespacing values lead to inconsistencies across operating systems and across browsers.

But still I am not 100% sure that's the case. May be someone make better guess and give more clear answer, just like explanation for child:)?

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
dmi3y
  • 3,482
  • 2
  • 21
  • 32
  • Strange, but I too am noticing this. Perhaps what you're trying to do is too exact for cross browser compatibility? Could you tell us what you're trying to do so that we can maybe help come up with an alternative solution for you? – zeMinimalist Nov 30 '12 at 23:34
  • Thank you Simon, I am trying to make kind of global headers, the testing code is not so far form the real, I just adding float left more height and line height for what I am needed. And again than it not looks such badly especially in Mac. I'll prepare more close sample later on – dmi3y Nov 30 '12 at 23:38
  • I think `height` on your `h1` is what's breaking everything for you. Again, your question is not clear, but look what happens here: http://jsbin.com/ehegaj/12/edit – Sparky Nov 30 '12 at 23:44
  • I need height here, will update question with details soon – dmi3y Nov 30 '12 at 23:50
  • Out of curiosity, have you applied all the global resets to your stylesheet? – Michelle Dec 01 '12 at 01:42
  • Yep, but not on examples – dmi3y Dec 01 '12 at 06:12
  • @Sparky672, not sure I got why height breaking factor here? – dmi3y Dec 03 '12 at 23:27
  • See the [jsBin](http://jsbin.com/ehegaj/12/edit) I posted. Without `height` on the first one, the others are now different sizes, where before they were all the same. Otherwise, now I have no idea what this question is really about... your new image seems to show everything the same. – Sparky Dec 03 '12 at 23:46

2 Answers2

2

It seems the reason you're experiencing different results using the same font, is because you're not actually using the same font. sans-serif is a variable really, and different browsers use a different font for sans-serif. If you change it to Arial, it should all be the same across all browsers.

See this post: CSS: Is Helvetica the default 'sans-serif' font on Mac and Arial the default sans-serif font on Windows?

Community
  • 1
  • 1
zeMinimalist
  • 453
  • 1
  • 3
  • 10
  • Thank you for responce, do not think it is because of family, in the project I use the totally different fonts with the same result, here is arial test, at least for windows it is same acting up – dmi3y Nov 30 '12 at 23:49
  • Remember that not all fonts are shared between different systems. Helvetica for example is not available on windows. My example worked when comparing Chrome Windows and Safari on Mac. I then noticed IE is still not the same with Arial. – zeMinimalist Nov 30 '12 at 23:55
  • font which is in real project loaded from the Typekit – dmi3y Dec 01 '12 at 00:06
2

In short: there are many fonts out there in which the linespacing values lead to inconsistencies across operating systems and across browsers.

This is true. Many fonts have issues with their vertical metrics. Such font will never align right across browsers. The only way to get the font rendered consistently across browsers is to fix its vertical metrics.

Most font providers allow you to update and fix vertical metrics of a font before downloading it. They may call that option differently though. E.g.: Fontsquirrel calls it Auto-Adjust Vertical Metrics, myFonts.com calls it Line Height Adjustments.

More on that: Font: poor vertical metrics cause inconsistent line-height rendering across browsers. Solution?

Community
  • 1
  • 1
Rotareti
  • 49,483
  • 23
  • 112
  • 108