- 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>
> 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 UTC