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

On Mon, Aug 15, 2011 at 6:45 PM, Brian Manthos <brianman@microsoft.com>wrote:

>  Yes, I object.****
>
> ** **
>
> For the original two reasons:****
>
> **(1)    **It exchanges what I consider as a good rendering for a bad one.
>

Fair enough. As I suggested earlier I tend to feel the opposite way. It's a
matter of opinion.

> ****
>
> **(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).
>
This is why it's important to note how marginal the set of impacted
transitions is.

The set of possible animations is different with each approach too. For
example, with my proposed rendering you can queue up a set of stops behind
an occluding stop and have them slide out while maintaining spacing -
something like:

linear-gradient(left, red 50%, black 0%, white, black, white, black, white
40%)
to
linear-gradient(left, red 50%, black 50%, white, black, white, black, white
90%)

In my implementation this generates a pleasant slide-out effect, which is
not possible afaict with the current implementation.

So I don't think it's fair to say my suggestion is at best "as good" without
thinking through the ramifications.

> (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”.
>
I think you misunderstand the intent behind asking for these to be switched.

> ****
>
(1) it isn't a fix for an insurmountable problem. Supporting both approaches
is possible in WebKit today, it's just *cleaner* to do it the way I'm
proposing.
(2) it doesn't set any precedents, except that when it's possible to
interpolate at either level we should prefer to be able to do it purely at
apply time (Why is this bad, btw? Every other currently animatable property
is interpolatable at apply time)

In particular I am not trying to claim that we should all interpolate at
apply time, in fact I thought that was clear from this discussion. I
completely understand that some properties (e.g. contain and cover) can't be
handled except by resolving them against the current container size, and I
have an approach that will allow me to do so within the current WebKit
framework. It just so happens that I can see an opportunity to make stops
resolution cleaner within the same framework, and can't see any genuine
technical disadvantages.


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

You didn't misunderstand his example, but you may have misunderstood my
approach. These examples do not present a problem for the system I
describe.
Cheers,
    -Shane

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