W3C home > Mailing lists > Public > www-style@w3.org > January 2010

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 27 Jan 2010 03:15:35 +0000
To: fantasai <fantasai.lists@inkedblade.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E102FBBB1@TK5EX14MBXC113.redmond.corp.microsoft.com>
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Tuesday, January 26, 2010 6:49 PM
> To: Sylvain Galineau
> Cc: www-style@w3.org
> Subject: Re: [css3-background] border-radius color transitions using
> gradients recommended but undefined

> Look, Sylvain, I'm happy to sit down with you for 4 hours and work out
> the details of the prettiest gradient transition we can come up with.
> I'm happy to put it in the spec. I'm happy to show you how to test that
> the center of the gradient, by some given definition, is where the spec
> says it should be.

That would sure be orders of magnitude better than what's there now.

> I'm *not* comfortable with requiring a particular gradient shape and
> velocity function (or whatever it's called, I don't have the vocabulary
> to explain this properly)--because I understand that there are other
> implementations that are working with limitations that your team does
> not have, and because I'm not convinced that we've yet hit all the
> degenerate cases we need to consider when clamping down our definitions.

I didn't actually ask for that. I may still be the slow newbie but I know we're not 
going to get pixel perfect gradient compares, and that it's not the goal. To be perfectly 
clear, and given all the issues raised by this thread, I believe the spec should not 
require this. It should make note that a future version of the module may define 
gradient-based color transitions. Thus, the current spec remains testable, we avoid a 
scenario where unprefixed border-radius may never do gradients in UA X, do them in UA Y 
and do them differently again in UA Z, with a strong possibility that 2 out of the 3 UAs will 
thus have to change when the behavior is better specified. Teams and platforms who can't afford 
it are not disadvantaged. But vendors may still experiment as much as they want behind their 
vendor prefix, gathering the implementation experience and feedback we all need to 
come up with the right design. Just like they did with image gradients not long ago.

Recommending it without any further details is currently unhelpful and unnecessary imo,
especially with platforms and teams potentially unable to deliver expected renderings.
(As you note, we are currently not at such a disadvantage)

If the recommendation is to stick, it needs to come with a reasonable proposal that everyone 
can converge on in a testable manner. But testcases will still need to handle all implementations
as this remains optional.
Received on Wednesday, 27 January 2010 03:16:16 GMT

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