Re: [round-display] [motion-path] Orientation of elements due to merging polar positioning and motion path

On Thu, May 26, 2016 at 8:19 AM fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 05/25/2016 05:34 PM, Shane Stephens wrote:
> >
> > On Tue, May 24, 2016 at 3:56 AM fantasai wrote:
> >
> >> On 05/19/2016 05:51 PM, Shane Stephens wrote:
> >> >
> >> >> This seems very counter-intuitive to me. I would not expect
> >> >> the coordinate system of translate/rotate/scale/transform
> >> >> to be affected by motion at all. The goal is for these all
> >> >> to behave as if they were independent right? But with this
> >> >> ordering they're not.
> >> >
> >> > I'm not sure that is a goal. Would you expect motion rotation
> >> > to affect transforms? Or transforms to affect motion? You have
> >> > to pick one. I think translate/scale/etc. should act the same
> >> > as the transform property, and we can't split that up to insert
> >> > motion components.
> >>
> >> I would expect them to be independent. I don't expect 'rotate'
> >> to affect motion, nor motion to affect 'rotate'. I also don't
> >> expect 'transform' to be affected by any of these, it should
> >> apply on top as a final operation.
> >
> > I don't think that's possible unless you're happy for translate
> > to behave differently to transform: translate.
>
> I don't understand what you mean here... they should behave the same.
> And neither should be affected by either 'motion-rotation' or 'rotate'.
>

For a translation to be unaffected by a rotation, the translation has to
'go first' (i.e. come earlier in the final transform list). That means that
transform and translate would both have to come before motion and rotate.

So I guess something like:
transform
translate
rotate
scale
motion

That in turn would imply that e.g. transform: rotate(90deg) would change
the behavior of both translate and motion, and that scale & rotate would
also change the behavior of motion.

I don't think this order makes much sense, btw, but the point is that
there's no order that makes perfect sense. The current order:

motion
translate
rotate
scale
transform

means that you can naively use motion and the 3 component properties with
only the side effect that motion rotation will change the reference axes
for the component properties (which is possibly something that people will
want to happen anyway). Transform applies on top but it's already an
"expert" property.

We get *limited independence* of translate, rotate and scale because a
special property of keeping these properties separate and in this order is
that we're effectively running decomposition in reverse. We can't do this
trick with transform or motion, unless we were to try and do some kind of
multichannel decomposition and recombination, which scares me (the existing
decomposition we do for transform animation already produces weird,
unexpected results).

There's no genuine independence possible while we output the results of
these properties as matrices that get combined into a final transformation
matrix. This isn't me being pedantic, it's a consequence of matrix
multiplication.

Cheers,
    -Shane


> >> The problem is that Gmail's email output HTML doesn't correctly
> >> mark up quotations. (See bug above, which Gmail so far refuses
> >> to fix because, I dunno. I keep having to fix up your quotations
> >> when I reply because they are--from what I've been told by proxy--
> >> adamant about not fixing this stupidly trivial bug.)
> >
> > Ah, damn. I can look into routing CSS emails to a different mail
> > client, though that'll take some time.
>
> It's fine. I can deal. I don't want you to switch mail clients...
> I just want Gmail to either fix the bug or accept patches. :(
>
> ~fantasai
>