Re: [css-variables] cycle() and variables

On Mon, Jul 16, 2012 at 10:46 AM, fantasai
<fantasai.lists@inkedblade.net> wrote:
> On 05/06/2012 10:20 AM, Tab Atkins Jr. wrote:
>>
>> On Wed, May 2, 2012 at 9:51 AM, L. David Baron<dbaron@dbaron.org>  wrote:
>>>
>>> On Wednesday 2012-04-25 08:44 -0700, L. David Baron wrote:
>>>>
>>>>
>>>> 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);
>>>>    }
>>>
>>>
>>> Actually, I don't think this works, because the thing that's
>>> inherited with variables is syntactic rather than semantic so the
>>> cycle() behavior wouldn't get applied until it's used.
>>
>>
>> Yup, you're right.  Bad on me for not catching this.
>>
>> I see two possible solution, then:
>>
>> 1) Go back to the function containing an explicit identifier, and
>> selecting the index based on how many ancestors use that identifier,
>> or
>>
>> 2) Create some way to force variable evaluation.  You'd need to supply
>> a property context somehow.
>
>
> You could define that certain global functions within variables are
> evaluated at computed value time on the variable, e.g. cycle() might be
> more useful in general if it's operating at that level than when expanded.
> attr() is another interesting case in this respect: you might want an
> attr() function that evaluates where the variable is declared.

On the other hand, both of those can be reasonable to evaluate on use
as well, as currently specified.  attr() definitely has use-cases for
the currently-specified eval-on-use behavior.

I'd rather address this cleanly and generally at some point in the
future, rather than complicate things by making some functions
eval-on-assign and shutting out eval-on-use usecases for them.

~TJ

Received on Monday, 16 July 2012 17:52:01 UTC