Re: CSS 2: Table Cells and the "line-height" Property

On Sat, 31 Mar 2001, ValerieGSharp wrote:
>
> Has Mozilla in fact implemented 'David's Inline Box Model'?

That certainly is the intent. It's supposed to be my job to actually
check that in fact we have done so. I haven't fully done that yet...


> I which case I assume all inline boxes in a line box are actually
> descendents of a root/anonymous inline box (itself being the sole
> child of the line box).

Well, it's not actually implemented like that (as David says, the
anonymous boxes are merely theoretical models) but the effect should
be the same, yes.


> In both interpretations anonymous inline boxes have baselines, but
> in David's model every inline element (including replaced elements)
> will be a child of an anonymous inline box.
>
> Is it this what constrains Mozilla in its handling of inline
> replaced elements?

'constrains' is a loaded word, I prefer to say 'guides'... ;-)

But yes. This is the explanation for Mozilla's behaviour.


> Regarding David's model, it aims to be a clarification, with a few
> changes, but instead it introduces not only a whole menagerie of
> needless terms, but also a root inline box that completely changes
> the CSS2 concept of anonymous inline boxes.

This is the problem with theoretical models -- you can change them
completely, without changing the end result. David's interpretation
explains things in a more logical (IMHO) fashion, but the end result
is an interpretation which is (modulo a few suggested errata items
that nobody has argued shouldn't be changed) within the spec.


> I don't know why the parent element couldn't have simply provided a
> _notional_ baseline for the alignment of inline content. Why did it
> have to be made concrete in form of the root inline box?

It's just a model. So long as the model is self-consistent, you can
think of many different ways of explaining it. Theoretical models
often differ dramatically (in design, not in end result) from actual
implementations, since implementations are constrained by performance
requirements. A specification should be easy to explain; an
implementation should be fast and maybe relatively easy to write.

For example, as I understand it the Mozilla code doesn't have
anonymous root inline boxes, it just assumes that every line box
contains an empty inline element that is a child of the parent
block-level box and which is baseline aligned with the rest of the
boxes in the line box. Same effect; different model.


> Is this heresy?

   heresy. n. A controversial or unorthodox opinion or doctrine, as in
   politics, philosophy, or science.

What's the orthodox/conventional opinion? Is there one? ;-) (I don't
claim David's is the orthodox interpretation!!!)


>> 4. If the replaced inline elements do not have a parent anonymous
>>    inline element to provide a baseline, then the behaviour of
>>    'vertical-align' becomes undefined.
>
> Presumably you're referring to [3]:
>
> # The following values only have meaning with respect to a parent
> # inline-level element, or to a parent block-level element, if that
> # element generates anonymous inline boxes; they have no effect if
> # no such parent exists.

Woah. Interesting. That's _got_ to be wrong. ;-)

   <div><span> Hello </span><span> World </span></div>

...doesn't match either of those, and yet

   span { font-size: 200%; vertical-align: 1ex; }
   span + span { font-size: 50%; vertical-align: baseline; }

...is definitely expected to have an effect.

This seems like yet another reason to assume anonymous inlines wrap
all inline content. ;-)


> This is surely _not_ implying that anonymous inline boxes are
> generated for all inline content, since I understand that a block
> will generate an anonymous inline box only for inline content that
> doesn't have an associated inline element.[1] i.e #PCDATA not
> contained in an inline element.

This is one of the changes in David's model, right.


> Surely all it is saying is that this property can only be
> interpreted relative to a parent element that has an implicit
> baseline i.e. an element that can generate anonymous boxes to
> contain otherwise naked #PCDATA.

Sounds like a fair interpretation to me (same result as David's, as
far as I can tell).


> Though I will admit that makes that paragraph somewhat redundant,
> since the property only applies to inline elements anyway, and
> inline elements can only occur within other inline elements, or
> within parent block elements that are also able to generate
> anonymous inline boxes.

Right.


> The use of 'vertical-align' on (as opposed to within) table cells is
> explained separately,[2] and is probably not relevant here.
>
> However, the same section goes on to describe how the baseline of a
> cell is derived from its content [...]

