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

Eric Meyer wrote:

....
>     Unfortunately, images are by default inline elements, and so (in
> my view) 

and clearly also the view of CSS2

> create a inline box when they appear, and therefore either
> contribute to a line box, or create one to enclose their inline box...

> .....It also happens that all
> this is a problem because inline images are, by default, defined to
> align their bottom edge with the baseline of the line box in which
> they appear.

Don't 'baseline', and all the other values except 'top' and 'bottom',
position the inline box relative to the parent box, rather than the line
box?

> If they were defined to align by default to the bottom
> of the line box, then we wouldn't have this problem.  (Thus the
> solution using 'vertical-align: bottom;'.)

How does this solve the problem of that 'minimal' height, when the only
content is inline replaced?

---------------------------------

Earlier, Ian wrote:

> On Thu, 29 Mar 2001, James Aylard wrote:
>>>
>>>    How would it be rendered in your model, considering you have no
>>>    reference baseline?
>>
>>    CSS 2 section 17.5.3 [1] already addresses the baseline question:
>>
>> "The baseline of a cell is the baseline of the first line box in the
>> cell. If there is no text, the baseline is the baseline of whatever
>> object is displayed in the cell, or, if it has none, the bottom of
>> the cell box...."

> The "baseline of a cell" is not used when aligning inline boxes within
> it, it is only used when aligning cells with each other. That section
> is not relevant to the question at hand.
> 
> It is the baseline of the line box which is relevant, and if you use
> your interpretation, it is undefined. That is what has forced me to
> interpret the spec as David has described it.

Has Mozilla in fact implemented 'David's Inline Box Model'? 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).

David states that his "Anonymous inline boxes are completely different
from the spec. However, they are mainly theoretical, and the resulting
effect is perhaps even just a clarification of the spec."

His model is more than just an interpretation of the spec.

But even he distinguishes between 'anchored' ('baseline', etc. -
relative to the baseline of the parent) and 'loose' ('top' and 'bottom'
- relative to the line box) types of vertical alignment.

I don't think line boxes have baselines in either interpretation.

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 that constrains Mozilla in its handling of inline replaced
elements?


---------------------------------

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.

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?

Is this heresy?

---------------------------------

Even earlier, Ian wrote:

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

I'd been wrestling with a response while the thread moved on. Maybe I
was a little more naive a few hours ago: I actually thought we were
trying to clarify the spec. Duh! :-)

Anyway, I was going to say something along the following lines:

Presumably you're referring to:

  "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."[3]

(Lets leave table cells out of this for the moment...)

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.

And it would be strange if 'vertical-align' only applied to inline
content for which an anonymous inline box had been created by the
parent.

Stranger yet if it implied that an anonymous inline box should be
created by the parent for any inline content with a 'vertical-align'
property.

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. i.e. not BODY, UL, TABLE, FORM, BLOCKQUOTE, etc.

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.


As for replaced inline elements, they will always generate their own
inline boxes, so no anonymous inline box is required from the parent.


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:

  "The baseline of a cell is the baseline of the first line box in the
cell. If there is no text, the baseline is the baseline of whatever
object is displayed in the cell, or, if it has none, the bottom of the
cell box. The maximum distance between the top of the cell box and the
baseline over all cells that have 'vertical-align: baseline' is used to
set the baseline of the row." [2]

... so in the case of replaced inline content, which has no baseline
itself, the baseline of the cell will be the bottom of the cell box.


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

>       [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, which will again be
the bottom of the cell box.


>       [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 plus half the height of the cell box.


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


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


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

It would be nice to know the original intentions of the spec's authors.


Refs:
[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




-- 
Regards,
Val Sharp - Edinburgh

Received on Friday, 30 March 2001 19:27:07 UTC