Re: Line layout in browsers

Investigating this further, even if I change/remove the WebKit hack,  
it looks like a lot of fonts just encode line spacing into their  
ascent values.  Therefore overlap really is going to be expected.  I'm  
not sure I'd call this a bug after all.

When you ask a browser to use a line-height of normal, it does line  
gap + ascent + descent, and so the spacing works out as expected.  But  
when you ask a browser to use a line-height of 100%, it will use the  
font-size, which could be much smaller than the font's ascent +  
descent if the ascent has spacing encoded into it.  The height of a  
span box is going to be ascent + descent (+ borders and padding), and  
so you'll end up with overlap if the line spacing was encoded into the  
font's ascent (as seems to be the case with lots of the fonts I tried).

However this is actually ok if you think about it for a second.  In  
the absence of borders/padding/backgrounds on the spans themselves  
(which would overlap and look odd I admit), the spacing really is what  
you expect.  In effect the "hacked ascent" portion of the next line  
overlaps the descent portion of the previous line.  However no glyphs  
will typically draw into that hacked ascent area, and so really the  
spacing works out correctly.  It's just the span box dimensions that  
reveal the oddity of the overlap because they include the "hacked  
ascent" portion in their dimensions.

dave
(hyatt@apple.com)

On Jan 21, 2008, at 4:16 PM, David Hyatt wrote:

>
> Ok, you've found a bug in WebKit.
>
> The overlap is because of the ascent hack I described earlier that  
> exists in WebKit (the one where the ascent of Helvetica is  
> artificially boosted).  Because it's the ascent that is boosted, the  
> overall height of the font effectively becomes about 115px instead  
> of 100px.  If I remove the WebKit hack, then the lines touch as  
> expected.  The hack was poorly implemented in that it should have  
> boosted the default line spacing only when 'normal' was specified.   
> By boosting the ascent always, when a line-height other than normal  
> gets specified, WebKit does the wrong thing for explicit line heights.
>
> This hack has been removed on Safari for Windows, so that platform  
> should (in theory) behave as expected.
>
> You may ask why this hack was implemented this way.  Well it turns  
> out that AppKit (a framework underneath WebKit that is also handing  
> back font metrics to us) also has ascent hacks for various fonts.   
> For example if you change the font to Monaco you'll still see an  
> overlap.  That's because the ascent we get back from AppKit is also  
> hacked.  Because we don't use AppKit on Windows, Safari on Windows  
> should also work with those fonts.
>
> I suspect that HFONTs on Windows also do ascent boosting and that  
> may be why IE has overlap as well.
>
> So what you're experiencing is essentially a Mac-only bug in  
> WebKit.  I will file it so that we can investigate how to fix it.
>
> Thanks for pushing on this!
> dave
> (hyatt@apple.com)
>
> On Jan 21, 2008, at 3:24 PM, Eric A. Meyer wrote:
>
>>
>> At 2:38 PM -0600 1/21/08, David Hyatt wrote:
>>
>>> Borders increase the span height (as does padding).  If you put  
>>> 1px top and bottom borders on a span in an attempt to "see where  
>>> it is", then you just made a span box that is 2px taller.   
>>> Therefore at a line-height of 1 (100px), there will be a slight  
>>> overlap since the span boxes are a bit taller than the height of  
>>> the line (102px).
>>
>>  Agreed.  In the case we were discussing, though-- the first test  
>> on <http://meyerweb.com/eric/css/tests/line-height/bigtext- 
>> spans.html>-- there is no padding on the spans, and at 'line- 
>> height: 1' there's a more than a few pixels of overlap in Safari  
>> and IE.
>>
>> -- 
>> Eric A. Meyer (eric@meyerweb.com)     http://meyerweb.com/
>>
>
>

Received on Monday, 21 January 2008 23:35:31 UTC