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

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 28 Mar 2001 16:32:18 -0800 (Pacific Standard Time)
To: Tantek Celik <tantek@cs.stanford.edu>
cc: <www-style@w3.org>
Message-ID: <Pine.WNT.4.31.0103281613460.980-100000@HIXIE.netscape.com>

On Wed, 28 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_".

Clearly we have come to an impasse.

Your argument (as I understand it) is that the spec means

   "If the property is" explicitly "set" by the author "on" the
   element you are looking at and if the element you are looking at is
   "a block level element", then ...

My argument is that the spec means

   "If the property" on the element you are looking at "is" implicitly
   or explicitly "set on a block level element", then...

Your argument has no backing (as far as I can tell) in any other part
of the spec. (Note that this is not necessarily a bad thing.)

I believe my argument has the (weak) backing of CSS2 section 6.1, but
you disagree that it is relevant, and I cannot easily counter that.


Since I see no easy resolution to this, I will instead offer an
alternative solution which should satisfy us both. I am assuming that
your requirement is that the solution be able to provide a backwards
compatible rendering when the author does not explicitly mention the
'line-height' property, regardless of backwards comparability modes.
Similarly, my requirement is that the solution be within my
interpretation of the spec.

How about you define a new value of 'line-height', call it
'-ms-normal', and you define your UA stylesheet to contain:

   :root { line-height: -ms-normal; }

You then define the behaviour of '-ms-normal' to be the backwards
compatible inline box model.

There is no need for your DOM, CSS Parser or Cascade code to know
about this value, in fact your code need not change at all.

The end result is that if the author explicitly mentions 'line-height'
then your code will think it has "been set", while if the author
doesn't mention it, it will still (per CSS) have its cascaded value of
'-ms-normal', and thus you can use your implementation.

This is a description of a theoretical model that in fact matches what
you describe as having implemented. I would be happy with this
interpretation of your implementation, since it fits within my model
of the CSS specification.

Comments?

-- 
Ian Hickson                                     )\     _. - ._.)       fL
Netscape, Standards Compliance QA              /. `- '  (  `--'
+1 650 937 6593                                `- , ) -> ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________
Received on Wednesday, 28 March 2001 19:29:56 GMT

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