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

On Thu, 29 Mar 2001, James Aylard wrote:
>>
>> 3. Treating replaced inline elements in this manner means that the
>> addition of text (including  ) would add whitespace where it
>> was not expected.
>
> ...
>>    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.

Look again at my example from my last message:

   <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; }
   [src=b] { vertical-align: baseline; }
   [src=c] { vertical-align: middle; }
   [src=d] { vertical-align: 1em; }

Could you draw me some diagrams showing how this would be rendered?

You may ignore the whitespace (assume there is no white space or text
in between the images) if that makes it easier to answer.


> You have argued that tables shouldn't be used for such layout.

Tables in the markup, to be precise. CSS tables may of course be used
to great effect, since they do not polute the semantics of the data.


> The Mozilla interpretation thwarts designers who want to develop
> standards-compliant pages that are reasonably consistent across
> browser makes and that degrade gracefully in legacy browsers.

Absolutely not!!! Mozilla has gone to great pains to ensure that there
is a forward migration path and that legacy content will be rendered
as much as possible in backwards compatible ways. David Baron himself
implemented a great deal of the "quirky" inline box model.

Any HTML content that is either missing a DOCTYPE or has an HTML 4.0
Transitional DOCTYPE will be rendered in "quirks" mode. This is very
similar to what the Windows IE6 preview does, in fact.

Publish documents using old DOCTYPEs (or none at all) and Mozilla
renders the pages in a backwards-compatible way. Give an HTML 4.01
Strict DOCTYPE (or an HTML 4.01 Transitional DOCTYPE with a system
identifier part) and Mozilla will render the pages in "standards"
mode, including the strict interpretation of the spec when it comes to
the inline box model.

It is perfectly possible to author standards-compliant pages that
trigger the quirks mode. (Feel free to mail me directly if you want
some help with doing that.)


> I am not convinced that the Mozilla interpretation is correct, but
> only that it can be defended under rigorous questioning through
> citations of the CSS 2 recommendation. :)

That's my definition of correct. :-)


> The Mozilla interpretation seems to argue for theoretical purity (as
> defined by its own interpretation), whereas it seems there is room
> for a little more pragmatic common sense.

That probably sums it up quite well.

-- 
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 Thursday, 29 March 2001 21:12:50 UTC