- From: Simon Fraser <smfr@me.com>
- Date: Tue, 24 Jul 2012 08:55:18 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Chris Marrin <cmarrin@apple.com>, Dirk Schulze <dschulze@adobe.com>, "www-style@w3.org" <www-style@w3.org>
On Jul 23, 2012, at 3:21 pm, L. David Baron <dbaron@dbaron.org> wrote: > On Monday 2012-07-23 09:22 -0700, Chris Marrin wrote: >> >> On Jul 19, 2012, at 5:51 PM, L. David Baron <dbaron@dbaron.org> wrote: >> >>> On Thursday 2012-07-19 16:54 -0700, Dirk Schulze wrote: >>>> Do I understand your point correctly, that you just want the >>>> affected transformation functions to get interpolated as matrices? >>> >>> Yes, rather than forcing the entire list to be interpolated as a >>> single matrix. >> >> You're complicating the rules by doing this. If I have: >> >> rotate(...) scale(...) translate(...) >> scale(...) rotate(...) translate(...) >> >> Do you do two separate matrix animations? Taking that to its >> logical conclusion, you could end up doing a dozen expensive >> matrix animations for a long list of unmatched primitives. > > I'm fine with doing that as a single matrix animation. > > The "affected transformation functions" in the most deeply quoted > text was referring to perspective(), rotate3d(), matrix(), and > matrix3d(). What I don't like is the idea that interpolating > between: > transform: perspective(5px) skewY(0deg) > and: > transform: perspective(5px) skewY(30deg) > should do a matrix interpolation for the entire list because the > perspective function is defined by the current spec as not having a > corresponding primitive. (This was not a problem in earlier > drafts.) I'd like to stick to the principle established in the > earlier draft that if the lists match, they're interpolated > item-by-item. It seems confusing for authors to do that most of the > time but not all of the time. > > To be clear, though, to restate my response to the most deeply > quoted text above: I don't particularly care whether they're > interpolated as matrices or interpolated some other way (esp. for > perspective() and maybe for rotate3d()). I think the text in the draft has drifted away from the original intent, and we're really all in agreement. Dirk, why can't we treat perspective() and rotated3d() as primitives? Simon
Received on Tuesday, 24 July 2012 15:55:51 UTC