Re: [css3-values + css3-cascade] Initial, Inherit, and cascade in multiple-value properties

I'm going to try and separate/define your proposals a little more
clearly, so it's easier to understand (line breaks are your friend!).

1. 'initial' and 'inherit' keywords
===================================
The 'initial' and 'inherit' keywords already exist; these are
proposals to extend the cases when they are applicable.

1.1 in shorthand properties
---------------------------
You propose to allow 'initial' and 'inherit' in shorthand properties.
They would have the traditional meaning for whatever specific
properties they appear in place of.  Example is the margin property.

1.2 in compound properties
--------------------------
You propose to allow 'initial' and 'inherit' in compound properties;
these are properties which accept one *type* of value, but possibly
multiple of them.  Example is the font-family property.

2. 'cascade' keyword
====================
The 'cascade' keyword is entirely new.  It indicates that a value is
to be obtained from the normal cascade (values set by earlier or
less-specific rules in the document).

2.1 in single-value properties
------------------------------
Using 'cascade' on a single-value property is a syntax error.

2.2 in shorthand properties
---------------------------
Currently, use of a shorthand property resets values that aren't
explicitly provided to their initial state, even if a less-specific
rule had provided values for them.  In your proposal, use of the
'cascade' proposal turns off this reset behavior, so that
less-specific rules can still apply for the unspecified values.
Example is the background property.

2.3 in compound properties
--------------------------
Use of the 'cascade' property causes a compound property to also take
values from less-specific rules.  Presumably they would be inserted
into the value list at the place where the 'cascade' keyword appears.

2.4 as a value for attr()
-------------------------
The attr() value, in addition to the computed value of the given
attribute, allows any normally valid value for the property to be
provided as fallback.  Use of the 'cascade' keyword as the fallback
property will cause the rule to be ignored completely in case of
fallback behavior.


This accurate?

I like 1.1 and would use it, especially in the given example.  I often
want to give an element auto horizontal margins to center it, but
leave the vertical margins as they are.  Currently I'm forced to
manually specify margin-left:auto;margin-right:auto, which is a bit
verbose.

However, 1.1 is unworkable in the case of properties which accept
values in any order.  I think you may be alluding to this when you say
"We may need to define what initial and inherit mean, since they're
not typed.".  What follows doesn't seem to be an answer to this
problem, though; I'm not sure where you're going with that.

I don't see anything immediately wrong with 1.2.  It would indeed be
rather useful on the font-family property, so you can avoid having to
manually retype every single font-family fallback any time you set it.

I like 2.2, for similar reasons to 1.1.  Is it meant to work even in,
say, margin?  Example: I have a less specific rule specifying
"margin:10px 20px 30px 40px", and then a more specific rule specifying
"margin: 10px cascade".  Should the targeted element's used margin
value be "10px 20px 30px 40px" or "10px 10px 10px 10px"?

2.3 seems complex.  Is it meant to inherit *all* values specified on
less-specific rules?  This seems to be of limited utility in many
cases.  If so, in what order do properties from multiples rules get
filled in?  It might be simpler and more useful for it to only cascade
from the single immediately less specific rule; that is, from the rule
that would apply if the 'cascade'-bearing rule was removed from the
stylesheet entirely.  If you need multiple-level cascade, you can
specify the keyword on each property in turn.

2.4 seems to be an eminently useful proposal.  The current draft of
the Values proposal states that "[the] attr() expression cannot
currently fall back onto another attribute. Future versions of CSS may
extend attr() in this direction.".  This would essentially accomplish
this.

~TJ

Received on Friday, 20 February 2009 21:54:25 UTC