W3C home > Mailing lists > Public > www-style@w3.org > April 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 Apr 2012 11:45:59 -0700
Message-ID: <CAAWBYDCbsohZvEQNSfuyuhs=a_yHB=WcUrAyanbFRfsP7Ux2YA@mail.gmail.com>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
Cc: WWW Style <www-style@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT