View Single Post
Old 07-18-2013, 04:26 PM   #16
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by tshering View Post
There is supposed to be a difference (cf. for instance here). In the case of { line-height: 1.3em; } child elements inherit the computed value, whereas in case of { line-height: 1.3; } they inherit the ratio that is used for the calculation. I took this for true without testing and thought it may explain what GeoffR reported.
According to that page, the difference is that length-unit line-heights are inherited poorly. That makes some degree of sense, but it's bad inheritance; the page is murky on whether the fault is in how CSS is implemented or in how the specification is supposed to work (engine vs. spec).

The takeaway here, regardless, is:

1. If you're an ebook author, don't put units on your line-height!

2. If you handle ebook code, see #1.

3. If you maintain software that generates ebook code, see #1.

4. If the device-specified line-height is getting translated into a value with units - whatever those units are - instead of a unitless value, that is bad behavior and should be regarded as a bug that needs fixed ASAP.
Rev. Bob is offline   Reply With Quote