Re: [css3-images] Changing the angles in gradients

On May 18, 2011, at 2:13 AM, Alan Gresley wrote:

> On 18/05/2011 2:42 PM, Brad Kemper wrote:
>> 
>> On May 17, 2011, at 8:08 PM, Eric A. Meyer wrote:
>> 
>>> At 16:27 -0700 5/17/11, Brad Kemper wrote:
>>> 
>>>> On May 17, 2011, at 3:33 PM, "Eric A. Meyer"<eric@meyerweb.com>
>>>> wrote:
>>>> 
>>>>> That's why we have prefixes, as far as I'm concerned-- to let
>>>>> implementors fix bugs and keep pace with changing specs.
>>>> 
>>>> How does that help authors who are already using prefixes for 4
>>>> browsers, and users who update at different paces? It doesn't.
>>>> The authors would have to remove all the prefixed gradients, and
>>>> rely only on the raster images that they had in there as
>>>> fallbacks.
>>> 
>>> Of course it doesn't help them, but we can't save everyone.  As
>>> I've said in the past, the alternative is that we wait for an
>>> unprefixed incompatibility to get deadlocked by "we can't change
>>> this now, we have customers with web sites that we can't break",
>> 
>> I'm saying we would need a pretty darn good reason to change it even
>> now. And I don't think we have one.
> 
> 
> Yes he does. You have just snipped them out. I will re-include them into this thread.

No, I didn't snip out anything that I thought was a good reason for reversing the meaning of the most important part of the gradient (the direction).

> 1. Reliving the late 90's all over again. DOCTYPE switching got us out of that mess once. It is very, very unlikely that it could do so again.
> 
> 2. It was pretty awful (DOCTYPE switching), and we still deal with echoes of it today, ten years after a desperate maneuver rescued CSS.

I'm sorry, but that is an absurd argument. This is nothing like that. We are not talking about anything like two different box models and no way to handle the difference within CSS. We are talking about degrees that indicate linear, one-dimensional direction being conceptually different from rotational direction, and therefore written according to the appropriate conventions for that. There is no need for switching back and forth with a DOCTYPE-like mechanism, or any mechanism at all. 

If linear-gradient stays as it is, then there are not modes to switch between. Linear direction is indicated according to conventions for indicating linear directions (where 0deg is just as strongly directional as 90deg), and rotational amount is indicated according to conventions for indicating rotational amounts (where 0deg means do nothing). You don't need anything like DOCTYPEs or meta data to indicate any differently.

What would be more like that box-model crisis is if we had some browsers doing the degrees in one way, and other browsers doing them in a completely incompatible way. Which is what WOULD happen for as long as there were older browsers doing it one way and newer browsers doing it another way. And no meta tag or doctype would get us out of that.

> I am writing this now even thought I know that there is an error in the implementation of values in gradients for 'linear-gradient' in Firefox 4 and also errors in the implementation of 'repeating-linear-gradient' in Chrome 11 and IE10. The former error could be used as a way around the issue you mention below.

You mean some sort of hack to reverse the direction in earlier versions of Firefox. That would hardly be a satisfying solution. 

>> Sure, things change while the
>> thing is indexed, but the changes usually don't make the thing act in
>> the opposite manner to the way it did in a major recent release of
>> the second-most-used browser. For the site I work on, I would end up
>> needing to remove -moz-linear-gradient from wherever I have it, and
>> wait until most of my audience was no longer using Firefox 4 anymore
>> before I employed it again.
> 
> That the consequence for authors using experimental properties with prefixes.

It is the consequence of taking an action that discourages author participation in prefixed values, instead of encouraging it to gain authorial experience with experimental values, as originally intended for prefixes.

> A question..., how long has Firefox 4 been out (auto updating from Firefox 3.6)? The answer is two weeks. 

It is an issue that I cannot dismiss so casually. For the site I manage, only 20% are using the latest version of Firefox (4.01), and 13% are using the 4.0 version. 26% are using 3.6.16, 17% are using 3.6.17, and the rest (nearly a quarter) are using some older version. Old versions stick around for a looooong time, and account for large portions of the traffic. I can't just show upside-down or backwards transitions to thousands of people every month. It is unacceptable.

> 
> Here is the bug in Firefox 4.0.1.
> 
> http://css-class.com/test/bugs/gecko/2-0/angle-linear-gradient-bug.htm

That does not seem relevant to this discussion. It looks like FF is parsing percentages (as bg-position) in a place where it should only be looking for degrees or keywords. But anyone authoring according to the current spec, and putting degrees in there instead of percentages, would find consistent behavior across Firefox, Safari nightlies, Chrome, and (I think) IE 10 previews.

> I do suggest that when this bug is fixed, the angles of gradient can be changed at the same time. If this happens, then you know how to exploit this current bug by using two vendor prefixes for Gecko.

That would be horrid. I already have two versions of gradients for webkit, which is painful, but at least they have different names (-webkit-gradient and -webkit-linear-gradient), and therefore do not rely on hacks.

>> As to -webkit-linear-gradient, I don't think it is
>> in any releases of Safari other than nightly downloads (I could be
>> wrong), but apparently Chrome 10 does, so it wouldn't be safe to use
>> that prefixed version either (until most people had replaced Chrome
>> 10 with Chrome 11 or whatever). This path is pure folly, IMO.
> 
> 
> Depend on how fast Chrome 11 is shipped.

Or maybe it is v. 12 or 13 before it shows a change like that. In looking at my stats now, I'm getting about 66% of my Chrome users on 5 different releases of Chrome 11 (less than 19% are the latest version of that), about 27% on Chrome 10.0.648.205, and the rest on earlier versions. It has faster uptake than Firefox for new versions, but I'd still have to wait until numbers of people with current versions of Chrome are a negligible portion before using a prefixed version that changed that drastically.

I don't mind using prefixed versions of some properties and values if I have reasonable fallback. I'm not comfortable saying that my users must have the absolute latest version in order to not see my designs with reversed backgrounds. That does not fit the purpose of the site or many others.

Received on Wednesday, 18 May 2011 15:33:23 UTC