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

Giovanni Campagna wrote:
> 2009/9/1 Anton Prowse <prowse@moonhenge.net>:
>> 10.8.1, 'vertical-align' property :
>>
>>  # The following values only have meaning with respect to a parent
>>  # inline-level element, or to the strut of a parent block-level,
>>  # table-cell, table-caption or inline-block element.
>>
>>
>> Issue 10c:  The wording suggests that a strut is a property of a several
>> different types of element.  This is incorrect; a strut is a property of
>> a line box.  This is essentially the same issue as Issue 8 as discussed
>> in [1].
> 
> Not really... the strut is the result of having font / line-height
> properties on block level elements, and thus is a peculiarity of only
> those elements, although it is "rendered" on every line box.
> Anyway, I'm not sure it makes any difference.

I don't think it makes any difference either.  Still, the spec as it
stands defines strut (or its CSS equivalent) only on line boxes.[1]


> 
>>  # baseline
>>  #     Align the baseline of the box with the baseline of the parent
>>  #     box. If the box doesn't have a baseline, align the bottom margin
>>  #     edge with the parent's baseline.
>>  # middle
>>  #     Align the vertical midpoint of the box with the baseline of the
>>  #     parent box plus half the x-height of the parent.
>>
>> Then,
>>
>> s/parent box/parent box or strut/
>> s/parent's/parent's or strut's/
>>
>> since redefining "parent (box)" to possibly mean "strut" is pretty ugly.
>>
> 
> It says:
>> The following values only have meaning with respect to a parent inline-level
>> element, or to the strut of a parent block-level, table-cell, table-caption or
>> inline-block element.
> To me, this is enough.

To me, it's taking conciseness a step too far, although I agree that
this is purely a matter of taste.  (I note, however, that I don't think
the spec takes such a device to quite this extreme anywhere else.)


> 
>> Issue 10d:  What is the baseline of an empty inline box?  Section 9.4.2
>> (Inline formatting context) states that text inside inline boxes has a
>> baseline, which is presumed to determine the baseline of the inline box
>> itself (see David Baron's and my discussion of Issue 10b in [2]).  If
>> such an inline box is empty, a strut is presumed to be used, although
>> the spec only discusses struts in relation to line boxes
>> (notwithstanding Issue 10c).
> 
> Why a strut? 10.8 says:
>> Empty inline elements generate empty inline boxes, but these boxes still
>> have margins, padding, borders and a line height, and thus influence these
>> calculations just like elements with content.
> So I expect that the baseline is the same as for an inline-level
> element with content, just not used for content inside but only for
> rendering the box and aligning surrounding text. Such boxes are not
> necessarily struts, ie they're not zero-width, because they have
> margins, paddings and borders.

Sure, the boxes are not themselves struts; I was claiming that one way
to understand the baseline of an empty inline box is to presume that it
/contains/ a strut.  In fact I prefer (and have always relied upon) your
interpretation, which is that the baseline is defined by virtue of the
inline-level element possessing the properties of line-height and
font-*.  My point is, this is not defined in the spec (either way).  The
only mentions of baseline with respect to inline boxes (outside of the
description of the 'vertical-align' property) are the following:

9.4.2 Inline formatting context:
   # The boxes may be aligned vertically in different ways: their bottoms
   # or tops may be aligned, or the baselines of text within them may be
   # aligned.

10.6.1 Inline, non-replaced elements:
   # If more than one font is used [...] the height of the content area
   # is not defined by this specification. However, we suggest that the
   # height is chosen such that [...]. Note that this may be larger than
   # any of the font sizes involved, depending on the baseline alignment
   # of the fonts.

which presumably implies that the baselines of glyphs from possibly
different fonts should line up and that the baseline of an inline box is
then defined by that font baseline. If this were stated explicitly it
would probably ease the path to the baseline of an empty inline box
being defined by what it would be if it held any glyphs.


> 
>> Issue 10e:  In the description of the 'baseline' value, which
>> inline-level/table-cell boxes don't have a baseline?  Boxes of type
>> inline-block, inline-table and table-cell are explicitly defined to have
>> one.  Boxes of type run-in which become inline boxes are assumed to
>> behave like normal inline boxes.  But how do such boxes behave?  Boxes
>> resulting from non-replaced inlines are presumed to have a baseline, as
>> described in Issue 10d.   On the other hand it seems natural to treat
>> the inline boxes resulting from inline replaced elements to have no
>> baseline, but this is not stated anywhere; perhaps it can /very/ vaguely
>> be concluded by comparing 10.6.1 with 10.6.2 (calculating height and
>> margins for inline non-replaced elements and inline replaced elements
>> respectively).
> 
> "If the box doesn't have a baseline" does not refer to the parent's
> box

Certainly.

> which is a block-level element and has always a baseline.

Not so; this is precisely issue 8.[2] "Baseline of a block" is sloppy
language.

> Instead
> it refers to the box having that value of "vertical-align": inline
> replaced and inline-block replaced don't have a baseline to align with
> other content, so they align their bottom margin edge.
> 

That is precisely the point that Issue 10e makes: it is not stated
anywhere that inline-level replaced elements do not have a baseline.  It
should be.


I state at this point that I'm fully aware that I'm nit-picking here in
several places as regards the inline formatting model (although not in
others places where the issues I raised are technical rather than
editorial).  I'm also familiar with the history of how the wording of
the current spec came to be (as well explained by Bert Bos in another
thread today[3]).  But the inline formatting model is of such
fundamental importance to CSS that it's distressing to see it presented
piecemeal in various different sections (and chapters) based on
something of a leap of faith, when it could be tidied up pretty easily.


[1] http://www.w3.org/TR/CSS21/visudet.html#leading
[2] http://lists.w3.org/Archives/Public/www-style/2009Aug/0655.html
[3] http://lists.w3.org/Archives/Public/www-style/2009Sep/0037.html

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

Received on Wednesday, 2 September 2009 18:56:15 UTC