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

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 24 Feb 2010 02:07:09 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, fantasai <fantasai.lists@inkedblade.net>
CC: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E10D3A508@TK5EX14MBXC120.redmond.corp.microsoft.com>

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Tuesday, February 23, 2010 4:09 PM
> To: fantasai
> Cc: Sylvain Galineau; Daniel Glazman; www-style@w3.org
> Subject: Re: [css3-background] border-radius color transitions using
> gradients recommended but undefined
> 
> On Tue, Feb 23, 2010 at 6:01 PM, fantasai
> <fantasai.lists@inkedblade.net> wrote:
> > If the opt-in means requiring a sharp color join in CSS3 and enabling
> > gradients
> > via another property in CSS4, then that's not acceptable to me.
> 
> Nor to me.
> 
> I agree completely with Elika here - minor differences in the
> appearance of the gradient until impls stabilize is *not* a big deal
> as long as no impl does it in an objectively *ugly* way.  

First, I *never* said anything about a separate property in CSS4. From the beginning, I indicated 
I'd be OK to do this behind -ms-border-radius for example. If you want the gradient, you use the 
prefixed version. Until a need for a separate property is demonstrated, there is nothing here 
that implies or requires a different syntax. I don't understand why that's an unreasonable burden 
for an experimental, undefined feature. In most cases, border-radius will work the same across all 
browsers. When authors want the experimental gradient side-effect, they opt in. Only those who need 
corner gradients are affected; and unprefixed CSS4 border-radius can still support this eventually.

(Although whether this requires a separate property someday should be based on author needs and use-cases, 
imo. If we can't even agree on how to spec this today, I doubt we can exclude this possibility outright).

As for 'minor differences' and 'not objectively ugly', they hardly constitute actionable, normative 
guidance :)

'Not ugly' is not helpful: there are teen sites in Asia that make me go blind 
but it clearly works for them. 'Minor differences' is not any more helpful. 
Minor for whom ? For the author who designs a background image to interact in some way
with his corner gradient in Firefox only to find out he needs to retouch it for IE, then tweak 
it again in Opera, then again for phone versions of those browsers ? Is that going to 
be minor to him ? Is it a proper answer to tell him "well, it's not objectively ugly so 
tough luck" ? Is he an outlier ? I don't really know. It's nice to know that's not an issue
for you but it's a big web.

And how minor can the differences be for the purposes of the test suite ? What is the level of
conformance that is sufficient here ? A simple eye-balling e.g. "there should be a gradient
looking roughly like this" ? More ? How ?

Elika claims it would take her ridiculous amounts of time to specify it with sufficient
details to ensure close interop. Fair enough. I don't quite understand how that makes not 
specifying anything at all a better alternative. But at the very least, stating that something 
is so hard to specify that the best we can do is specify as little as need be to ensure 
'minor differences' strongly suggests we're dealing with an experimental feature. I like the latter
but am not comfortable using stable CR-level properties for that purpose and remain surprised that 
I, as a Microsoft rep, have to raise that concern. It's nice to know we want this to result in minor 
differences but that remains unhelpfully vague. Minor is not testable.

Most importantly, I'm not shipping specs. I understand we - the WG - really want to ship 
this one; we did drop box-shadow even though it's widely supported (without a prefix in Opera 10.50b, 
in fact) and fairly popular (requests for corner gradients on my end: 0; for box-shadow: thousands).
And that's fine. That's the trade-off we chose to make. But given that we want to finish this badly
enough to drop a popular feature with plenty of implementation experience, I'm afraid I find my request
entirely reasonable under the circumstances. 

We are three months into CR. No one supports this feature; it is largely undefined except for a suggested algorithm. 
The spec editor has indicated the feature is experimental. It is thus appropriate to specify it as a MAY and leave 
the exact definition of the behavior to the next level, or any prose indicating that this is a vendor behavior 
until such time as we're able to describe the desired level of interop better than 'the rendering shall not be 
objectively ugly' and 'user agents shall render gradients with minor differences'. 



 

 





> 
> ~TJ

Received on Wednesday, 24 February 2010 02:08:07 GMT

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