Re: Proposal: Nesting SVG Graphics Elements

On Fri, Nov 30, 2012 at 4:23 AM, Cyril Concolato <
cyril.concolato@telecom-paristech.fr> wrote:

>  Hi Doug,
>
> When I teach SVG to my students, I explain that the way to group things in
> SVG is to use <g> (or <defs> for other purposes): for positioning, for
> animating, for interacting with the children together. Even if they have
> some HTML knowledge and practice, in general they understand it very well.
> I think the use of <g> brings some useful structuring to SVG content, also
> semantically. So, I'm a bit worried that this proposal makes people use SVG
> in a less structured manner.
>

Yes, 100%, totally agree.

SVG has a nice concise method for grouping elements that works very well.
<g>  Making every element a container element, to me, seems very chaotic
and unnecessary.


>
> Regards,
> Cyril
>
>
> Le 30/11/2012 08:30, Dirk Schulze a écrit :
>
> Have serious problems with mails today. Looks like my previous mail got lost.
>
> Hi Doug,
>
> On Nov 29, 2012, at 7:54 PM, Doug Schepers <schepers@w3.org> <schepers@w3.org> wrote:
>
>   This proposal makes it harder to understand an SVG file if you have
> nested elements:
>
> <rect width="200" height="200">
> 	<circle>
> 		<rect>
> 			<circle/>
> 		</rect>
> 	</circle>
> </rect>
>
> This is reasonable for HTML, but not for SVG.
>
>  This doesn't seem hard to understand to me at all... How is that any
> more confusing than
>
> <g transform="translate(x,y)">
>   <rect width="200" height="200"/>
>   <circle/>
>   <g transform="translate(x,y)">
>     <rect>
>     <circle/>
>   </g>
> </g>
>
> (or whatever the equivalent would be)? Why is nesting more reasonable
> for HTML than SVG?
>
>  You forget some very important points. It is not only about positioning, but also about dimensions. If I understand you discussion on IRC about it correctly, child elements should also be sized dependent on the parent element.
>
> <rect width="200" height="200">
> 	<rect width="100%" height="100%"/>
> </rect>
>
> In this case the inner rect element would have a size of 200x200 pixel, because percentage values are resolved to the parent, which is fine here.
>
> But what about this example:
>
> <rect width="200" height="200">
> 	<rect width="120%" height="120%"/>
> </rect>
>
> The bounding box of the parent is 200x200. The child element would get the size of 240x240. This means the bounding box of the parent must change to 240x240 as well. An infinite loop, or just not possible to solve.
>
> But even if it is not relative to the parent size:
>
> <rect width="200" height="200">
> 	<rect x="40" y="40" width="200" height="200"/>
> </rect>
>
> The dimension of the inner child element is 240x240 which affects the bounding box of the paren which used to be 200x200. We are opening the Pandora's box with it. It doesn't stop here. It has affects on masking, filters and clipping as well, which will be relative to the painting bounding box or define the painting bounding box can can collude here.
>
> This is just one reason why you can't size a <g> element.
>
> Greetings,
> Dirk
>
>
>
>
>   It needs a lot of specification work either.
>
>  Agreed, and I'm willing to do that work.
>
>
>
>  I spoke to designers as well. When I mean designers, I mean one, and
> one in my team. Suggesting this his answer was just "Reasonable, but
> what for?". Of course it is just one opinion, but at least I give a
> number and at least I give the source.
>
>  This is kind of a strange assertion... I made no claim that I had done
> an exhaustive survey of designers, but I'm happy to list my sources as
> well.  I spoke to several local designers with only a passing
> familiarity with SVG, and asked them questions that I thought were
> pretty objected (i.e., not leading, but just recording their immediate
> impressions).  I also spoke with Lea Verou, and Tab Atkins. And through
> the years, I have seen and heard questions from several people asking
> why you can't nest shapes (mostly newbies), which I never thought much
> about until just recently.
>
> But this is a relatively big change, so I'm happy to take it slow,
> develop the proposal to anticipate all the issues that might arise and
> how to specify things to the level of detail necessary, and to make a
> survey of designers and developers to see if they find it useful.
>
>
>
>  This proposal makes SVG more complex, less likely to get implemented
> in an interoperable way and harder to understand. I don't support
> this proposal at all.
>
>  I think you may be reading more into my proposal than I meant... I need
> to articulate it more clearly. I don't see this being any more complex
> than the existing model... and not really that different.
>
> Regards-
> -Doug
>
>
>
> --
> Cyril Concolato
> Maître de Conférences/Associate Professor
> Groupe Multimedia/Multimedia Group
> Telecom ParisTech
> 46 rue Barrault
> 75 013 Paris, Francehttp://concolato.wp.mines-telecom.fr/
>
>


-- 
    "It's hard to believe that something which is neither seen nor felt can
do so much harm."
    "That's true.  But an idea can't be seen or felt.  And that's what kept
the Troglytes in the
mines all these centuries.  A mistaken idea."
-- Vanna and Kirk, "The Cloud Minders", stardate 5819.0