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

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.

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

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.

~TJ

Received on Tuesday, 15 January 2013 01:34:21 UTC