Re: [CSS21] [Section 6.2.1] inherit keyword versus specified value instead of computed value of its parent's property

On 18/05/2011 22:08, "Gérard Talbot" wrote:
>
> Le Mer 18 mai 2011 4:56, Øyvind Stenhaug a écrit :
>> On Tue, 17 May 2011 21:44:50 +0200, GĂŠrard Talbot<www-style@gtalbot.org>
>> wrote:
>>> The Proposed Recommendation of CSS 2.1 changed important words
>>> in section 6.2.1 [1], which are highlighted in green and
>>> red+striken in C.8.49:
>>> http://www.w3.org/TR/CSS21/changes.html#q543
>>>
>>> My question relates to this sentence:
>>> "
>>> Each property may also have a cascaded value of 'inherit', which
>>> means that, for a given element, the property takes the same
>>> specified value as the property for the element's parent.
>>> "
>>> http://www.w3.org/TR/CSS21/cascade.html#value-def-inherit
>>>
>>> "the property takes the same computed value" [2]
>>> has been replaced with
>>> "the property takes the same specified value" [1]
>>> which makes a huge difference. Consider now this test:
>>>
>>> http://test.csswg.org/suites/css2.1/20110323/html4/border-width-011.htm

No change in behaviour has been introduced; it's simply that the new 
text lacks a bit of clarity.

In previous releases of CSS21, Chapter 6 appeared to say that if (what 
CSS3 calls) the cascaded value of a property is 'inherit' then the 
computed value is the same as that of the parent's property.  Although 
it was not explicitly stated, 6.2.1 also implied that the specified 
value in this case is 'inherit'.  I claimed in Issue 259 that this 
contradicted 6.2, which stated that, when inheritance occurs, the 
computed value from the parent element becomes both the specified value 
and the computed value on the child (and hence the specified value is 
not 'inherit').  However, the fact that 6.2.1 does not explicitly state 
that the specified value is 'inherit', taken with the fact that, when 
the cascaded value is 'inherit', "inheritance" (as defined by CSS21) 
doesn't occur at all (first sentence of 6.2 linking to 6.1.1) and so 6.2 
doesn't apply, meant that the problem was not so much a contradiction as 
a failure to define specified value when the cascaded value is 
'inherit'.  The issue became how to define specified value.

Peter Moulder noted that most of the spec expected the specified value 
to be other than 'inherit'.  fantasai proposed a change to 6.2.1 that 
aimed to bring CSS21 in line with CSS3, where the concept of cascaded 
value is introduced [css3-values] and specified value is explicitly 
defined to not take the value 'inherit'.  In CSS3, the use of 'inherit' 
is explicitly stated to invoke inheritance [css3-values, css3-cascade] 
and so the fact that CSS21 indirectly said the opposite was probably a 
bug; this means that CSS21 is best interpreted as saying that the 
specified value is the computed value of the parent's property, which 
matches what CSS3 explicitly states.

The problem is that fantasai's proposed change defines the specified 
value to be the same as "the property for the element's parent", which 
is itself unclear: does it mean the same as the specified value of the 
parent property, or the same as the computed value of the parent 
property?  Gérard assumed the former (which is the most logical 
interpretation based on the grammar of the sentence), but only the 
latter interpretation matches both CSS3 and (the best interpretation of) 
older CSS21 and also avoids the non-trivial changes in behaviour 
illustrated by Gérard.

Hence the solution to Gérard's problem is to be make fantasai's change 
clearer.


>> I think the
>> intention might be that the<p>  in that test gets 2em as specified value
>> for 'border-width'
>
> That seems contradictory, illogical.
> And no webpage debugger does that. The specified value for the<p>'s
> border-width is inherit in Firefox DOM inspector, Opera DragonFly,
> webkit's web inspector. None of them give 2em as specified value.

No, the specified value is '0' (the computed value of the parent's 
property).  The cascaded value is 'inherit' and the computed value is 
'0'.  The various inspection tools have traditionally always shown the 
cascaded value, since that's normally what authors are interested in 
when debugging.  On the other hand the specified value is what the specs 
are usually interested in, since it allows them to ignore the 
inheritance "pre-processing" phase and just assume a sensible value 
without burdening the prose with conditionals.


One more thing whilst we're at it:  fantasai's change also included the 
following modification of 6.1.2:

   | <del> When the specified value is not 'inherit',</del> the computed
   | value of a property is determined as specified by the Computed
   | Value line in the definition of the property.

In the case of a cascaded value of 'inherit', the specified value is the 
same as the parent's computed value, but is it really true that defining 
the computed value to be the same as the parent's computed value (6.2.1) 
is identical to using the Computed Value line to convert the specified 
value into a computed value (6.1.2)?  In other words, can there exist a 
property for which a valid computed value, when used as a specified 
value, gets converted to a /different/ computed value by the Computed 
Value line?  I doubt there is, but it's worth a thought!

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Wednesday, 18 May 2011 22:48:49 UTC