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

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

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 18 Oct 2013 18:36:51 -0600
Message-ID: <CACQ=j+dKhrZBcE9hf9qbUeKxc7bVHXTimXd115t71hWaNEObew@mail.gmail.com>
To: Gérard Talbot <www-style@gtalbot.org>
Cc: John Hudson <tiro@tiro.com>, Alan Gresley <alan@css-class.com>, W3C Style <www-style@w3.org>
On Fri, Oct 18, 2013 at 5:31 PM, Gérard Talbot <www-style@gtalbot.org>wrote:

> Le 2013-10-18 13:28, Glenn Adams a écrit :
>
>  On Fri, Oct 18, 2013 at 9:58 AM, John Hudson <tiro@tiro.com> wrote:
>>
>>  On 17/10/13 10:34 PM, Glenn Adams wrote:
>>>
>>>
> [snipped]
>
>  My interpretation of "largest font size" is one of:
>>
>> #1 max(computedFontSize(B), computedFontSize(I1), ...,
>> computedFontSize(I*n*
>> ))
>>
>> or
>>
>> #2 max(computedFontSize(I1), ..., computedFontSize(I*n*))
>>
>> where B is the block element and I1...I*n* are its inline children
>> elements.
>>
>
> When line-height is set onto a block element, it sets the minimum height
> of each of its line boxes. When line-height is set onto an inline element,
> it sets the height of the inline box:
>
> "
> On a block container element whose content is composed of inline-level
> elements, 'line-height' specifies the *minimal* height of line boxes within
> the element.
> "
> http://www.w3.org/TR/CSS21/**visudet.html#propdef-line-**height<http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height>
>
> "
> The height of the inline box encloses all glyphs and their half-leading on
> each side and is thus exactly 'line-height'.
> "
> http://www.w3.org/TR/CSS21/**visudet.html#inline-box-height<http://www.w3.org/TR/CSS21/visudet.html#inline-box-height>
>
>
> We have tests (and I could create tests) to "exemplify" both sentences
> which would highlight the differences of those 2 sentences.
>
> In your test
>
> http://www.gtalbot.org/**BrowserBugsSection/**
> CSS3LineBox/multiple-line-box-**various-font-sizes.html<http://www.gtalbot.org/BrowserBugsSection/CSS3LineBox/multiple-line-box-various-font-sizes.html>
>
> http://www.gtalbot.org/**BrowserBugsSection/**
> CSS3LineBox/multiple-line-box-**various-font-sizes-AG.html<http://www.gtalbot.org/BrowserBugsSection/CSS3LineBox/multiple-line-box-various-font-sizes-AG.html>(line box are painted with lime color)
>
> each line boxes (containing respectively the X1 inline box, X2 inline box,
> X3 inline box) should be using its distinct height (caused, determined,
> conditioned by each Xn inline box's height).
>
> The line box with X1 should be approx. (16px + 2 * 1.6px) 19.2px tall, the
> line box with X2 should be approx. (48px + 2 * 4.8px) 57.6px tall and the
> line box with X3 should be approx. (24px + 2 * 2.4px) 28.8px tall...
> assuming that 'normal' computes to 1.2.
>
>
>
>
>  And where computedFontSize(E) is the result of the normal CSS cascading
>> and
>> computed style resolution process.
>>
>> What I am observing, however, is that font size appears to be interpreted
>> on a per-line basis in order to create a per-line value for line height.
>>
>
> Yes. That's how it should be too. In a multi-line block element, each line
> box can have its own distinct height.


Unfortunately you are using "line height" in two ways. I am referring to *the
property whose name is 'line-height'*. You are referring to the *height of
a line box*. I am talking about only the former, and not about the latter.

I am trying to resolve what it means to *determine a used value for the
property named 'line-height'* when its computed value is 'normal'. The
result of this process serves as an input parameter for the subsequent
process of *determining the height of a line box*.

These are two separate processes, where the former precedes the latter (and
there is no feedback loop).

I am not disputing the language that 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."

What I am asking is how line-height normal is resolved to a used value that
serves to specify this minimal height. In my example, if line-height normal
is resolved to a used value that is the maximum computed value of inline
element children, then this used value would be 36pt * some percentage, say
120%, and thus 43.2pt, which means that every one of the three line boxes
must be at least 43.2pts in height.

This would be the natural reading of "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>
value
according to the largest font size.". The reason this is the natural
reading is because this language includes all contained text rendered in
more than one font [size], it doesn't say determine the normal line-height
value according to the largest font size on a line by line basis.

Is this more clear?


> In a multi-line block element, each line box can have its own distinct
> height based, determined by, conditioned by factors like vertical-align,
> font-size, line-height applied onto its replaced and non-replaced inline
> elements.
>

Of course, but that is not what I am discussing.


>
>  This appears to be counter to the language in [1] that says:
>>
>> "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."
>>
>
> That's for non-replaced inline box.
>
> Sections 10.6.1, 9.4.2 and 10.8.1 are intricated and are difficult to
> understand.
>
> I hope I am not wrong with what I wrote you. In any case, I'd love to
> read/see where I may have been wrong.
>
> Gérard
>
Received on Saturday, 19 October 2013 00:37:41 UTC

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