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

From: Ian Hickson <ian@hixie.ch>
Subject: Re: CSS 2: Table Cells and the "line-height" Property
>Date: Tue, Mar 27, 2001, 3:52 PM
>

> On Mon, 26 Mar 2001, Tantek Celik wrote:
>>>>
>>>> Note that in description in specifically said:
>>>>
>>>> "_If_ the property is set "
>>>
>>> Woah. It says "if the property is set *on a block-level element*".
>>> (Emphasis mine).
>>>
>>> I interpret that to mean that "if you are looking at this property
>>> on an element trying to work out what to do with it and you find
>>> that element to be block level, then...".
>>
>> Nope. "if the property _is_set_" means something very different than
>> "if you are looking at this property".
>
> *Context*. "if the property is set _on_" means something very
> different to "if the property _is_set_".

You are changing your interpretation of the association of "on".

It's "_on_a_block-level_element", as your "(Emphasis mine)" quote above
reads.

It is not "_is_set_on_".

> The latter is redundant in
> CSS, as per CSS2 section 6.1 [1]:
>
> # Once a user agent has parsed a document and constructed a document
> # tree, it must assign, for every element in the tree, a value to
> # every property that applies to the target media type.

Not redundant.

"assign"  !=  "set"

Of course every user agent could be set to _assign_ a value to every
property, but that is certainly not the same as an author _setting_ a
property value.

>>> Anyway, there is no way in CSS to tell the difference between a
>>> property that is never mentioned at any point in the stylesheet(s)
>>> and one that is explicitly set to its initial value.
>>
>> I'm willing to accept that a subset of the CSS spec implies this,
>> and therefore some implementations may have this limitation.
>
> This is not a limitation, it is a fundamental axiom of the CSS model.

You consider it to be an axiom of CSS, I consider it to be implied by a
subset of CSS.

>> Thus we have a contradiction that needs to be resolved.
>
> There is no contradiction...

I consider it a contradiction.  It is at least an ambiguity.

>> In other words - I am stating the general principle that CSS default
>> behaviors (call them initial values if you like) should be backward
>> compatible with default traditional HTML rendering.
>
> This is not the way things are.

Actually, this is very much how things were developed in CSS.

> The CSS inline box model is but one of
> many areas where the CSS spec is not "backwards compatible"

Not true.  There are very few.  The vast majority of CSS properties/values
are very much backwards compatible with what HTML presentation does.

> with the
> mutually incompatible renderings that existed before it.

Of course implementations had differences.

However, this sounds like you agree that if implementations were consistent
in the past, then that consistency should be carried forward.

Certainly I would argue that professional web authors strongly believe that.

> Other
> examples include floats, font selection, font size selection,
> backgrounds, underlining, and user preferences, to name but a few.

You are lumping together all that HTML presentation got right, all that it
mostly got right but had a few bugs with, and some that were problematic in
general.

Treating these cases indiscriminately is wrong.  Or reductio ad absurdum at
best.

To address your specific examples:

> floats

Essentially work the same.  CSS fixed some edge cases to work better.

> font selection

CSS is a proper superset of HTML here.  No backwards compat problems.

> font size selection

Though it wasn't necessarily easy, we (in IE5/Mac) were able to resolve the
HTML FONT SIZE=1..7 model with the CSS font-size values in such a way as to
be backwards compatible with the most common implementations.

> backgrounds

CSS specifically says that backgrounds on BODY apply to the whole canvas if
there is nothing set on HTML.

I can't believe you raised this example because CSS specifically went out of
its way to try to be backwards compatible with HTML presentation here.

> underlining

Agreed that this one is problematic.  We may still want to find a way to fix
this.

> user preferences

Again, we saw no problem here.


> At least three separate browser codebases have managed to cope with
> this issue using DOCTYPE-derived modes (MacIE, N6, and the upcoming
> Windows IE6).

I wrote the DOCTYPE switch as a last resort to compatibility.

It is specifically there for distinguishing between correct and _expected_
behavior, as opposed to buggy behavior.

The DOCTYPE switch is NOT an open license to completely redefine how
presentation works in HTML.

> The backwards compatible model is often rooted in ridiculous reverse
> engineering feats that, while impressive in their own right, have very
> littly logic involved.

You are lumping together bugs with proper expected behaviors.

Backwards compatibility with "bugs" is one thing.  And that is what the
DOCTYPE switch is for.

Backwards compatibility with simple expected behaviors are another, and that
should always work.

>> 'line-height:normal' should do what traditional HTML user agents do
>> when formatting unstyled "lineboxes" as you say.
>
> Modulo some minor disagreements of edge cases, CSS2 is very clear as
> to how the inline box model should work.

LOL.

You have to be joking.

"very clear as to how the inline box model should work"?

I bet you could count on one hand the number of web authors and browser
implementers that fully understand "how the inline box model should work".

> It is not fully backwards
> compatible. That is no big deal;

No, it is a big deal.

HTML's "inline box model" had some very nice simplifications, like
vertically shrink wrapping by default.

Simpler models are easier to understand and easier to author to.

Whenever possible (I believe it is possible in this case) richer models
should be built upon them, as a superset.

Not as a replacement thereof.

>> if that is tough to define, then so be it. Nobody said it was
>> supposed to be easy to work on a W3C specification.
>>
>> Yes, this may be difficult to define, but that's our job.
>
> The "backwards compatible" inline box model includes "the last line of
> the last LI in an OL should have the height of the parent's
> 'line-height'" [2]. If I see that in a W3C spec I will cry. :-/

Again, you are lumping buggy/inconsistent backwards compatibility with
"simple" backwards compatibility.

You are missing the point.


Here is a simpler restatement of the problem.

Excess white space is considered a _bug_, not a feature.

This is why the CSS working group decided to refine :first-letter as to NOT
cause excess white space by default, and to cause the first-letter to be
treated as a replaced element instead, in order to easily achieve common
drop caps and standing caps effects without having to futz with negative
margins etc.


A single image in a table cell is a similar case.

 <table><tr><td><img></td></tr></table>

This example, as previously pointed out, _does_not_ have extra white space
surrounding the image in traditional HTML rendering.

This is what authors want, and is correct for a default behavior.

If you want extra white space, you can add it using padding, margins,
transparent borders etc.

The CSS inline box model needs to handle such simple cases in the expected
way, or else it is the CSS inline box model which is broken, not the simple
case.

I'll say it again, breaking compatibility with HTML presentation when it
could have just has easily been made compatible, will do nothing more than
alienate web authors from CSS.

This case is far worse.

Introducing or redefining features which are more difficult to use than they
need to be (read: the simple case is not so simple to understand/write),
will all by itself alienate web authors from CSS, even independent of
compatibility considerations.

Tantek

Received on Wednesday, 28 March 2001 11:17:28 UTC