W3C home > Mailing lists > Public > www-style@w3.org > April 2012

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

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Mon, 30 Apr 2012 14:41:48 +0800
Message-ID: <4F9E342C.7060101@csail.mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "L. David Baron" <dbaron@dbaron.org>, WWW Style <www-style@w3.org>
(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

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.

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:58 UTC