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

Anton Prowse wrote:
> I have identified some issues with the specification of the inline
> formatting model in CSS21.  Most are editorial, but a couple are more
> serious.
> 
> 9.2.2.1 Anonymous inline boxes
> (http://www.w3.org/TR/CSS21/visuren.html#anonymous) :
> 
>   # In a document with HTML markup like this:
>   #     <p>Some <em>emphasized</em> text</p>
>   # The <p> generates a block box, with several inline boxes inside it.
> 
> Issue 1:  s/The/the/
> 
> ---
> 
> 9.4.2 Inline formatting context
> (http://www.w3.org/TR/CSS21/visuren.html#inline-formatting) :
> 
>   # A line box is always tall enough for all of the boxes it contains.
>   # However, it may be taller than the tallest box it contains (if, for
>   # example, boxes are aligned so that baselines line up).  When the
>   # height of a box B is less than the height of the line box containing
>   # it, the vertical alignment of B within the line box is determined by
>   # the 'vertical-align' property.
> 
> Issue 2:  'vertical-align' should be linked to its property definition.

Filed as Issue 116.

http://wiki.csswg.org/spec/css2.1#issue-116

> ---
> 
> 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/.
> 
> Also cf.  "Although margins, borders, and padding of non-replaced
> elements do not enter into the line box calculation, they are still
> rendered around inline boxes." [10.8.1 Leading and half-leading
> (http://www.w3.org/TR/CSS21/visudet.html#leading)]
> 
> Issue 3b:  s/content area, not the 'line-height'/content area of each of
> its inline boxes, not the inline boxes themselves/

I disagree with these changes. In particular, the way it's worded
right now allows the text to describe individual boxes generated
by a single element. Also the change proposed in 3b doesn't make
any sense to me.

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

Filed as Issue 117.
http://wiki.csswg.org/spec/css2.1#issue-117

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

No, they have content. It's replaced content, but it's still content.
An empty inline element would be e.g. <span></span>.

> 10.8.1 Leading and half-leading
> (http://www.w3.org/TR/CSS21/visudet.html#leading) :
> 
>   # Since the value of 'line-height' may be different from the height of
>   # the content area there may be space above and below rendered glyphs.
> 
> 
> Issue 6:  s/'line-height'/'line-height' for an inline box/
> and:  s/the content area/its content area/

Added to Issue 116.
http://wiki.csswg.org/spec/css2.1#issue-116

> 10.8.1 Leading and half-leading
> (http://www.w3.org/TR/CSS21/visudet.html#leading) :
> 
>   # The difference between the content height and the used value of
>   # 'line-height' is called the leading
>   #
>   # User agents center glyphs vertically in an inline box, adding
>   # half-leading on the top and bottom.
> 
> 
> Issue 7: is it the glyphs which are centered, or the content area of the
> inline box containing the glyphs?  Is the leading added to the glyphs or
> to the content area?  (Is this difference moot?)

Good catch. This wording is probably wrong in the case of glyphs
in fonts like, e.g. Zapfino where the glyphs extend far outside
their bounding box.

Filed as Issue 118:
   http://wiki.csswg.org/spec/css2.1#issue-118

The height of the content area is given in
   http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced
and does not rely on line-height.

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

Filed as Issue 119
   http://wiki.csswg.org/spec/css2.1#issue-119

This would be a case where the old concept of a "root anonymous inline"
that wraps all the block's inline content would improve the explanation.

Would simply replacing "block's baseline" with "baseline" be sufficient?

 > Furthermore, is the word 'block' appropriate for table-cell or table-caption?

I think the spec is pretty lax on this one in general. The best way
to fix it would probably be to define for table-cell, table-caption,
and line-block elements that their contents are laid out exactly as
if they were blocks and let the spec just talk about blocks.

I'll ask the WG what to do about this. Filed as Issue 120.
   http://wiki.csswg.org/spec/css2.1#issue-120

> ---
> 
> 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/
> 
> Issue 9b:  s/tall images/inline replaced elements/

Or inline blocks or inline tables... If we want precision, this
paragraph needs rewriting. Filed as Issue 121.
   http://wiki.csswg.org/spec/css2.1#issue-121

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

Added to Issue 117. We can split it out later if we need to, but it seems
edits for 117 might need to take these into account.
   http://wiki.csswg.org/spec/css2.1#issue-117

~fantasai

Received on Wednesday, 6 May 2009 23:40:25 UTC