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

Re: [css3-transitions] Back-tracking transition-timing-function

From: Simon Fraser <smfr@me.com>
Date: Mon, 07 Jun 2010 21:00:18 -0700
Cc: Erik Arvidsson <arv@chromium.org>, Alex Meiburg <timeroot.alex@gmail.com>, www-style@w3.org
Message-id: <DDEDFD54-D776-4404-AEE2-09D2E2543FE9@me.com>
To: "L. David Baron" <dbaron@dbaron.org>
On Jun 7, 2010, at 5:22 PM, L. David Baron wrote:

> On Thursday 2010-05-06 00:05 -0700, L. David Baron wrote:
>> On Wednesday 2010-05-05 23:46 -0700, Simon Fraser wrote:
>>> We modeled transition/animation timing functions after SVG keySplines:
>>> http://www.w3.org/TR/2001/REC-smil-animation-20010904/#KeySplinesAttribute
>>> which limit the values between 0 and 1.
>>> We'd be OK lifting this restriction for CSS (assuming people are
>>> happy with the divergence from SVG), but we'd have to make some
>>> rules about how properties like color get clamped when you go
>>> outside the 0->1 range.
>> There is a relationship between this discussion and the discussion
>> about reversing transitions.  I currently have an unlanded patch
>> that vastly simplifies (by avoiding dependence on distance
>> computation) Gecko's handling of reversing of transitions using
>> inversion of the transform timing function.
>> Then again, we need the distance computation for SMIL, so I could
>> perhaps leave it as-is, although I really don't want to figure out
>> how to write a distance computation function for transforms.
> Actually, I don't depend on inversion of the timing function for
> this new reversing code.
> Second, I've heard other requests for this feature, so I would
> strongly support relaxing the range restriction for the y1 and y2
> values.

Sounds good. We'll update the spec accordingly.

Received on Tuesday, 8 June 2010 09:02:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:47 UTC