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 
drawing).

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 
differently.

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC