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

On Wed, May 18, 2016 at 3:09 PM Brad Kemper <brad.kemper@gmail.com> wrote:

>
>
> > On May 17, 2016, at 5:05 PM, Florian Rivoal <florian@rivoal.net> wrote:
> >
> >
> >> On May 17, 2016, at 12:08, Brad Kemper <brad.kemper@gmail.com> wrote:
> >>
> >>
> >>
> >> Round Display has 'transform: rotate(<angle> | polar-angle |
> polar-angle-reverse)', which allows the standard rotate transformation to
> be derived from the angle of the "path" (the path was a ray, whose angle
> was called polar-angle).
> >>
> >> I think we should extend this to work with motion path too, to consider
> the angle at whatever point of the path the element is on. The syntax would
> be 'transform: rotate(<angle> | polar-angle | polar-angle-reverse)', With
> the path keyword in there, the path angle at that point is just added to
> whatever angle is specified, to determine its final rotation.
> >>
> >> Thus, if you have an airplane picture that points to the right, and a
> path that is at 45deg (that is, up and to the right), then 'transform:
> rotate(-90deg path)', would rotate the airplane 45deg - 90deg . Which is to
> say, it would be pointed at a 45deg angle too. If the path was pointed
> downward (motion-path: 180deg), then the plane would be rotated 180 - 90 =
> 90deg (clockwise), thus pointed down.
> >>
> >> If you had clock numbers whose baselines should be perpendicular to the
> ray, such that their bottom is toward the center of the clock, you would do
> this with 'transform: rotate(0deg path)'. Thus, the 12 o'clock position
> corresponds to a 0deg path, and there is no rotation. The 6 o'clock
> position corresponds to a 180deg path, and element is upside down.
> >>
> >> With this, no 'reverse' key word is needed, you just add 180 to your
> non-reversed angle to get it.
> >>
> >> This also gives you 'transform-origin' for free. You don't need
> 'motion-origin' to replicate that functionality.
> >
> > I thought we would be dropping transform: rotate(polar-angle) and
> transform: rotate(polar-angle-reverse)
>
> We didn't resolve one way or another about those.
>

We resolved to accept Fantasai's proposal, which (if I recall correctly)
was to drop transform: rotate(polar-angle).


> > in favor of motion-rotation. I suppose we could go the other way around
> and drop motion-rotation in favor of keywords in the rotate function,
>
> That's what I'm suggesting. I liked the idea of extending
> transform:translate() with a new value, rather than having a separate
> property that does the same thing.
>

It's clear that you like this idea. I will repeat what I said last time:
this is not a good approach for implementations.


> > but this looks less practical to me:
> > - if there's no motion-path (including a polar angle path), these
> keywords make no sense
>
> My syntax modification makes no less sense that the 'transform:
> rotate(polar-angle)' syntax that we had resolved on previously. It just
> makes it a little more versatile, so that we don't need a completely
> separate rotation transformation property that is just for paths.
>

Irrespective of prior resolutions, having a keyword exist that is
nonsensical 95% of the time is a bad idea, and we shouldn't do it.

Let me provide two more problems with your proposal:
(1) authors need to specify a transform to opt into auto rotation on paths,
even though this is a path feature, not a transform feature.
(2) authors who want to use both transform and motion-path need to consider
carefully the ordering semantics of transform. We already know that this is
confusing and difficult to do.


> If there's no motion-path, then motion-rotation as a property doesn't make
> any more sense. I don't see how moving it from a separate property to a
> value of an existing property decreases the sense it makes. I think it is
> simpler for authors to always use transform: rotate() when they want to
> rotate.
>

You're taking a property that always makes sense (transform) and injecting
partial values that don't. The motion-* properties can be considered an
independent unit, so it's far less problematic for individual properties in
that unit to require other properties in the same unit.


> The 'path' keyword for rotate() would just be 0deg if there was no path,
> so it'd add nothing to the angle, and would be the same as leaving it off
> in that case.
>
> > - from a cascading point of view, the various motion-* things are
> independent of the rest of the transforms, and I'd like to keep it that way.
>
> That's not what it sounds like to me from Shane. It seems like they all
> get thrown into the matrix in one order or another.
>

The matrix is post-cascade. I ***strongly*** agree that we should keep the
motion-* things independent of transforms during the cascade.


> > - Similarly, the various motion things are applied before the
> transforms, and I'd like to keep it that way.
>
> Why? It simpler to do all the rotating at once. The fact that motion-path
> and motion distance are done before the transforms is what enables the
> angle of the point on the path can be known prior to applying transform:
> rotate().
>

No! It is *not* simpler to do all the rotating at once. The order of
operations in transform lists is critical to the final outcome.
Additionally, computation doesn't work the way you think it does,
motion-path and motion distance are only "done" before transform if we add
another explicit dependency in computation to make that true. This adds
complexity, and makes our engines slower. I don't want to do that without
good reason.

> I don't think my syntax suggestion would change that much, other than to
make it a bit
> simpler. It would be:

> apply motion (= motion translation)
> apply translate
> apply rotate (including calculated rotation based on earlier motion
translation)
> apply scale
> apply transform

> You might get somewhat odd results by combining motion translation with
translate(), I
> guess, but the solution is for authors to not do that, or to do it with
eyes wide open. It would > be different from what is expected in current
motion-path spec, but not necessarily bad.

What happens in this scenario?

motion-path: <some path>;
rotate: auto;
transform: translate(100px) rotate(auto) scale(-1, 1) rotate(auto)

Cheers,
    -Shane

P.S. An alternative is to completely subsume motion within transformation,
and add a path() function to transform lists which takes a path, a
rotation, and an offset. While this would either require dropping the
motion-* properties or adding them as dependencies to transform, I think
that this approach is much more rational in terms of keeping like things
together.