W3C home > Mailing lists > Public > www-style@w3.org > October 2013

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

From: Alan Gresley <alan@css-class.com>
Date: Sat, 19 Oct 2013 16:33:49 +1100
Message-ID: <526219BD.2070508@css-class.com>
To: Glenn Adams <glenn@skynav.com>
CC: W3C Style <www-style@w3.org>, Gérard Talbot <www-style@gtalbot.org>
CC Gérard

On 19/10/2013 2:31 AM, Glenn Adams wrote:
> On Fri, Oct 18, 2013 at 4:52 AM, Alan Gresley <alan@css-class.com> wrote:
>> On 18/10/2013 4:34 PM, Glenn Adams wrote:
>>> On Thu, Oct 17, 2013 at 7:49 PM, Alan Gresley <alan@css-class.com> wrote:
>>>   On 18/10/2013 3:52 AM, Glenn Adams wrote:


>>    | When an element contains text that is rendered in
>>    | more than one font, user agents may determine the
>>    | 'normal' 'line-height' value according to the
>>    | largest font size.
>> A few paragraph up appears this.
>>    | The height and depth of the font above and below
>>    | the baseline are assumed to be metrics that are
>>    | contained in the font.
>> Each font has it own unique font metrics.
> Not relevant. A+D will be the same (= font size) regardless of font family.
> A and D only affects baseline placement in this context.

This is not true. A+D can be different when you use different fonts on 
one single line. Baseline placement is done by some other means (it does 
involve x-height) and since I am not an implementer, I can not tell you 
how this is done.

The following test case shows that A+D are different when you use 
different fonts on one single line. The line-height is still normal 
until you choose a different line-height.


Please note the following:

1. The baseline will remain consistent between different fonts.
2. The x-height will be change between different fonts.
3. The span will shift vertically within the line box if
    the line-height is normal causing the vertical height
    of the line box to be different.
4. If you change the line-height, you will notice bleeding.
    This will be more pronounced if the font has a larger
    line-height (e.g. due to font metrics).

>>> The other spec problem is that it isn't clear about what is meant by "font
>>> size". Does it mean the computed font size of all descendant elements or
>>> the computed font size of all descendent elements and itself.
>> It means the size of the typeface (or font) for the part that say "largest
>> font size."
> Read what I said. Font size here refers to computed font size of some
> elements. Which elements?

Can you tell me precisely the CSS values of each element. Then I can 
attempt to answer your question.

>>> The third problem is that the spec allows for implementation dependent
>>> behavior, which makes the results ambiguous. It does this by suggesting
>>> more than one interpretation.
>> Where?
> Where it says "*may* determine ... normal ... according to the largest font
> size".

If you view the above test case (linebox-line-height-fonts-003.htm) in 
both Firefox and the Chrome, you will note that each browser does 
something different for various fonts. I think the spec reflects the old 
behavior of old UA (IE vs Mozilla).

You are correct that *may* does allow implementation dependent behavior 
but to arrive at a meaning of normal that reflect implementation 
behavior and interoperability involves the creation of mega test suites 
for fonts.


>> Could you please run the test and note the line-height. It ranges from 1
>> up to 1.767 for Segoe Print.
> Thanks. But you aren't seeing the problem I am trying to discuss: whether
> the same line height is applied to the case of multiple lines, each of
> which have different font sizes, or whether each line is considered
> separately for determining line height.
> Your example shows only one line.
> The spec says "On a block container
> element<http://www.w3.org/TR/CSS2/visuren.html#block-boxes> whose
> content is composed of
> inline-level<http://www.w3.org/TR/CSS2/visuren.html#inline-level>
> elements,
> 'line-height' specifies the *minimal* height of line boxes within the
> element."
> Note the phrase "within the *element*". It doesn't say "within each
> *line* produced
> by the element".

Correct but please bare in mind that the spec is not worded to cover all 
instances of how a text within a element is laid out. It's worded to 
cover an element with one line and it's worded to cover an element with 
two lines or more.

> What you have demonstrated is that UAs appear to treat each line separately
> for interpreting line height.

Correct (see above for the reason).


>>> Since the initial value of line-height is 'normal', then setting it to
>>> normal is a NO-OP. The point of my test was to demonstrate that UAs do
>>> *not* implement
>>> the "use largest font size" interpretation.
>> Of course it will be a NO-OP. The reason is that what you think is font
>> size is just font or fonts if used in a plural sense.
> The fact that you and I have different readings of the spec should be
> sufficient to show that the spec is ambiguous, yes?

No. Where the spec just mentions font, it's referring to typeface.


Alan Gresley
Received on Saturday, 19 October 2013 05:34:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC