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

(12/04/27 8:31), Tab Atkins Jr. wrote:
> Issue 12: cycle() is unable to represent values containing commas
> without ambiguity.

This is relatively easy. We can just just disallow commas that are not
in functional notations at this level and do something later if there
are enough use cases.

> 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.  

I am not opposed to resolving this way, but I also don't think
combinatorial explosion of syntax-checking is too harmful. (Although it
that is what we want, the spec should clarify it.)

> Issue 15: The notion of equality for cycle() components is
> ill-defined.
>
> (And might make issue 15 easier, if we say something like
> "functionally equivalent after parsing".)

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)"
...


If we don't want to work out the details for now, I think we can just
define the equivalence here to be the string equivalence of
getComputedStyle() and see how it goes. Although I want to point out one
concern with this naive definition:

If there are two values 'A' and 'B' for a property 'foo' such that A=B
in browser A and A!=B in browser B, authors can target Browser A and B
with something like

  .parent {
    foo: B;
  }

  .child {
    foo: cycle(A, value-A-targeting-browser-A,
               B, value-B-targeting-browser-B)
  }

Besides prefixed values, there even seem to be permanently exploitable
pairs that can be used here (say, by using the fact that Firefox is
1/60px quantized).


I don't have enough experience with the Web Platform to tell if this is
a big deal or not.



Cheers,
Kenny

Received on Sunday, 29 April 2012 20:58:01 UTC