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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 20 Jan 2012 11:32:11 -0800
Message-ID: <CAAWBYDCtZk462JtFLLvuajWAGW6AS4zcupCUa8hswMCTrEBr4Q@mail.gmail.com>
To: Anton Prowse <prowse@moonhenge.net>
Cc: www-style@w3.org, fantasai <fantasai.lists@inkedblade.net>, Øyvind Stenhaug <oyvinds@opera.com>
On Mon, Jan 2, 2012 at 2:33 PM, Anton Prowse <prowse@moonhenge.net> wrote:
>> 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.

Our treatment of them in specs is somewhat inconsistent, but the
propdef tables for shorthands are nearly always written with "Initial
Value" and "Computed Value" lines of either "see individual
properties" or "N/A".

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

Take, for example, "background: inherit url(foo) top left;".  Which
longhand property does the "inherit" apply to?  Which properties are
instead set to their initial values?

>> 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?)

Simplicity - in the above example, we *could* say that if you
specified *every field* in the background shorthand save one, that one
could be specified with 'inherit'.  But it's not really worth carving
out that special 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.

I see what you're saying.  Yes, the shorthand still doesn't have a
defined specified value given the above.  It cant' be the effect of
combining all the inherited values of its longhands, as that may
produce something that can't be represented in the shorthand.  I guess
it should stay as "inherit" or "initial" for shorthands, though the
effect of this is as above - it's treated as if the subproperties had
the given keyword, which is then substituted for the actual correct

Received on Friday, 20 January 2012 19:33:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:10 UTC