W3C home > Mailing lists > Public > www-style@w3.org > September 2009

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

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Wed, 2 Sep 2009 12:50:09 +0200
Message-ID: <65307430909020350h3fce54d1p67202b8b99774a23@mail.gmail.com>
To: Anton Prowse <prowse@moonhenge.net>
Cc: "www-style@w3.org" <www-style@w3.org>
2009/9/1 Anton Prowse <prowse@moonhenge.net>:
> Anton Prowse wrote:
>>
>> 10.8.1, 'vertical-align' property
>> (http://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align) :
>>
>>  # This property affects the vertical positioning inside a line box of
>>  # the boxes generated by an inline-level element.
>>  #
>>  # 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.
>>  #
>>  # 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.
>>
>>
>> Issue 10a:  If 'strut' is going to be used normatively, it should be
>> defined explicitly in 10.8.1 rather than by example ('what TeX calls a
>> "strut"').
>>
>>
>> Issue 10b:  [...]
>>
>
> Some more issues come to light from the recent correspondence about
> baselines and struts.
>
>
> 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.

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

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

>
> 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, which is a block-level element and has always a baseline. 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.

>
> [1] http://lists.w3.org/Archives/Public/www-style/2009Aug/0655.html
> [2] http://lists.w3.org/Archives/Public/www-style/2009May/0191.html
>
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
>
>
>
>

Giovanni
Received on Wednesday, 2 September 2009 10:50:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT