RE: [css3-images] Order of color-stop fixup

Yes, I object.

For the original two reasons:

(1)    It exchanges what I consider as a good rendering for a bad one.

(2)    Setting (1) aside for a moment, at best your proposed rendering is "as good" as the existing one, which isn't enough reason to go against the inertia/momentum of the spec as it stands (and the degree of interoperability of implementations we have thus far).

(3)    It's a local "fix" for a small portion of the larger problem, and as such (a) doesn't address the whole problem and (b) potentially becomes a "tail wagging the dog" precedent for all kinds of other potential changes across CSS to support (IMO) "interpolating at the wrong time".

Also note, in case you missed it, Tab replied [@ Fri 10:57 AM PST] with another example that presents a problem for the system you describe.  Unless I misunderstood his example.

-Brian

From: Shane Stephens [mailto:shans@google.com]
Sent: Monday, August 15, 2011 6:26 PM
To: Brian Manthos
Cc: Tab Atkins Jr.; www-style list
Subject: Re: [css3-images] Order of color-stop fixup

On Fri, Aug 12, 2011 at 1:01 PM, Brian Manthos <brianman@microsoft.com<mailto:brianman@microsoft.com>> wrote:
"resolving sizes down to pixel values before interpolation"
We're missing each other apparently.

Resolve *nothing* before you have all the necessary data to do so.

Ah, I apologize. I thought you were suggesting that the right gradient representation for interpolation was percentages for stops and pixel values for position and gradient size.

Coming back to the original topic, the WebKit animation pipeline currently interpolates at apply time. As we've discussed it's still possible to make gradient interpolation work correctly with this scheme, although as you've pointed out it is more complicated than just interpolating further down the stack. Unfortunately, making big changes to the pipeline is not something I'm likely to be able to do, and it is anyway something I'm wary about - I don't know the context around why the pipeline is the way it is.

As an implementation detail, it's easier to interpolate stops at the point where WebKit does it if rules (2) and (3) of color-stop fixup are swapped. It seems that:

* swapping these steps merely exchanges one constraint bias for another - i.e. one approach is not more correct than the other
* if you are already interpolating lower down the stack, either approach is of similar complexity
* only poorly specified gradients (i.e. with mixed pixel and percentage values or clear order inversions) are impacted

With this in mind, do you have objections to swapping the two steps?

Cheers,
    -Shane