W3C home > Mailing lists > Public > www-style@w3.org > May 2011

[css3-images] exactly 2 adjacent colors stops

From: Brian Manthos <brianman@microsoft.com>
Date: Mon, 16 May 2011 17:21:48 +0000
To: www-style list <www-style@w3.org>
Message-ID: <FA122FEC823D524CB516E4E0374D9DCF1FAC50FE@TK5EX14MBXC136.redmond.corp.microsoft.com>
http://dev.w3.org/csswg/css3-images/#repeating-gradients
# If the difference in the positions of the first and last color-stops is 0
# (for example, in the value 'linear-gradient(red 10px, blue 10px)'),
# the gradient defines a solid-color image with the color of the last
# color-stop in the rule (in this case, then, it would simply define a
# blue image).

http://dev.w3.org/csswg/css3-images/#color-stop-syntax
# If multiple color-stops have the same position, they produce an
# infinitesimal transition from the one specified first in the rule to
# the one specified last.


I believe both of these quotes are intended to be normative, but they are in conflict.

The first quote indicates you should see solid blue.  The second quote says you should see both red and blue (as well as an infinitesimal transition from red to blue).


I believe the second quote is the preferred to be applied in this case, and that we should consider just removing the first quote.  If we decide to keep the first quote, I think it really belongs in section 5.4 (gradient color-stops) rather than buried in 5.3 (repeating gradients).


The rule specified in the first quote fails on the following browsers:
*       Chrome: 12.0.742.53 beta-m
*       FF: 4.0b7
*       IE: PPB1
*       Opera : 11.10
In other words, the binaries interoperably disagree with it.


The first quote requires a new condition to be tested and snapped to a solid color in the implementation for this specific case.  Note that such logic would also have to handle cases like "linear-gradient(red 5px, blue 7%)"* that will sometimes be solid blue and sometimes be a red/blend/blue rendering - depending on how 7% compares with 5px for the specific rendering location.  For these extended cases, it's very likely that we'll have interoperability issues due to rounding differences in comparing 5px vs. f(7%, gradient-line-length).

Adding in the "2." rule in section 5.4 makes it even more likely that you'll bounce between these states as you change the gradient line length: blue -> red/blue -> blue.  With transitions and animations, this could be an entertaining effect but I suspect not desired from a spec perspective.

* It gets even worse when you make use of calc, but I've excluded such cases for now for brevity.

If we keep the first quote, we should have examples of all of these unusual conditions captured directly in specification examples for clarity and to re-enforce exactly what is intended.

-Brian
Received on Monday, 16 May 2011 17:22:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:40 GMT