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

On Tue, 10 Jan 2012 22:32:58 +0100, Anton Prowse <prowse@moonhenge.net>  
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".

I don't find this "active"/"passive" terminology very obvious. Other  
suggestions: "total"/"partial", "complete"/"incomplete"...

The text-decoration "shorthand" in css3-text  
(<http://dev.w3.org/csswg/css3-text/#text-decoration>) also seems to break  
our models quite badly since the 'blink' keyword actually does *not*  
correspond to any longhand. But perhaps that should just be fixed in  
css3-text (by introducing another longhand, possibly some sort of  
"virtual"/"internal" variety...).

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

I'm not sure why the line needs to be drawn there. Couldn't the "passive"  
shorthands be assigned computed values when possible? As in the current  
CSSOM draft: "If the value of a shorthand property is requested and it  
cannot be computed because the properties associated with the shorthand  
have values that cannot be represented by the shorthand the serialization  
is the empty string."

If getComputedStyle is the only thing that needs it, the  
assignment/reconstruction of values to shorthands could perhaps be rolled  
into CSSOM's definition of "resolved value"  
(<http://dev.w3.org/csswg/cssom/#resolved-value>).

See also 'white-space', a CSS 2.1 longhand which as been made into a  
"passive" shorthand in <http://dev.w3.org/csswg/css3-text/#white-space0>.  
I'm not convinced that extending it to allow all possible combinations of  
text-space-collapse and text-wrap would be more elegant, but for backwards  
compatibility it probably needs getComputedStyle(foo).whiteSpace to return  
the right keyword if the longhands have not been used.

-- 
Øyvind Stenhaug
Core Norway, Opera Software ASA

Received on Thursday, 12 January 2012 11:21:01 UTC