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

Let's look at that from another perspective. In other terms, please
all cool down.

A Member's representative has an important remark about
interoperability of a very visual feature important to web designers.
That Member acknowledges that importance ("and we believe it is").

The editor prefers to let the gradient definition up to the browser
implementor ("I *am* interested in soliciting ideas for good corner
joins, but I think this should go into an informative appendix, not the
normative prose.").

I tend to disagree. The current thread shows that it is not a
prohibitive investment to discuss a preferred algo, based on available
underlying technologies (Zach's mail), best result (one of Brad's mail),
ping the XSL-FO and SVG people to know how they solved this issue if
they solved it, see what other non-web technos are doing, or even look
at the common practice in the Press. I am
in particular concerned by rendering differences among browsers for
large border widths, the gradient differences between implementations
becoming more visible. Experience across the years has shown that when
browsers ship a new feature, web authors use it in ways we did not
expect. At a time we discuss harmonization with a pixel-precise
technology like SVG, having a defined behaviour here seems to me a
good way of doing things.
Speaking of the existing hiatus about dotted borders, I heard myself
some web authors loudly complaining about it. I think we should avoid
another bad story of that kind. "Undefined behaviour" should be really
exceptional.

Leaving this undefined and moving to a feedback loop after PR _is_
a standardization process going on at implementation level. So
standardization is possible, and it's possible at spec level.

Let's continue the discussion at the technical level, to see if we can
find a preferred and desired behaviour that is interoperably
implementable. Speeding up things to avoid another stage back at
WD level does not seem to me a reasonable argument here.
If the investigation shows that no interoperable algo can be found
at this time, then the "undefined _for the time being_ because of
platform constraints" solution will probably be the best. But since
this investigation did not really happen, we're unable to resolve now.
The CR period ends in June and that should be enough to untie the knot.

Thanks.

</Daniel>
--
W3C CSS WG, Co-chair

Received on Wednesday, 27 January 2010 07:59:32 UTC