Re: [css-transforms] 'transform' longhands and their origins, introducing origin() functions

On 07/14/2014 02:10 AM, Alan Gresley wrote:
> On 14/07/2014 5:23 PM, fantasai wrote:
>
>> On that note, if there needs to be separate origins for the longhands,
>> they should not be handled as origin() functions as you propose [1],
>> since you generally want to cascade the origin and the value independently.
>
> Why? I can see reasons why you would want to use a different origin on
> hover. The below would be exposed to most functions of
> the transform either being longhand or a transform-list.
>
> el:hover { transform-origin: bottom right }

I'm not really following the logic here.

I can see why you would want to have a different origin for rotate
than for skew, but I don't see what :hover has to do with it.

>> An origin() function might be useful for translate-list, however, to
>> avoid the awkward translate-untranslate pattern Dirk mentions [2].
>
> How is this awkward? The property 'transform-origin' does not effect
> translate, translateX, translateY, translate3d and
> translateZ. Only scale, rotate, skew and matrix depend on transform-origin.

transform-origin isn't awkward; I think it's fine.

But if you want to do a complex ordered set of transformations
using different origins for different parts of it, you might
want to be able to reset the origin explicitly with an inline
origin() function (that takes translate-origin's syntax)
instead of translating over the origin, transforming, and then
untranslating.

I consider translate-transform-untranslate to be an awkward
way to set the origin of a transform function. You are doing
an unnecessary operation, which you then need to undo. On top
of which, you have to repeat the argument: once positively,
once negatively. How is it *not* awkward?

~fantasai

Received on Monday, 14 July 2014 20:25:14 UTC