RE: [css3-background] border-radius color transitions using gradients recommended but undefined

> From: fantasai [mailto:fantasai.lists@inkedblade.net]


> Given that on the 3 February 2010 teleconference you said
>      Sylvain: I'm ok with 2 or 3

Yes, that is what I said. And after further conversations with
my peers we agreed that this was not right. Given the number of 
repetitive messages on this topic between now and then - most of 
them over the past ~24 hours, between you and I - I didn't expect 
the need for clarification this far along. My bad.

> [...] 
> If we adopt wording on color stops, then there would be additional
> tests to require that the color at the stop is as expected, e.g.
>    "There should be no abrupt changes in color in the shape below."
> for
>    border-radius: 40px;
>    border-width: 20px;
>    width: 30px; height: 30px; /* show part of the straight sides */
>    border-style: solid solid none none; /* top and right border join */
>    border-color: teal orange transparent transparent;

I'm grateful for getting some answers on this front. If we can produce a reference 
image or an automated test, then this can be specified. I do not foresee a need for 
a level of detail exceeding what was done, for instance, to describe shadow blurs 
in HTML5 Canvas [1] but that would be a lot more likely to result in compatible, 
testable behavior than the minimal prose we have now, imo. 

> Because very few people care what the color interpolation function is,

I've come to believe few people actually care about this use-case, period.

To be perfectly honest and open, I'd rather spend time adding support for 
box-shadow (or rather -ms-box-shadow now). Demand for that feature exists and all 
our competitors support it. Maybe other browser vendors feel differently but given 
that all implementations currently draw a sharp line (including Opera 10.50b) I consider 
this recommendation to be effectively at risk, however aesthetically correct it may be.

Should I want to go experimental and risk some interop kinks, Tab's 
gradient image feature offers a very interesting risk/reward ratio. And 
if few people do care about the actual color interpolation used in gradients, 
it's even more interesting. (Although I suspect getting gradients right on a 
large surface matters more than on a border corner)
 
So at this stage I see more value in delivering the feature that was taken out 
of the spec than in supporting a behavior that's explicitly recommended in CR. Fwiw.

But being able to test this cross-browser is still a concern for out test suite work.
I'll let Arron follow up on that part.

> "opt-in" that requires additional features to be added to the standards
> to trigger gradient transitions is unacceptable because the default
> behavior should be what 80%+ of authors want to be the default, and
> sharp color transitions is not it.

1) That is what they have been getting for as long as border-radius has been
supported in Gecko and WebKit. Have users complained ? Besides unassigned work items, 
I have been unable thus far to find bugs in Gecko or WebKit's bugzillas that relate to 
authors' border-radius feedback on the lack of corner gradients, but I may have looked
in the wrong place ? Although one WebKit reporter did suggest being able to use gradients 
to define border colors [2]. (Which actually is an interesting request, I thought; it'd 
likely requires the corner gradient code to handle start/end lines that are themselves 
gradients...)
2) For the nth time, no "additional feature" has been required here, at least by
me. If you want to use your browser's corner gradient support you'd stick to 
-<vendor>-border-radius, which is all that exists today. In most cases and for most 
authors, this likely won't be an issue as 2+ border colors is not a common use-case.
3) We can't assert that the default behavior should work right for 80% of authors *and* also claim 
it is OK to leave said behavior unspecified for the purpose of experimentation. We can't have it 
both ways.

I thus remain unconvinced that my proposal is unacceptable or unreasonable.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-shadowblur
[2] https://bugs.webkit.org/show_bug.cgi?id=20127

Received on Wednesday, 24 February 2010 23:16:41 UTC