Re: [css21] The 'inherit' keyword in shorthand properties

On 02/01/2012 21:20, Tab Atkins Jr. wrote:
> On Mon, Jan 2, 2012 at 7:17 AM, Anton Prowse<prowse@moonhenge.net>  wrote:
>> I take it back; I believe my claim and comments *do* stand, and that this
>> problem is just a special case of the fact that value assignment on
>> shorthand properties is not well-defined.  (Apologies for my wavering; I
>> blame it on the abrupt end of the holiday season!)
>>
>> It's often the lack of an obvious /computed/ value for shorthand properties
>> that alert us to the wider problem of value assignment on shorthand
>> properties, but in this case we see the lack of a /specified/ value for
>> shorthand properties.  The proposal wouldn't provide this value.
>>
>> Unfortunately, I can't see that it would be any easier to solve this special
>> case with an alternative proposal than it would be to solve the general
>> problem.  Nonetheless, I've tracked this issue separately at
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15387 with references to the
>> general problem.
>
> No, it's still a different case.

I'm not convinced.  Still, we agree that this issue is important enough 
that we be open to solving it independently of the general problem.

> In general, shorthand value assignment is defined "well enough".  They
> have a grammar, and we handwave that values are assigned appropriately
> from what you provide.  Aside from the odd ambiguity caused by mashing
> together multiple properties (which we solve on a case-by-case basis)
> this is unambiguous and fine.

(I disagree that it's defined well enough.  You say that shorthands have 
neither initial nor computed values but this isn't stated in any spec to 
my knowledge.

The one thing that we do know about shorthands from CSS21 is that 
"setting" them is the same as "setting" the corresponding longhand 
properties all at once.  Given that

border-style: none;
border-top-style: solid;

is different from

border-top-style: solid;
border-style: none;

one assumes that "setting" and "the same as" should be taken to mean 
that the shorthand properties are expanded to longhand properties prior 
to performing the cascade.  This isn't explicit anywhere though.)


> Passing 'inherit' or 'initial', though, doesn't work with the above.
> For one, it's fully ambiguous, as it can come from any of the
> properties.

I don't follow you.

> For two, we explicitly forbid passing 'inherit' or
> 'initial' multiple times, or as a part of a shorthand while other
> parts are filled in, even if it would be unambiguous to do so.

(Would you mind reminding me of the reasons for this, in the unambiguous 
case?)

> Those
> two keywords are explicitly a special case that cannot be handled by
> the general language that we normally rely on successfully for
> shorthands.

I agree that these keywords are special, but I think solving the problem 
"what is the specified value of 'x' when the winning declaration is 
x:inherit" is similar in difficulty and approach as solving the problem 
"how does value assignment to shorthand properties work".

So far we don't have any proposal that addresses the former problem. You 
suggested:[1]

   | If 'inherit' is given as a value to a shorthand property, it has
   | the same effect as specifying 'inherit' for all of the longhand
   | properties that the shorthand represents (even if the combined
   | computed values of the longhand properties end up being an invalid
   | value for the shorthand).

but I think that the effect you describe is just the standard way that 
declaring shorthands works (see above) and that it doesn't address the 
problem of what the actual specified value is in this case, which was 
the original issue.

> The specified value of a shorthand is well-defined in the general
> case; it's what was specified.  'inherit' and 'initial' are special
> because they disappear before the specified-value stage, which is why
> we need the special text for them - their normal effects don't work,
> as shorthands have neither initial nor computed values.
>
> ~TJ

[1] http://lists.w3.org/Archives/Public/www-style/2011Nov/0420.html

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

Received on Monday, 2 January 2012 22:33:38 UTC