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

On 04/30/2012 02:41 AM, Kang-Hao (Kenny) Lu wrote:
> (12/04/30 13:48), Tab Atkins Jr. wrote:
>> On Sun, Apr 29, 2012 at 1:57 PM, Kang-Hao (Kenny) Lu
>> <>  wrote:
>>> (12/04/27 8:31), Tab Atkins Jr. wrote:
>>> Well, "functionally equivalent after parsing" is of course better than a
>>> vague equal sign but it's still pretty underspecified. It might also not
>>> be what we want, for two reasons:
>>> 1) cycle() compares the inherited value to the arguments so that's a
>>> comparison of computed values. That's is it should at least be
>>> "functionally equivalent after parsed and computed".
>>> 2) there are cases that are "functional equivalent" but potentially hard
>>> to tell programatically, such as:
>>> a. "url(" vs. "image(".
>>> b. "image(black)" vs. "linear-gradient(0deg, black, black)"
>> Neither of those are equivalent in the way I was thinking.  I was just
>> thinking "same tokens, and same order unless the difference in order
>> is unimportant".
>> Actually, since computed values shouldn't *have* order unless it's
>> important (for example, the 'flex' function is just "two numbers, and
>> a length or keyword"), comparison of the abstract notion of computed
>> values should be fine.  That allows "5px 10px" and "top 10px left 5px"
>> to be "the same" potentially.
> Please no "abstract notion"!
>> However, I wouldn't be too put out if we just went for the "same
>> tokens, and same order if important" definition.  It's simple.
> Which means that a hash color is different from rgb()? I doubt this is
> implementable.
> In any case, I believe this question has to be deferred to CSSOM.

The cycle() (now toggle()) function is already defined to operate on the
the computed value, which is well-defined and already abstract enough for
our purposes. The CSSWG therefore closed this issue as invalid. Let me
know if there's a problem with this.


Received on Monday, 16 July 2012 18:30:02 UTC