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

Re: [css21][css3-cascade] Proposal for value assignment to shorthand properties

From: Anton Prowse <prowse@moonhenge.net>
Date: Wed, 11 Jan 2012 08:57:00 +0100
Message-ID: <4F0D40CC.7080109@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>
On 10/01/2012 23:03, Bjoern Hoehrmann wrote:
> * Anton Prowse wrote:
>> There are two types of shorthand property in CSS: those which are
>> capable of unambiguously representing all possible combinations of all
>> possible specified values of the corresponding longhand values, and
>> those which are not.  Let's call the former set the "active shorthand
>> properties" and the latter set the "passive shorthand properties".
> This seems a mischaracterization to me, for one thing, how shorthands
> relate to longhand properties is subject to change. `font` for instance
> resets `font-stretch` even though the latter property is not part of
> CSS 2.1 but `font` is.

Interesting.  So 'font' went from being an active shorthand to a passive 
one.  In my proposal, I think that would be forbidden.  (This particular 
example isn't a practical problem, though, since several UAs don't treat 
any shorthands as active at the moment so we can just treat 'font' as if 
it were always a passive shorthand.

Are you aware of any other examples like this?

>> Do shorthand properties get assigned specified, computed, used and
>> actual values?  Since passive shorthands can't possibly match all
>> combinations of the longhands, I would argue that they should be defined
>> as not having any of these values.  On the other hand, the active
>> shorthands should be assigned these values by merely combining the
>> corresponding values from the longhands.
> As I recall it, shorthand properties are a macro mechanism and are ex-
> panded in place, DOM Level 2 Style for instance treats them as if they
> do not exist at the object model level anymore.

OK, so that really is how I imagined passive shorthands working.

> Odd cases like system
> fonts in the `font` property have been discussed a number of times, I
> am not sure if there was any conclusion however.

I'm not aware of these discussions.  I'll try to hunt them down; any 
pointers would be welcome.

> Similarily, there is
> a problem when ordinary properties are redefined as shorthands.

I tried to propose something to handle that, below.  Such properties 
would be required to be active shorthands, representing the full space 
of the longhand properties that they set.

>> How do the special values 'inherit' and 'initial' fit into this?  Well,
>> we assume that the initial value of a shorthand is always in direct
>> correspondence with the initial values of its longhands.
> A shorthand set to either of the values results in setting all the sub-
> properties to the same value plus whatever else is required, like re-
> setting certain other properties. This should be clear from the syntax
> of the shorthand properties, where `inherit` is only allowed as alter-
> native for everything else (and the references to longhands do not in-
> clude `inherit` as explained in the definition of the notation), but in
> CSS 2.1 C.3.1 this is more explicit.

Indeed; I don't think I contradicted that, although I did query in a 
recent thread[1] with Tab what the exact reasons were for this 
all-or-nothing approach but it hasn't yet received a response.  (I 
suspect the answer will turn out to be rather influential to any 
proposal for fixing shorthands.)  Also, the "whatever else is required" 
is interesting.  By "resetting certain other properties" I guess you're 
referring to 'font-stretch' in your 'font' example above.  Did you have 
any other cases in mind?

> As I recall it, `initial` is meant
> as alternative wherever `inherit` is allowed and should work the same
> way.

Yes, that's how I understand it too.

[1] http://lists.w3.org/Archives/Public/www-style/2012Jan/0024.html

Anton Prowse
Received on Wednesday, 11 January 2012 07:59:58 UTC

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