Re: [CSS21] section 10.8.1: when line-height is equal to or less than content area (font-size)

On 23/02/2012 03:44, "Gérard Talbot" wrote:
> {
> Although margins, borders, and padding of non-replaced elements do not
> enter into the line box calculation, they are still rendered around inline
> boxes. This means that if the height specified by 'line-height' is less
> than the content height of contained boxes, backgrounds and colors of
> padding and borders may "bleed" into adjoining line boxes. User agents
> should render the boxes in document order. This will cause the borders on
> subsequent lines to paint over the borders and text of previous lines.
> }
> http://www.w3.org/TR/CSS21/visudet.html#line-height
>
> The above is not thorough and, IMO, is not precise. The "may" of "may
> bleed" seems inappropriate, incorrect, definitely hesitant when it should
> not. I do not understand the recourse of the "may" in the sentence.
>
> I believe it should be saying instead that:
>
> {(...)
> if the height specified by 'line-height' is *equal to* the content height
> of contained boxes, then backgrounds and colors of padding and borders, if
> any, *will* "bleed" into adjoining line boxes.
> If the height specified by 'line-height' is *less than* the content height
> of contained boxes, then background-color of content area *will* "bleed"
> into adjoining line boxes.
> }

> Glyphs in a smaller line box bleed out of their line box

Indeed, and of course bleeding can occur if the height specified by 
'line-height' is *more than* the content height (but less than the 
border area height) as well.

I've raised this in the past,[1] but there was no enthusiasm to make a 
spec change.[2]  No doubt it will be written more precisely in CSS3.

> and they overlap
> *over* the previous line box (they overlap *under* following line box).
> None of this is actually written in the current spec.

This latter part is captured by "User agents should render the boxes in 
document order."  (Aside: I've no idea why there's a "should" there; 
like the "may" that you took issue with, this just seems like a bad 
choice of wording.)


[1] http://lists.w3.org/Archives/Public/www-style/2011Mar/0637.html (#1)
[2] http://lists.w3.org/Archives/Public/www-style/2011Mar/0681.html

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 24 February 2012 07:44:48 UTC