Re: Proposal: Nesting SVG Graphics Elements

Hi Doug,

I think your proposal is interesting. It clearly needs discussion. I 
don't have a strong position, just some thoughts.

 From a renderer implementation point of view (just first thoughts), if 
you don't require the <rect> to constrain the rendering of the <circle> 
and if you just use it for grouping, relative positioning and property 
inheritance (basically as a <g>), I don't think it would be a big deal. 
It's just a matter of adding a RenderChildren call. If you add more 
features like clipping or viewbox with preserveAspectRatio, or resizing. 
This would mean making every graphical element similar to <svg>. This 
would probably require more work for an implementation. But this could 
be a good way to mix HTML/SVG together like: <p>...<circle></circle> ... 
</p> without an <svg> element.

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.

- I think people looking a <circle><rect/></circle> will expect 
rightfully that the <circle> does something on the <rect> (clip, 
resize), because otherwise you'd use a <g>. The clipping case can 
already be done differently, and Brian had suggested another way too 
(IIRC (not sure) having a <clipPath> as a direct child). I don't think 
it would be good to introduce a third way. The resizing is maybe a good 
use case, as Cameron pointed out for a <rect> fitting a <text>. But 
maybe we just want to allow text in graphical elements.

- regarding the reference to the spec you were looking for, I found in 
SVG Tiny 1.2 
(http://www.w3.org/TR/SVGTiny12/single-page.html#implnote-UnsupportedProps)
"Within anSVG document fragment 
<http://www.w3.org/TR/SVGTiny12/single-page.html#intro-TermSVGDocumentFragment>, 
any subtree that is rooted by an unknown element [...] or a known 
element that occurs in unexpected location, is not rendered. The nodes 
in the subtree are not processed beyond including the relevant DOM 
objects in the document tree. Those DOM objects will still implement the 
DOM interfaces appropriate for the element type, however."
The key is "a known element" <rect> "in an unexpected location" inside a 
circle. I think that was the intent of 1.1 too (as Ken pointed out).

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> 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, France
http://concolato.wp.mines-telecom.fr/