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

(12/07/17 2:29), fantasai wrote:
> 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
>>> <kennyluck@csail.mit.edu>  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(http://www.example.com/)" vs. "image(http://www.example.com/)".
>>>> 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.

For the purpose of advancing the spec, no, I don't have a problem with
that. But otherwise, I'll comment on the relevant discussion in the F2F
minutes[1]:

> TabAtkins: let's look at 15.
> TabAtkins: problem is cycle relies on comparing computed value with
>            each value of cycle, which is new
> dbaron: this is a comparison of computed values. Transitions start
>         when a computed value changes. So transitions depend on
>         knowing that 2 computed values are different
> TabAtkins: that shouldn't be a problem. The issue isn't about that,
>            but about whether top left is the same as left top when
>            cycling background position. Answer is for computed values:
>            yes
> TabAtkins: so should we just say "like transitions", or define this
>            more carefully
> dbaron: the computed value line in our specs defines an information
>         set - set of concepts that the computed values can take
> TabAtkins: so is transitions under defined?
> dbaron: I think it is, but it's not that hard to define
> dbaron: here and there there's probably a computed value line in a
>         spec that isn't very clear, but the underlying definition
>         is those lines
> TabAtkins: so for now we can just explicitly say we're comparing
>            computed values and get implementors to tell us if they're
>            ever confused so we can fix that in the spec
> plinss: I think if there's 2 specs that talk about comparing computed
>         values, and one references the other, which doesn't define
>         that, this is bad
> dbaron: also, a definition should be in V&U, not transitions
> fantasai: what more do we need over "compare computed values"?
> dbaron: some kind of statement about what a computed value is

It seems that dbaron thinks the current spec is not detailed enough
about what "computed value" is?

> plinss: there's lots to define there, e.g. is 72 points == 1 inc?
> fantasai: yes, because they get converted to absolute values
> plinss: that should be explicit

It seems that plinss thinks the spec should make this more explicit?

> dbaron: it is. It's more things like pairs of values
> fantasai: we need to go and fix the computed values lines to not
>           imply an order, if there are any left that do
> TabAtkins: that's not a problem because they'll still compute to
>            the same thing for comparison
> dbaron: e.g. flex before it was a shorthand took 3 values in any
>         order. It's computed value is the combination of the 3 values,
>         not ??
> TabAtkins: so I want to say just simply compare computed values,
>            with a note that gets developers to come to us if they
>            think something's weird
> fantasai: yes, just a note that says these are abstract things,
>           not strings
> dbaron: have to be careful about computed values with optional parts.
>         Is the presence of the optional part substantive, or can it
>         be replaced by its default if the optional part isn't present?
> dbaron: that text could be in values spec

Was an action taken for this comment?

> RESOLVED: issue 15: add a note to define computed style comparisons
>           better

I don't quite care what the status keyword this issue gets, but I think
if we want to make DoC useful, there should be a link to this discussion
(i.e. [1]) instead of this Response mail I am replying to, which, in my
humble opinion, doesn't have much information.

I am not against deferring this to the future so to speak.

[1] http://lists.w3.org/Archives/Public/www-style/2012May/0542



Cheers,
Kenny

Received on Tuesday, 17 July 2012 16:47:21 UTC