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

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

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

Yeah, although using prefixed selectors/values is "invalid" and easily
breakable with browser updates while exploiting differences on system
limitations isn't.

I think "validity" is probably theoretical so I am not in any sense
enthusiastic about it but I am just raising a point here.


Cheers,
Kenny

Received on Monday, 30 April 2012 06:42:18 UTC