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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 01 Mar 2009 20:44:10 +0100
Message-ID: <49AAE58A.1000200@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
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.


---

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/


---

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.


---

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.


---

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/


---

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?)


---

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?


---

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/


---

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


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Sunday, 1 March 2009 19:45:03 GMT

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