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

On Sat, Oct 19, 2013 at 2:18 AM, L. David Baron <dbaron@dbaron.org> wrote:

> On Thursday 2013-10-17 10:52 -0600, Glenn Adams wrote:
> > 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
> >
> > value
> > according to the largest font size."
> >
> > 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).
> >
> > 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>
> >
> > 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>
> >  - 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.
>
> This sentence is not intended to refer to text inside descendant
> elements, only text in the element itself.  That could certainly be
> clearer.
>
> What it's referring to is that the font matching algorithm is
> per-character, so different fonts might be used for different
> characters within the element.  These fonts might have different
> sizes (due to unavailability of some font sizes with bitmap fonts)
> or might have font metrics that suggest different normal line
> heights, or (a case the spec doesn't cover) might have font metrics
> that suggest that normal line height has different positions
> relative to the baseline.
>

I've did some research on Blink/Webkit, and both resolve line-height
'normal' on a block element to a single value that is used by the
subsequent process of computing each line box's height:

resolvedLineHeight = *ascent* + *descent* + *leading*

where the dependent variables are based only on metrics obtained from the
font associated with the single computedFontFamily associated with the
block.

The value of *leading* here is based on a per-platform-font metric, e.g.,
on Windows the TEXTMETRICS.tmExternalLeading field, on Mac,
CTGetFontLeading(), etc.

Does FF use this same strategy? If all UAs use the same strategy, I wonder
(again) if we should remove the language about "may [use] largest font
size"?



>
> As Alan points out, the test isn't testing the quoted text.
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>              Before I built a wall I'd ask to know
>              What I was walling in or walling out,
>              And to whom I was like to give offense.
>                - Robert Frost, Mending Wall (1914)
>