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

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

I interpret it this way because the following paragraph explains how to
interpret it if it is inline-level, using exactly the same phraseology.


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.

Section 6.1.1, "Specified values", reads:
#
# User agents must first assign a specified value to a property based on
# the following mechanisms (in order of precedence):
#
# If the cascade results in a value, use it.
# Otherwise, if the property is inherited, use the value of the parent
# element, generally the computed value.
# Otherwise use the property's initial value. The initial value of each
# property is indicated in the property's definition.

Since 'line-height' is inherited, the second sentence applies: "use
the value of the parent element". Follow that line of argument up to
the root element to get the initial value 'normal'.

You now have to "use" the value 'normal' for the property 'line-
height', and the sentence in 10.8.1 applies -- the property is set.


> That to me says, "not counting the initial value".

Unfortunately that isn't backed up by any statement, implied or otherwise,
anywhere in the spec, as far as I can tell.


> And I don't accept the "but a property is always set" argument,
> because, if that were true, then that phrase "If the property is set"
> could have been omitted from the above description.

Well, technically it could, but that would result in sentences that are
much more formal and less friendly:

: On a block-level element whose content is composed of inline-level
: elements, it specifies the minimal height of each generated inline box.
:
: On an inline-level element, it specifies the exact height of each box
: generated by the element.

I prefer the more friendly sentences as the spec currently has them.
(With the exception that "inline box" should IMHO be "line box".)


> Obviously the authors of the spec intended the lack of a setting on
> line-height to mean something when they wrote that part of the spec.

"Obviously" they didn't...


> Therefore a perfectly reasonable interpretation which is consistent with
> that part of the spec is vertically shrinking wrapping a line box to its
> contents.  No line-height setting, no line-height "effect".  Done.

What's the computed value of 'line-height' on the relevant element?


> P.S. I also don't accept the "but that statement shouldn't have been
> there, because by removing it, it makes more my model make more sense"
> argument either - that's what we call a circular argument.

Similarly, I don't accept the "but that statement clearly shouldn't be
interpreted in a way consistent with the rest of the spec, because if you
instead interpret it my way, my model makes more sense" argument either.

-- 
Ian Hickson                                     )\     _. - ._.)       fL
Netscape, Standards Compliance QA              /. `- '  (  `--'
+1 650 937 6593                                `- , ) -  > ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________

Received on Monday, 26 March 2001 19:42:12 UTC