W3C home > Mailing lists > Public > www-style@w3.org > July 2014

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

From: Rafal Pietrak <rafal@ztk-rp.eu>
Date: Wed, 16 Jul 2014 09:19:53 +0200
Message-ID: <53C62799.1000904@ztk-rp.eu>
To: www-style list <www-style@w3.org>

W dniu 15.07.2014 22:07, Tab Atkins Jr. pisze:
> On Tue, Jul 15, 2014 at 11:51 AM, Rafal Pietrak <rafal@ztk-rp.eu> wrote:
>> What I tried to say is, that all this just adds up to conclusion, that
>> instead of supplementing current svg drawing model with c.a 20 new
>> properties entangled with current transforms, most of the cases could
>> probably be addressed by uniform introduction of (some) local coordinate
>> system. This works for cairographics, could work here.
> Hm, I'm not sure how that addresses any of this, though.  Note that
> transforms *already* deal with local coordinate systems - whenever you

Yes, true. The <G>/<USE> actually give us sort of local coordinate 
system, "indirectly".

> transform an element, you're actually transforming the coordinate
> system it uses (which is why there's a difference between
> "rotate(90deg) translateX(100px)" and "translateX(100px)
> rotate(90deg)").

Yes. Naturally they are just transformations, and I can explicitly do 
whatever I need to do, by properly stacking them accordingly. I can 
maintain my own transformation matrixes to get me back and for to/from 
that preferred coordinate system.

I know that, and still I'm  not doing it, until "things get unmanagable" :(

I fell to the same error prone scenarios, that've been expressed by others.

> Can you elaborate on what you're suggesting, and how you think it
> might help?  I suspect there's an inferential gap I'm not crossing.

:\ sorry.

Yet, I'd rather believe that it was the fact, that I've started to 
present my point of view from far away of your proposal, i.e: I wasn't 
trying to suggest changes to your proposal, but rather to look at the 
problem from entirely different perspective.

And I must admit, that I'm not quite sure how to apply this (i.e 
explicit local coordinate system) to svg language.

As I'm revisiting now my earlier struggles with svg, I can see the 
following point where the two approaches could possibly meet:

1. when I used <g>/<use> to reuse graphic components, I've often was 
longing for the initial graphic not getting displayed. example: <g 
id="one"><path .... display:none></g><use xlist:href="one" display=true 
/>; This way the coordinate system of the original content of <g 
id="one"> is "truely local" i.e.: it will not get onto the display, so 
need not be of any relevance to the coordinates of a viewport - thusly 
be local.

2. just like "translate" builds up a transformation matrix for an 
element, another attribute (say: "origin"), could be defined to build 
transformation matrix to local coordinate system. (but here, I'm not 
quite sure how to give that back to developer for reuse withing the 

But no, I don't have any clear view of how to provide that functionality 
to svg. I just wanted to suggest "taking a deep breath" before 
introduction of (admittedly handy) another 20 attributes to it, possibly 
having another look at other drawing environments, that did things 

Received on Wednesday, 16 July 2014 07:20:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC