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

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Fri, 11 Mar 2011 19:12:28 +0000
To: "Anton Prowse (prowse@moonhenge.net)" <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2AB8CB6B@TK5EX14MBXC113.redmond.corp.microsoft.com>
Anton,

The CSSWG has resolved to edit the CSS2.1 specification [1] to reflect your feedback.

Please respond before 14 March, 2011 if you have an issue with this resolution.
 
[1] http://w3.org/TR/CSS


Original messages: http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html (issue 3b)
http://lists.w3.org/Archives/Public/www-style/2009May/0191.html 
ISSUE-281: http://wiki.csswg.org/spec/css2.1#issue-281

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


From: Anton Prowse <prowse@moonhenge.net> 
Date: Sun, 24 May 2009 13:30:21 +0200
 Message-ID: <4A192FCD.1060101@moonhenge.net> 
To: "www-style@w3.org" <www-style@w3.org> 

L. David Baron wrote:
> 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.

fantasai picked me up on Issues 3a and 3b, too:[1]

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


The issue in 3a is that boxes are not "replaced" or "non-replaced"; 
elements are.  Moreover, my proposed wording was consciously intended to 
preserve the nuance that fantasai mentions (hence "of an inline box" 
instead of "of the inline box").

As David suggests, we could replace "box" by "element" -- but then, as 
he recognises, we have a problem later in the sentence, because "content 
area" is a property of a box, not an element.  (As we know, the spec is 
rife with terminology problems on this point.)  So IMO we need to adopt 
both of David's suggestions together (which is the same as my proposal, 
except more elegantly worded).


The issue in 3b is that that the sentence currently makes no sense:

   # The vertical padding, border and margin [..] start at [..] the
   # 'line-height'.

'line-height' is a property (and its values are 'quantities') not a 
physical entity; nothing can "start" there.  I do think this needs 
resolving.


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

I wasn't aware of your earlier email or the WG resolution, but I'm 
certainly in favour of greater interop here.

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

Of course; I was pointing out that this information needs to be 
explicitly reiterated the section "The height of a line box is 
determined as follows:" I quoted -- and possibly doesn't need to be in 
the first paragraph at all.

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

I wasn't aware of your proposal, but I'm inclined to agree with it. 
Whilst I think it's possible to resolve the issues in this section using 
more careful use of the concept of strut, given that CSS is so heavily 
box-oriented I think your proposal feels more natural, and probably 
makes the whole section easier to explain.


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

That sounds reasonable.


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

fantasai agrees with you and says:[1]

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

Possibly.  In CSS21, baseline is sometimes treated as a property of text 
(font?) and sometimes by association as a property of boxes.  (Although 
see David's comment below.)  I think it would still need to be more 
carefully defined as to /which/ boxes we're talking about in the case of 
"block" and "table-caption".

Note that I incorrectly said that baseline is not defined for 
inline-block; in fact it is defined for both inline-table and 
inline-block at the bottom of the section for 'vertical-align'; these 
definitions should probably be moved up to the 'line-height' section if 
we don't move to the "root inline box" 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.

Good point.  Agreed.


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

Ok, I'll concede this.  The baseline is determined by the font(s) used, 
and the spec uses both "the baseline of the text" and "baseline of the 
box" freely; I agree that there is no loss in this flexibility. 
Initially, though, it took me a short while to realise that the baseline 
of an inline box wasn't something that existed without reference to the 
text it contained, hence my request for a more explicit description of 
this point.


[1] http://lists.w3.org/Archives/Public/www-style/2009May/0035.html

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Friday, 11 March 2011 19:13:03 GMT

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