Re: [css3-values] using 'cycle()' with other values

On Mon, Apr 9, 2012 at 11:05 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (I'll send a strawman proposal for a new definition of 'cycle()' soon,
> but this is a small issue for the current definition so I'll just raise
> it now.)
>
> The description of cycle() says
>
>  # The value returned by ‘cycle()’ must be determined by comparing
>  # the inherited value I (the computed value on the parent, or, for
>  # the root, the initial value) to the computed values Cn returned by
>  # the n-th argument to ‘cycle()’. For the earliest Cn such that
>  # Cn = I, the value returned by cycle is Cn+1. However, if this Cn is
>  # the last value, or if there are no Cn that equal I, the computed
>  # value of the first value is returned instead.
>
> First of all, I think this meant to say s/the initial value/the computed
> value of the initial value/. Secondly, ignoring shorthand properties at
> the moment, for even longhands the current description seems
> underspecified for cases when cycle() is used with other values. For
> example, I interpret the current description as follows:
>
> cascaded value -> computed value (take, say, 'content' as an example)
>
> "x" -> "x"
> cycle("x", "y") "z" -> "y" "z"
> cycle("x", "y") "z" -> "x" "z"
> cycle("x", "y") "z" -> "x" "z" (because "x" "z" != "x")
> ...

Yes, this example is correct.

> I don't think authors would expect this, so the above description should
> be changed to explain that Cn is the whole value, like
>
>  | The value returned by ‘cycle()’ must be determined by comparing
>  | the inherited value I (the computed value on the parent, or, for
>  | the root, the initial value) to the computed values Cn formed by
>  | using the n-th argument of each ‘cycle()’ in the same
>  | declaration. For the earliest Cn such that Cn = I, the value
>  | returned by each ‘cycle()’ in the same declaration is the n+1-th
>  | argument. However, if this n is the length of the arguments, or if
>  | there are no Cn that equal I, the first value is returned instead.
>
> with
>
>  | A declaration with two ‘cycle()’ of different number of arguments
>  | is invalid.
>
> . Otherwise, the spec should just say that cycle() cannot be used with
> other values (which doesn't seem bad too because there might be other
> interesting way to interpret a declaration with multiple cycle()) .

There's *potentially* good uses for cycle() combined with other things
(if you're very careful, it can be used as a limited form of 'switch'
against the inherited value), but that's pretty minor, so I wouldn't
be overly sad to see us restrict cycle() to only be used all by itself
in a declaration, like we do with 'initial' and 'inherit'.

> By the way, does
>
>  # The ‘cycle()’ notation is not allowed to be nested; nor may it
>  # contain ‘attr()’ or ‘calc()’ notations.
>
> mean that cycle() is valid as a default value of attr()? I am not quite
> sure what exactly "nested" means here.

Yes, cycle() may be used as a default value of attr().  "Nesting" here
means "nested inside of itself".

~TJ

Received on Monday, 9 April 2012 18:46:53 UTC