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

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

This would be fine with me for now, I suppose.  Eventually, I suspect
we'll go with SASS's solution, which is to wrap arguments in
parentheses when they contain commas.


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

We slightly altered the validity of attr() to avoid this problem, so
we might as well do the same with cycle().  I don't think it's
harmful.  In the rare cases that you might want to combine cycle()s
together, you can do so by passing them through with Variables, and
then just referencing the variables in the target property.  This
still avoids the silly case.


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

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.

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.


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

This isn't a big deal.  UA sniffing is already trivial to do (hard to
do *right*, but trivial to do half-right, at least), and even within
CSS, selectors make it very easy to target rules at specific UAs.
Given any selector "A", the selector "A, :not(*):-foo-B" will be
functionally equivalent in browsers that understand the -foo- prefix,
and invalid everywhere else.

~TJ

Received on Monday, 30 April 2012 05:49:35 UTC