As I mentioned before, the baseline of a _cell_ (as opposed to the
'inner block formatting context' of the cell) is only relevant to
inter-cell alignment.


>>    Take, for instance, the following markup:
>>
>>       <td>
>>        <img src="a" alt="a" height="10" width="10" />
>>        <img src="b" alt="b" height="20" width="30" />
>>        <img src="c" alt="c" height="30" width="30" />
>>        <img src="d" alt="d" height="40" width="40" />
>>       </td>
>>
>>    ...with the styles:
>>
>>       [src=a] { vertical-align: bottom; }
>
> "Align the bottom of the box with the bottom of the line box."[3] - the
> cell box will contain a line box - no baseline required.

Right.

>>       [src=b] { vertical-align: 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 of the box with
> the parent's baseline."[3]
>
> Since the replaced element doesn't have a baseline itself, the
> bottom of the element will be aligned with parent's baseline,

Ok...

> which will again be the bottom of the cell box.

This is the jump you are making. There is nothing in the spec that
says this. In this case, the baseline is undefined by the spec. If you
are misled by the text that speaks about "the baseline of the cell",
simply image the image is wrapped in a <div> in the cell, or some
such. The block element does not have a baseline defined. This is in
fact precisely what David is clarifying in his document.


>>       [src=c] { vertical-align: middle; }
>
> "Align the vertical midpoint of the box with the baseline of the
> parent box plus half the x-height of the parent."[3], which will be
> the bottom of the cell box

...arguable, see above, but let's ignore that for now...

> plus half the height of the cell box.

The 'x-height of the parent' is half the size of '1ex' which is
decided by the font-size. But whatever, that's a minor point.


>>       [src=d] { vertical-align: 1em; }
>
> "<length>  Raise (positive value) or lower (negative value) the box by
> this distance. The value '0cm' means the same as 'baseline'."[3] So the
> box is raise by 1em above the bottom of the cell box.

Ok. So far, so good. Now let's add the spanner in the works:

    <img src="e" alt="e" height="10" width="10" />
    [src=e] { vertical-align: -1em; }

Does this "create" a baseline in your model?


>>    How would it be rendered in your model, considering you have no
>>    reference baseline?
>
> Surely baselines are only meaningful in relation to text, and where
> there is no text the baseline would reasonably default to bottom.

"Surely"?

Why? IMHO it looks a lot more consistent if images are aligned to the
same baseline as text.


>> As I mentioned before, my interpretation of the CSS2 inline box
>> model...
>
> This proliferation of models and interpretations is worrying. I can
> see we will still have the problem of different UAs producing
> significantly different renderings, only now they'll all be
> 'conforming' UAs!

There are only two, as I see it:

 1. Apply the minimum line-height rule by just increasing the size of
    the line box and aligning the boxes in it at the bottom.

 2. Apply the minimum line-height rule by assuming every line box has
    an anonymous inline box that sets the baseline (for alignment) and
    the minimum line box height. (aka, David's interpretation)

The first interpretation causes some odd results in edge cases
involving only text:

   <div>
     a b c a b c a b c a b c a b c a b c a b c a b c a b c a b c a b c
     <span> lots of text lots of text lots of text lots of text </span>
     a b c a b c a b c a b c a b c a b c a b c a b c a b c a b c a b c
   </div>

   div { font-size: 100px; line-height: 1.0; }
   span { font-size: 10px; }

How would you align the <span> in a line box where only it appeared?

The second interpretation resolves these odd results, but sacrifices
some backwards compatability in the replaced-content-only case.

They are both valid per the spec (assuming proposed errata).

-- References --
 [1] http://www.w3.org/TR/REC-CSS2/visuren.html#anonymous
 [2] http://www.w3.org/TR/REC-CSS2/tables.html#height-layout
 [3] http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-vertical-align

-- 
Ian Hickson                                            )\     _. - ._.)   fL
Invited Expert, CSS Working Group                     /. `- '  (  `--'
The views expressed in this message are strictly      `- , ) -> ) \
personal and not those of Netscape or Mozilla. ________ (.' \) (.' -' ______

Received on Wednesday, 4 April 2001 03:45:20 UTC