Re: Proposal: Nesting SVG Graphics Elements

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

> Hi,
> 
> I just come to add my author's 2ct to the discussion. Note that I just express a very personal opinion here and I do not pretend to speak to anybody else.
> 
> 
> 2012/11/29 Doug Schepers <schepers@w3.org>
> Hi, SVG WG-
> 
> I have a proposal that may make SVG2 easier to understand and use for people already familiar with the HTML+CSS world.
> 
> The basic idea is to allow rendering elements to also serve as container elements, with child rendering elements also rendered. (This is currently not very clearly specified in SVG1.1.)
> 
> Currently, to associate 2 rendering elements, you have to use a group, like this:
> 
>   <g id="g1">
>     <rect id="r1" x="5" y="10" width="70" height="40" fill="yellow" stroke="red" />
>     <text id="t1" x="15" y="35" font-size="12" fill="crimson">Some label</text>
>   </g>
> 
> This can be problematic for positioning the elements relative to one other, and to moving the whole unit (yes, you can use a transform, but for drag-n-drop, you have to know what to grab and drag).
> 
> Yes, I think this is the main issue with SVG, elements are all positioned relatively to the same point of origine. I egree this is something a bit disruptive for people that come from the HTML+CSS world (where everything is relative), but frankly, it doesn't require hours of work to understand the basics.
>  
> We could allow authors to do this by simply nesting the text element, which would render on top of the rect (using the same Painter's Model), and could be positioned relative to the new established coordinate space of the parent shape:
> 
>   <rect id="r2" x="5" y="10" width="70" height="40" fill="yellow" stroke="red">
>     <text id="t2" x="50%" y="50%" font-size="12" fill="crimson">Some label</text>
>   </rect>
> 
> Hug! I'm not sure it's that simple because it leads to hundreds of questions that were pointless before that. One of the biggest is related to the inheritance of CSS properties. For example, in your code sample, does the text inherit the stroke property from the rect? All of this is not define and it's a huge work to check all of this for, IMO a very small benefice
> 
> I agree with Tab that having to set a translation to a <g> element in order to reposition a whole group sucks and is far from obvious.
> 
> But if the true issue is to have a way to position element in a relative maner, I suggest another solution:
> 
> <g dx="10" dy="10">
>   <rect x="10" y="10" width="50" height="50">
> </g>
> 
> The dx and dy attribute on the g element could be use to shift the point of origine used to position its children. So in the previous example, the <rect> element is position at the coordinate 20,20 (dx+x , dy+y)
> 
> This allow to build some interested shift in nested elements
> 
> <g dx="10" dy="10">
>   <g dx="5" dy="-5">
>     <rect x="10" y="10" width="50" height="50">
>   </g>
> </g>
> 
> Now, the <rect> element is at the coordinate 25,15
> 
> And it should be possible to even redefine a coordinate system related to the root coordinate system with the x and y attribute applied on the <g> element:
> 
> <g dx="10" dy="10">
>   <g dx="5" dy="-5">
>     <g x="0" y="0">
>       <rect x="10" y="10" width="50" height="50">
>     </g>
>   </g>
> </g>
> 
> With x and y we offer authors a convenient way to reset the coordinate system even if they have build an insane tree of <g> elements (end they will). With that last example, the <rect> element is back a the coordinate 10,10
> 
> I really think that will make things a lot easier for people coming from the HTML+CSS world: They have nothing to worry about the few thing they already know about SVG and CSS, but they can build things in ways that make position relative one against another.
> 
> 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)"? 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.

Greetings,
Dirk


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

Received on Monday, 3 December 2012 12:01:11 UTC