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.
>

Yes, it could be much 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)
>

So in this case you are suggesting that a font size specification in the
block element would be ignored? That is, the matched fonts may not have
font size scaling applied (e.g., because one is a bitmap font and bitmap
fonts may not be scaled by some platform)?


> or might have font metrics that suggest different normal line
> heights


Does the spec cover this case? I don't see it. For that matter, could you
point out how a font might suggest a different interpretation of 'normal'?
I don't see this in OT, TT, BDF, etc.


> , 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.
>

Yes, it could specify different A/D values that, if a single baseline
registration is assumed, may result in an increase in the used value
assigned to normal. However, even then, the spec text, if read as you
suggest, would still be unclear whether this determination is made once for
the entire block level element or if it is repeated for separate lines. I
would assume the former, since it doesn't really make sense to have a
multi-valued line-height property on the block element.



>
> As Alan points out, the test isn't testing the quoted text.
>

Since you have suggested an entirely different interpretation of the quoted
text, then I will grant it doesn't test your interpretation. However, it
does test my initial interpretation of what is meant by "contains text" in
combination with my reading that the resolution of line-height normal needs
to be performed once for the entire block element and applies to each
determination of the height of a line box (when using line-height as a
minimum enclosing height).

If you are suggesting that the used value of the line-height property on
the block element is re-evaluated for each generated line box, then I would
like to see what spec text you believe produces that reading.