W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: [css3-cascade] Unexpected computed value when cascaded value is 'inherit'

From: Anton Prowse <prowse@moonhenge.net>
Date: Wed, 23 Jan 2013 09:16:15 +0000
Message-ID: <50FFAA5F.7000200@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>
On 15/01/2013 01:33, Tab Atkins Jr. wrote:
> On Mon, Jan 14, 2013 at 12:39 PM, Anton Prowse <prowse@moonhenge.net> wrote:
>> The css3-cascade WD of 2013-01-03 says, in 4.3.2:
>>
>>    # The inherited value of a property on an [non-root] element is the
>>    # computed value of the property on the element's parent element.
>>
>>    # If the cascaded value of a property is the ‘inherit’ keyword, the
>>    # inherited value becomes the property's /specified/ and computed
>>    # values.
>>
>> Firstly, given that Section 4.3 is describing how to determine the specified
>> value, I don't know why "specified" is emphasized; it confused me somewhat!
>> I think the word "and" should be emphasized instead, since the unexpected
>> piece of information in that sentence is that the computed value is also
>> influenced.
>
> Sorry, human fail.  That was supposed to be auto-linked (we use <i>
> for that purpose in the spec source).  I've added a title='' to make
> it link up properly.

Ah, thanks!  Makes sense.


>> Secondly, I don't know why the computed value is influenced.  On the one
>> hand, it's clearly wrong:
>>
>> parent {display: inline}
>> child {display: inherit; float:left}
>>
>> The computed value of 'display' for the child element is 'block', not the
>> inherited value ('inline').
>>
>> On the other hand, it seems such intentional wording that it makes me wonder
>> what other situation can arise that requires us to explicitly spec the
>> computed value rather than just let it be determined from the specified
>> value (which is already an valid computed value).  In other words, the
>> editors obviously believe there is a situation in which the normal process
>> of converting a specified value x to a computed value y yields x != y
>> despite x being a valid computed value.  I can't think of such a situation
>> off the top of my head.
>
> It's definitely intentional - because the inherited value has already
> passed through computation, you don't want it to go through the
> specified->computed process again, in case it would change.
> Particularly, if the same value would mean something different in
> specified and computed values, that would go wrong.  A specific
> example is flex-basis, where a specified 'auto' can resolve to a
> computed 'auto', which mean *completely different things*.

Great, *that's* the example I was hunting for!  I knew I'd seen one 
before.  (I was on a different tangent trying to construct one involving 
percentages.)

> I'm not sure that the current definition is wrong, though - we have
> several places across specs where a computed value is transformed into
> another computed value, and the ordering of these transformations is
> ill-defined (usually relying on the "specific trumps general"
> meta-rule).  'float' changing display:inline to display:block would
> just fall into the same bucket.

Yeah, I don't doubt it.  I think it would be good to add some kind of 
disclaimer though, such as "unless specified otherwise elsewhere".

Cheers,
Anton
Received on Wednesday, 23 January 2013 09:16:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT