Before the word: initially I had in mind only Windows, but after some time testing on Mac Air realized that it was even worse there. Although in real code this is not such a problem, although there are some contradictions.
here is the test http://jsbin.com/ehegaj/6/edit
In short, what is happening. I have headers where I applied the line-height , it is always one line of headers, so I fixed the height to be suitable for fonts. In different browsers (and OS), you can see text bookmarks in different ways. Any ideas how to solve this?
UPD: here http://jsbin.com/uzucuf/1/edit is a very close example of the real work I'm doing, again, this is not as bad as the test example above, but still there are moving pixels.
UPD2:
I conducted more tests focused mainly on Windows 7, and there was an image with test screenshots in different browsers with different line heights. you could see visually the mismatch between them.
It's about 1px, so in practice I could fix this by using a 29px line height and serving IE with 30px different line height. Although I would just leave it with a line height of 30px and ignore the safari, so at that moment I'm fine.
So just curious why this happened? Forcing this impatient person to spend a couple of hours viewing various resources:
This guy seemed to have the same problem, but he just got rid of the question of why.
Another person suggested using only even values for line-height , which is a bit strange from my point of view :) Please correct me if I am wrong here.
Another , but slightly unrelated topic was simply interesting to read.
And finally, it seems like I will find out the answer, it is a bit blurry, but it actually makes some sense.
1. Three sets of line spacing
For unknown reasons, rooted in the history of TrueType and OpenType font formats, each web font contains three sets of line spacing values.
The “old Mac” set introduced in System 7. On the old Mac OS, if the glyph reached above or below the lines between the lines of the “old Mac”, that glyph would be squeezed vertically to fit.
The set of "old windows" introduced in Windows 3.1, in which any part of the outline located above or below the lines of the "old and old" Windows, will not be displayed on the screen (therefore glyphs will be cropped). A "typographic" set, supposedly free from 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 the re-filling of documents created in older applications. Mac OS X does not compress, but most applications still use the "old Mac" value.
This baggage has been ported to browsers. Chrome on Mac OS X uses a different set of values than Chrome on Windows; Firefox in Windows 7 uses a different set of values than Firefox in Windows XP, and Firefox in Windows 7 uses a different set of values than Chrome in Windows 7. In versions of the same browser for Mac and Windows, different sets of values will be used, while while different browsers in the same OS can also use different values! In an ideal world for font makers, a simple solution would be to make sure that all three sets of values produce the same result. But many of the existing fonts were created before web fonts were conceived, and font creation tools prevent font developers from easily making these values "correct."
In short: there are many fonts in which line spacing results in inconsistencies between operating systems and browsers.
But still I'm not 100% sure that it is. Maybe someone better guesses and gives a clearer answer, as an explanation for the child :)?