Re: Proposal for CSS 2.1 issue 153

On 06/10/2010 19:13, Bert Bos wrote:
> On 23 Jun, 2010, L. David Baron<dbaron@dbaron.org>  wrote:
>
>> http://wiki.csswg.org/spec/css2.1#issue-153 reports that some of the
>> definitions of "box" in the section on vertical alignment are
>> ambiguous.  This was much clearer in CSS 2.0 before section 10.6.1
>> was revised; the revisions made to 10.6.1 since then have made it
>> ambiguous.
>>
>> The proposal previously in the issues list (from Elika, I think)
>> was to add:
>>    # In the following definitions, for replaced, inline-block, and
>>    # inline-table elements, the box used for alignment is the margin
>>    # box. For inline non-replaced elements, the box used for
>>    # alignment is undefined.
>>
>> I would propose that instead, we add:
>>    # In the following definitions, for inline non-replaced elements,
>>    # the box used for alignment is the box whose height is the
>>    # 'line-height' (containing the box's content area and the
>>    # half-leading on each side).  For all other elements, the box used
>>    # for alignment is the margin box.
>
> After we made the half-leading unambiguous (issue 118[1]), it is clear
> that an inline box has a height of 'line-height' *or more* (viz., in
> certain cases where the inline box contains glyphs from fonts with
> different metrics, or when it contains other inline boxes from child
> elements). Nowhere do we have a box defined that is
> always 'line-height' high.

I for one tended to interpret the current wording of the spec 
differently, and so for me this resolution to Issue 118 is a change from 
the current spec. (I confess that I didn't notice that this change has 
the consequence you describe.)  As I tended to read it, there used to be 
a box which was line-height high, because leading appeared to be defined 
for the entire box as the difference between content height and 
line-height (not that the spec was very clear about it, which is why I 
raised the issue in the first place).  It was those boxes, line-height 
high, that were aligned according to the vertical-align property.  With 
the resolution, however, vertical-align acts on these newly-defined 
boxes which may be more than line-height high.

My immediate question is whether there interop for this "change". 
(Perhaps it's what browsers were doing anyway and hence it's merely a 
clarification and not a change at all... but I'd prefer some 
demonstration of that.  I imagine that vertical-align:middle can produce 
a different rendering depending on which boxes are being acted upon.)


> Thus, in David's proposed text above, "the box whose height is
> the 'line-height'" isn't a well-defined concept.
>
> We do have a well-defined term "inline box" now. (Issue 120[2] added
> that to section 9.2.2, while issue 118 defined its height in section
> 10.8.1). Unfortunately, that is not the box that 'vertical-align' acts
> on. E.g., the vertical position of "abc" in
>
>      ...<span style="vertical-align: middle">abc<sup>2</sup></span>...
> and
>      ...<span style="vertical-align: middle">abc</span>...
>
> should be the same, despite the fact that the first SPAN has a taller
> inline box than the second.
>
> I can see two approaches: we can define a special kind of box just for
> the purposes of 'vertical-align', a box whose height does not depend on
> child elements;

This is precisely my concept of "guide boxes" that I introduced near the 
end of [1].  (I wrote there that "the height of each guide box is 
determined only by the value of the line-height property on the inline 
box", which was based on my interpretation discussed above; but with the 
new resolution to Issue 118 the guide box height is now determined by 
the metrics of the glyphs in addition to the 'line-height' property.)


> or we can change 9.2.2 and 10.8.1 so that "inline box"
> itself is defined as such a box.

That might work.  It would take careful checking that it doesn't cause 
problems elsewhere, though.


> In the original model for CSS (which was never very explicit), mark-up
> such as<EM>abc<STRONG>def</STRONG>ghi</EM>  created three inline boxes,
> not one box with another one inside.

It's still the case the Chapter 9 is unclear on this, and the proposal 
for Issue 120 does not assist here.  However, that model is not what we 
want, right?  For example, we don't want a border on the EM to break 
around the STRONG.


> The definition of 'vertical-align' was written with those boxes in
> mind.

> If we take that approach, then David's proposed text to add
> to 'vertical-align' becomes:
>
>    | In the following definitions, for inline non-replaced elements,
>    | the box used for alignment is the inline box (containing the
>    | box's content and the half-leading). For all other elements, the
>    | box used for alignment is the margin box.
>
> The definition of inline box in 9.2.2 (cf. issue 120[2]) could be
> rewritten as:
>
>    | A non-replaced element with a 'display' value of 'inline'
>    | generates one or more<dfn>inline boxes</dfn>. An element with
>    | a 'display' value of 'run-in' can also generate inline boxes; see
>    | _run-in boxes_. Inline boxes contain all text of the element that is
>    | not in a child element. If the element has neither text nor child
>    | elements, it generates one inline box containing a strut[ref to
>    | 10.8.1].
>    |
>    | Example:<span>abc<em>def</em></span>  generates two inline boxes,
>    | one containing "abc", the other "def".
>    |
>    | Inline-level boxes that are not inline boxes (such as
>    | replaced inline-level elements, inline-block elements, and
>    | inline-table elements) are called<dfn>atomic inline-level
>    | boxes</dfn>  because they participate in their inline formatting
>    | context as a single opaque box.
>
> (This avoids to say how many inline boxes are generated exactly, because
> that is difficult, as it depends on line breaking, hyphenation and
> bidi-reordering...)
>
> The definition of leading in 10.8.1, which defines the height of the
> inline box, could be modified as follows:
>
>    | User agent must align the glyphs in a non-replaced inline box to
>    | each other by their relevant baselines<del>, and to nested inline
>    | boxes according to 'vertical-align'</del>.
>    | ...
>    | The height of the inline box is then the smallest such that it
>    | encloses all glyphs and their leading<del>, as well as all nested
>    | inline boxes</del>.
>
> I think that defines 'vertical-align' correctly and doesn't harm the
> other places where "inline box" is used (some of which, such as 9.2.2.1
> and 9.4.2 in fact still use this model), except for two:
>
> Section 10.1 says: "In the case that the ancestor is an inline box, the
> containing block depends on the 'direction' property of the ancestor
> [...]". But an inline box doesn't have children. Earlier text said: "In
> the case that the ancestor is inline-level, [...]" and what is actually
> meant is an ancestor that is 'inline' or 'run-in'.
>
> Section 9.2.1.1 says:
>
>    # When an inline box contains an in-flow block-level box, the inline
>    # box (and its inline ancestors within the same line box) are broken
>    # around the block-level box.
>
> It should say:
>
>    | When an inline element contains an in-flow block-level element, the
>    | inline element (and its inline ancestors within the same line box)
>    | are broken around the block-level box.

See my comment above.  How do box model properties on the outer 
inline-level element interact with the rendering of the inner inline 
element if there's no nesting?  I know that the padding, border and 
margins already bleed out of the inline-level box, but it's going to be 
rather more difficult to explain that they bridge disconnects as well, 
such as in your <EM>abc<STRONG>def</STRONG>ghi</EM> example.


> [1] http://wiki.csswg.org/spec/css2.1#issue-118
> [2] http://wiki.csswg.org/spec/css2.1#issue-120

   [3] http://lists.w3.org/Archives/Public/www-style/2010Jul/0535.html

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Saturday, 9 October 2010 10:51:24 UTC