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

On Tue, May 24, 2016 at 3:56 AM fantasai <[email protected]>
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.


> > Actually, based on your reactions here I'm leaning towards us
> > adding a full motion transform function. There isn't a perfect
> > ordering of transform and motion components where everything
> > always works as expected but at least that way more advanced
> > users can select an order.
>
> While maybe adding a motion transform function is *also* a good
> idea, I don't think it's a good substitute for independent
> properties. Which is why we're introducing translate/rotate/etc.
>
> I'm pretty sure the expectation is that these operations are all
> independent, unless stacked within the 'transform' property itself.



> >> What if you did
> >>
> >> apply translate
> >> apply motion
> >> apply rotate
> >> apply scale
> >> apply transform
> >>
> >> ?
> >
> > This would keep translate components in the global coordinate
> > system but then
> >   translate: 100px;
> > and
> >   transform: translate(100px);
> > would sometimes act differently to each other, which is weird.
>
> Agreed that's weird. They should be the same.
>
> >> p.s. Please either use plaintext email on www-style, or
> >> successfully harass the Gmail team to fix b/19483003 ?
> >
> > Ah, sorry :( I think that whatever messed up happened because I
> > manually quoted an email to merge two replies. I won't do that
> > again. Unfortunately inbox has no plain text option yet.
>
> No, that is not the problem. You are not doing anything wrong. :)
>
> 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. Hopefully the switch to github will make
this problem go away.

Cheers,
    -Shane


>
> ~fantasai
>