Re: line-height: normal and multiple descendant font sizes

On Thu, Oct 17, 2013 at 12:27 PM, Gérard Talbot <www-style@gtalbot.org>wrote:

> Le 2013-10-17 12:52, Glenn Adams a écrit :
>
>> In CSS2.1, we have the following in Section 10.8.1:
>>
>> "When an element contains text that is rendered in more than one font,
>> user
>> agents may determine the 'normal'
>> 'line-height'<http://www.w3.**org/TR/CSS2/visudet.html#**
>> propdef-line-height<http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height>
>> >
>>
>> value
>> according to the largest font size."
>>
>
> Glenn,
>
> The "may" word in the sentence makes this optional and not required.


Understood. However, if no UA actually does this, then it would be better
to change the spec to require the behavior implemented by UAs (if they
indeed all implement the same behavior). That would improve consistency
between the spec and implementations and make it less ambiguous, i.e., to
require consistent behavior instead of suggesting a different
implementation choice.


>
>
>> I'm curious if any UA actually implements this. I have tested Chrome,
>> Opera, and Safari UAs, and none of these UAs seems to use the largest font
>> size (of descendant fonts).
>>
>
> It seems (I am quite busy right now; did not check thoroughly) we only
> have 1 test on this:
>
> http://test.csswg.org/suites/**css2.1/nightly-unstable/html4/**
> line-height-largest-001.htm<http://test.csswg.org/suites/css2.1/nightly-unstable/html4/line-height-largest-001.htm>
>
> but this interactive test is good IMO for testing that sentence:
>
> http://test.csswg.org/suites/**css2.1/nightly-unstable/html4/**
> inline-formatting-context-**010b.htm<http://test.csswg.org/suites/css2.1/nightly-unstable/html4/inline-formatting-context-010b.htm>
>
>
>
>
>> My test consisted of the following fragment:
>>
>> <p style="line-height: normal">
>> <span style="font-size: 12pt; border: 1px solid #C0C0C0">X</span></br>
>> <span style="font-size: 36pt; border: 1px solid #C0C0C0">X</span></br>
>> <span style="font-size: 18pt; border: 1px solid #C0C0C0">X</span></br>
>> </p>
>>
>
> I'll create that test and upload it later... very busy right now..
>
> The borders are not necessarly a good, reliable indicator of where the
> line box starts (at the top) and ends (at the bottom) since borders are not
> part of line boxes. Background color is a more reliable way to display line
> 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.
> "
>
> Eg:
>
> http://test.csswg.org/suites/**css2.1/nightly-unstable/html4/**
> border-padding-bleed-003.htm<http://test.csswg.org/suites/css2.1/nightly-unstable/html4/border-padding-bleed-003.htm>
>
>
>> If a UA implements the above language, then I would expect that each of
>> the
>> three lines be assigned a single line height (of 36pt), where the leading
>> on each line is computed according to the following language:
>>
>> "Still for each glyph, determine the leading L to add, where L =
>> 'line-height' <http://www.w3.org/TR/CSS2/**visudet.html#propdef-line-**
>> height <http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height>>
>>
>>  - AD. Half the leading is added above A and the other half below D,
>> giving
>> the glyph and its leading a total height above the baseline of A' = A +
>> L/2
>> and a total depth of D' = D + L/2."
>>
>> Also, I should note that "the largest font size" is ambiguous in the above
>> language, since it might mean:
>>
>>    1. largest font size of descendant non-replaced elements, i.e.,
>>    descendants only;
>>    2. largest font size of descendant non-replaced elements and element
>> (on
>>
>>    which line-height of 'normal' is specified), i.e., descendants and
>> self.
>>
>> G.
>>
>
> Gérard
>
>