W3C home > Mailing lists > Public > www-style@w3.org > March 2001

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

From: Tantek Celik <tantek@cs.stanford.edu>
Date: Mon, 26 Mar 2001 17:15:55 -0800
To: Ian Hickson <ian@hixie.ch>
CC: James Aylard <jaylard@pixelwright.com>, www-style@w3.org
Message-ID: <1226466775-349107037@psdbay.com>
From: Ian Hickson <ian@hixie.ch>
Subject: Re: CSS 2: Table Cells and the "line-height" Property
Date: Mon, Mar 26, 2001, 4:44 PM

> On Mon, 26 Mar 2001, Tantek Celik wrote:
>>> No. You have forgotten section 10.8.1, which says how 'line-height'
>>> applies to blocks [1]:
>>>
>>> # If the property is set on a block-level element whose content is
>>> # composed of inline-level elements, it specifies the minimal height
>>> # of each generated inline box.
>>
>> So far so good.
>>
>>> The initial value of 'line-height' is normal,
>>
>> A-ha! - here is the faulty leap.
>>
>> 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".

Again, this is a leap.

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

But, this is in direct contradiction with the "_is_set_" conditional which
implies that there can be a different behavior if is "not set", which
implies that that condition can occur.


Thus we have a contradiction that needs to be resolved.


I think the preferred way to resolve such contradictions, is in such a way
as to be maximally backward compatible.

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.

To do otherwise (that is, to make CSS default behavior _incompatible_ with
traditional HTML rendering), would do nothing but alienate web authors from
CSS.

So, in summary:

 'line-height:normal' should do what traditional HTML user agents do when
formatting unstyled "lineboxes" as you say.  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.

We certainly shouldn't define something (like line-height) a certain way
just because it makes it easier to define/implement (though those are good
things to keep in mind as secondary goals).

We should define these concepts/features/technologies primarily in such a
way as to be easy to author, and to be compatible with present content.  If
being compatible with all present content is too difficult, then you make
sure you are compatible with the common 90% cases, etc.

Some might even call that user-centered design, as opposed to
implementer-centered design.

Tantek
Received on Monday, 26 March 2001 20:16:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:08 GMT