W3C home > Mailing lists > Public > www-svg@w3.org > December 2012

Re: Proposal: Nesting SVG Graphics Elements

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 3 Dec 2012 05:30:51 -0800
To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
CC: Doug Schepers <schepers@w3.org>, SVG public list <www-svg@w3.org>
Message-ID: <F88CFB18-BB3E-4B8D-A34F-CE1B14925DFB@adobe.com>

On Dec 3, 2012, at 5:01 AM, Jeremie Patonnier <jeremie.patonnier@gmail.com> wrote:

> 2012/12/3 Dirk Schulze <dschulze@adobe.com>
> On Dec 3, 2012, at 3:12 AM, Jeremie Patonnier <jeremie.patonnier@gmail.com> wrote:
> > This alternative proposal does not really change SVG as it is and offer a nice short cut for user who wish to perform SVG hand editing.
> But where is the difference of using: transform="translate(dx, dy)"?
> Almost none, it's syntactic sugar with a little difference: those attributes act like the translation is applied before any other transform and the transformation operate by those attribute is not visible in the list of transformations. They act really like the point of origine has changed, not just by moving the elements. This is why, in this proposal, it is possible to reset the coordinate system with the x and y attribute (doing this with transform is just a pain in the ass because you have to check all the transformation applied along the DOM tree if you have nested elements with a transform on each).

This sounds rather like the use case of transform-origin, that will be a presentations attribute in SVG[1]. But IIRC you are not just changing the point of origin, but really translate the group in the current coordinate system. I don't see why you would need to avoid the transform showing up in the transform list? What is the problem of the transformation list? At least we have a SVG DOM API that let you traverse the transform list (which is not the case for CSS3 Transforms).

>> I would rather say that HTML+CSS authors won't have this big problem with it, given the fact that we have CSS3 Transforms in HTML as well.
> You should'nt assume that. HTML+CSS authors are fare from familiar with CSS Transforms, and transformation in the CSS world are really disruptive (I see that every day with many people around me). From my perspective, only authors with advanced skills are ok with transforms. Most of the time they use it with JS on top of it and when they edit it by hand it's to perform very small change (especially because it's not supported in legacy browser so they cannot relay on it, therefor they learn slowly how it works). And to be  honest, the quality of cross-browsers implementation of CSS transform is not very good (poor rendering or horrible performance, make your choice) which does not help the authors to embrasse them at a large scale. So it remains an aside technologie in HTML+CSS.

You brought up assumptions of HTML+CSS authors. However, we should not be stock on the knowledge of web developers today. If they don't understand transforms today, they will need to understand it tomorrow. Transforms are a fundamental part of SVG and will get it in HTML as well. If you want to write SVG code manually, you will catch up very fast on it. dx and dy are very easy to implement, but the reason to support them seem to be wrong.


> Best
> -- 
> Jeremie
> .............................
> Web : http://jeremie.patonnier.net
> Twitter : @JeremiePat

[1] http://dev.w3.org/csswg/css3-transforms/#transform-origin-property
Received on Monday, 3 December 2012 13:32:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:30 UTC