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

I offer the below proposal for handling value assignment to shorthand 
properties.  It's nothing revolutionary, but I hope it's correct. (If 
not, it will reveal some gap in my understanding in the cascade, 
inheritance and value assignment model.)  The aim is to fix spec bugs 
[1] and [2].

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

The shorthand properties defined in CSS21 are:

background
border-color
border-style
border-top
border-right
border-bottom
border-left
border-width
border
cue
font
list-style
margin
outline
padding
pause

The only passive shorthand is 'border'.  The remaining shorthands are 
active; that is, they represent the full space of the longhand 
properties that they set.

Currently, the value assignment process for shorthands is under-defined. 
  Insofar as the longhand properties are concerned, a shorthand property 
seems to be expanded into its corresponding longhand properties at the 
same point in the stylesheet at which it appears, prior to the cascade 
and inheritance process.  Does the shorthand itself participate in that 
process?  It would not seem to make any sense for it to do so, because 
the specified value resulting from the winning declaration wouldn't have 
any relevance since it may well not correspond to the set of specified 
values of the longhands.

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.

When a shorthand is designed, it must be decided whether it is to be an 
active shorthand or a passive shorthand.  I feel that active shorthands 
are more elegant and less frustrating to authors, so active shorthands 
should be the preference.  In the case of pre-existing properties that 
become shorthands, such as is likely to happen with 'overflow', the 
shorthand /must/ be active since web content no doubt relies on the 
existence of either specified, computed, used or active values.  (What 
is it that getComputedStyle returns, exactly?  Are there similar 
interfaces for the other values?).  Hence such "evolved" shorthands must 
be designed to represent the full space of the longhand properties that 
they set.  (See 'list-style' and 'cue' for examples of how to handle 
cases where the value spaces of the longhands overlap.)

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.  (This is true 
in CSS21; is this true elsewhere to date?  If so, I would argue that it 
be a required design pattern for all shorthands.)  A shorthand set to 
'initial' should be expanded into longhands set to 'initial'.  This 
value, once transferred to the longhands, disappears during the cascade 
and inheritance process for those properties, and if the shorthand is 
active then its specified value is derived directly from the specified 
values of the longhands.  The same procedure ought to happen with 
'inherit'.  (Note that the rule "if a winning declaration for an 
element/property pair is 'inherit' then the specified value is the 
computed value of the parent/property pair" does not apply since 
shorthand properties don't have winning declarations.)

This would seem to solve the bugs "Value assignment on shorthand 
properties is not well-defined"[1] and "Not clear what 'inherit' on 
shorthand properties means".[2]

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15384
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15387

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

Received on Tuesday, 10 January 2012 21:35:58 UTC