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