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

On Sunday 2009-03-01 20:44 +0100, Anton Prowse wrote:
> 10.6.1 Inline, non-replaced elements
> (http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced) :
>
>   # The vertical padding, border and margin of an inline, non-replaced
>   # box start at the top and bottom of the content area, not the
>   # 'line-height'.
>
>
> Issue 3a:  s/of an inline, non-replaced box/of an inline box of a
> non-replaced element/.

I think the terminology in the spec now is better than what you
suggest, but if we want to change it for consistency (with what I
think is worse), we should only change "box" to "element".

> Issue 3b:  s/content area, not the 'line-height'/content area of each of
> its inline boxes, not the inline boxes themselves/

I think that makes things worse rather than better.  I could see
adding "of each inline box" after "of the content area", though.

> 10.8 Line height calculations
> (http://www.w3.org/TR/CSS21/visudet.html#line-height) :
>
>   # The height of a line box is determined as follows:
>
>   #    1. The height of each inline box in the line box is calculated
>   #       (see "Calculating heights and margins" and the 'line-height'
>   #       property).
>   #    2. The inline boxes are aligned vertically according to their
>   #       'vertical-align' property.
>   #    3. The line box height is the distance between the uppermost box
>   #       top and the lowermost box bottom.
>   #    4. If the resulting height is smaller than the minimal height of
>   #       line boxes for this block, as specified by the 'line-height'
>   #       property, the height is increased to be that minimal height.
>
>
> Issue 4a:  In step 2, how? In "normal" inline text with tall images
> either top- or bottom-aligned, where should the text with
> vertical-align:baseline be positioned in the line box?  In other words,
> where is the strut positioned in the line box?  Firefox 3.1b2 and Opera
> 10a handle the cases differently:
> http://dev.moonhenge.net/css21/test-cases/inline-formatting/alignment.html

This is a known undefined behavior, as I described in detail in the
"indeterminate cases" section of
http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html .
The group decided to leave this undefined:
http://lists.w3.org/Archives/Public/www-style/2004Feb/0148.html

I think we should probably reconsider in an attempt to achieve
greater interoperability.

> Issue 4b:  In step 3, this is not what is done Firefox 3.1b2 and Opera
> 10a).  Rather, a strut is taken into consideration in addition to inline
> boxes when determining the line box:
> http://dev.moonhenge.net/css21/test-cases/inline-formatting/strut.html

...as the first paragraph of
http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height (which
you quote, and point out problems with, below) already says.  I
think that wouldn't have required any changes to this section if we
had instead gone with the formulation where there was an anonymous
inline box wrapping all consecutive inline/text children of a block
(what I've called the "root inline box" for the block) instead of
talking about struts.

> Issue 4c:  In step 4, what is the mechanism for increasing the line box
> height?  Is this a reference to leading? If so, the description is
> incorrect: leading is not applied to the line box itself but rather to
> its inline boxes, and so the height of the line box is not "increased";
> rather, the inline boxes are "increased" to ensure that the line box is
> always as least as hight as the minimal height.

Yeah, this ought to be rewritten to reflect that there's either a
strut or anonymous inline box.

> 10.8 Line height calculations
> (http://www.w3.org/TR/CSS21/visudet.html#line-height) :
>
>   # 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.
>
>
> Issue 5:  Do inline replaced elements such as IMG and OBJECT count as
> empty inline elements?  If so, they need to be excluded from the above.

Not for the above.  But they do still count for line height
calculation.  Maybe the above paragraph should just move to 10.6.1?


> 10.8.1, 'line-height' property
> (http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height) :
>
>   # On a block-level, table-cell, table-caption or inline-block element
>   # whose content is composed of inline-level elements, 'line-height'
>   # specifies the minimal height of line boxes within the element.  The
>   # minimum height consists of a minimum height above the block's
>   # baseline and a minimum depth below it, exactly as if each line box
>   # starts with a zero-width inline box with the block's font and line
>   # height properties (what TeX calls a "strut").
>
>
> Issue 8:  what is a block's baseline?  This is defined for table-cell,
> but not for block, inline-block or table-caption.  Furthermore, is the
> word 'block' appropriate for table-cell or table-caption?

Well, like I said, we wouldn't have had this problem if we hadn't
made up the strut concept.

> 10.8.1, 'line-height' property
> (http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height) :
>
>   # When an element contains text that is rendered in more than one
>   # font, user agents may determine the 'line-height' value according to
>   # the largest font size.
>   #
>   # Generally, when there is only one value of 'line-height' for all
>   # inline boxes in a paragraph (and no tall images), the above will
>   # ensure that baselines of successive lines are exactly 'line-height'
>   # apart.
>
>
> Issue 9a:  s/Generally/for example/

No, since it's only generally true in that case; it's not if font
fallback is used.

> Issue 9b:  s/tall images/inline replaced elements/

maybe "tall images or other replaced elements".  Saying images makes
the spec more concrete and thus more readable, although they are
only one example.

> 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"').

If there were always a root inline box, then, again, we wouldn't
have this problem.

> Issue 10b:  It would be helpful to make explicit the fact that
> 'baseline' is a property of the font (and hence the content area) and
> thus only indirectly a property of the inline box; in particular, it is
> not necessarily inside the inline box.  Maybe do this by highlighting
> the fact that the values for vertical-align are partitioned into two
> classes: those which directly address the position of the inline box, and
> those ('baseline', 'super', 'sub') which address the position of the
> baseline (and hence only indirectly address the position of the inline box).

I disagree with your statement that the baseline is not a property
of the inline box.  Each non-replaced inline box (or whatever we
call the piece after it's been split across lines, not that the spec
is remotely clear about such terminology) has exactly one baseline.
Thus it makes perfect sense to consider it a property of the box.

However, I agree that it can be outside the box.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Friday, 8 May 2009 00:14:30 UTC