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

2009/2/20 Tab Atkins Jr. <jackalmage@gmail.com>:
> 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!).
I tried to put as many examples as possible.

> 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?
This is exactly what I meant, thank you for explaining better than I could.

> 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 meant that currently string-to-value assingment are based on types
(ie background: red; sets background-color because red is of type
<color>). A solution to this is to "streamline" the values of the
shorthand and using the position of initial / inherit / cascade
keyword to find the properties they apply to.

If "prop" currently accepts "<a>||<b>||<c>", to set prop-a, prop-b,
prop-c, the initial keyword (when not alone) would set prop-b is after
an other value, would set prop-c when in third position or after a
value of type <b>. If prop accepts a repeating syntax (such as
"(<a>||<b>||<c>)+"), in the fourth position or after value of type
<c>, would set <a>, and so on.
>
> 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"?

I think it should be margin-top:10px, margin-right: cascade as
specified, then margin-bottom:10px (the same as top) and
margin-left:cascade, which leads to a computed value of margin: 10px
20px 10px 40px;

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

If you looked at the last example (background-image with cascade
keyword) I used cascade both in :hover and .farmer. Because all
selectors have the same specificity (0-1-0), the cascade order is the
reverse order of writing (bottom --> top). So the specified value for
.farmer.seaside:hover is:
background-image: url(sunshine.png) cascade;
Because the second most specific rule sets background-image:
url(farmer.png) cascade; and the third sets background-image:
url(seaside.png); the real specified value (or the computed value, I
don't know which is best) is
background-image: url(sunshine.png) url(farmer.png) url(seaside.png);
This would be the same value also on .farmer.farmhouse.seaside:hover,
because the declaration on .seaside overrides that on .farmhouse and
does not use the cascade keyword.

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

Thinking more of this I imagine you would do
selector {
width: attr(my-one,px,auto);
width: attr(my-two,px,cascade);
}
But in order to use the cascade keyword, we need to remember all width
property declaration in the same selector. I instead expect that
implementation do optimize this by simply overriding the first
declaration at the parser level and memorizing a fixed number of
declarations per rule.
We should allow this optimization and say that multiple declarations
for the same property in the same selectors are overriden despite of
the cascade keyword.
If sameone wants this, he should use
selector {
width: attr(my-one,px,auto);
}
selector {
width: attr(my-two,px,cascade);
}

> ~TJ

Giovanni

Received on Saturday, 21 February 2009 13:01:28 UTC