Re: Issue 118 (Was: [CSS21] Issues with inline formatting model (particularly 10.8))

On 19/08/2010 22:48, Bert Bos wrote:
> On Monday 26 July 2010 23:53:13 Anton Prowse wrote:
>> Bert Bos wrote:
>>> I have an action item to write text for issue 118[1].

> Here is a new proposed text (which uses mathematics and so should be a 
> lot more precise. :-) ).
> 
> Replace the first three paragraphs in section 10.8.1[3]:
> 
>     # Since the value of 'line-height' for an inline box may be
>     # different from the height of its content area there may be
>     # space above and below rendered glyphs. The difference between
>     # the content height and the used value of 'line-height' is
>     # called the leading. Half the leading is called the
>     # half-leading. 
>  
>     # User agents center glyphs vertically in an inline box, adding
>     # half-leading on the top and bottom. For example, if a piece
>     # of text is '12px' high and the 'line-height' value is '14px',
>     # 2pxs of extra space should be added: 1px above and 1px below
>     # the letters.
> 
>     # When the 'line-height' value is less than the content height,
>     # the final inline box height will be less than the font size
>     # and the rendered glyphs will "bleed" outside the box. If such
>     # a box touches the edge of a line box, the rendered glyphs
>     # will also "bleed" into the adjoining line box. 
> 
> with:
> 
>     | CSS assumes that every font has font metrics that specify a
>     | characteristic height above the baseline and a depth below it. In
>     | this section we use A to mean that height (for a given font at a
>     | given size) and D the depth. We also define AD = A + D, the
>     | distance from the top to the bottom. (See the note below for how
>     | to find A and D for TrueType and OpenType fonts.) Note that these
>     | are metrics of the font as a whole and need not correspond to the
>     | ascender and descender of any individual glyph.
> 
>     | User agent must align the glyphs in a non-replaced inline box
>     | to each other by their relevant baselines, and to nested inline
>     | boxes according to 'vertical-align'. Then, for each glyph,
>     | determine the A and D. Note that glyphs in a single element may
>     | come from different fonts and thus need not all have the same A
>     | and D. If the inline box contains no glyphs at all, it is
>     | considered to contain a strut[ref] (an invisible glyph of zero
>     | width) with the A and D of the element's first available font.
> 
>     | Still for each glyph, determine the leading L to add, where
>     | L = 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.
> 
>     | The height of the inline box is then the smallest such that it
>     | encloses all glyphs and their leading, as well as all nested
>     | inline boxes.
> 
> The next paragraph is kept unchanged:
> 
>     # Although margins, borders, and padding of non-replaced
>     # elements do not enter into the line box calculation, they are
>     # still rendered around inline 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.
> 
> Then add this note:
> 
>     | Note that CSS 2.1 does not define what the content area of an
>     | inline box is (see 10.6.1) and thus different UAs may draw the
>     | backgrounds and borders in different places.
> 
> And finally add this implementation note about TrueType and OpenType:
> 
>     | Note. It is recommended that implementations that use OpenType or
>     | TrueType fonts use the metrics "sTypoAscender"
>     | and "sTypoDescender" from the font's OS/2 table for A and D (after
>     | scaling to the current element's font size). In the absence of
>     | these  metrics, the "Ascent" and "Descent" metrics from the HHEA
>     | table should be used.

Looks great (concerns about inline box height being unrelated to the box
model[1] notwithstanding – although to be fair, the situation under the
proposed text is better since it's now very clear how the inline box is
sized).

Is there much value in defining AD = A + D?  You only use it once (and
the notation can be confused with product notation, although this might
be because I'm not seeing the motivation for it).

[1] http://lists.w3.org/Archives/Public/www-style/2010Jul/0535.html

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 20 August 2010 20:01:05 UTC