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

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 Sunday, 24 May 2009 11:31:32 UTC