Re: [css3-values] use cases and the design of 'cycle()'

On Wed, Apr 25, 2012 at 8:44 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Tuesday 2012-04-10 02:11 +0800, Kang-Hao (Kenny) Lu wrote:
>> While reviewing CSS3 V&U, I realized that 'cycle()' doesn't really solve
>> a use case I thought it would solve.
>>
>> Use Case A: In a User Interface built by nesting elements (say,
>> <table>), set background color on the elements alternatively along the
>> nesting level. See picture[1]
>
> Yes, it doesn't solve this case alone.  (I've also never seen any
> other examples of this case.)
>
> It does solve this case in combination with variables, though, and
> I think that's a better solution than making cycle() more complex.
>
> For example:
>
>  table {
>    var-cycling-background: cycle(white, gray);
>    background: var(cycling-background);
>  }

Ooh, that is *clever*.  I hadn't thought to use variables as a
"harmless inheritance path".

Well, that solves issue 13 in the DoC (and issue 14 is trivial to fix
anyway).  We're still left with issues 12 and 15, though:

Issue 12: cycle() is unable to represent values containing commas
without ambiguity.
Issue 15: The notion of equality for cycle() components is ill-defined.

Closely related is issue 21, where using multiple cycle()s in a rule
causes a combinatorial explosion of syntax-checking to ensure that all
possible combinations are valid.  However, I'm not seeing how cycle
would *ever* be useful except as a sole value.  If we just say that
cycle() is invalid if it appears with any other component values,
that'll solve this problem.  (And might make issue 15 easier, if we
say something like "functionally equivalent after parsing".)

~TJ

Received on Friday, 27 April 2012 00:31:54 UTC