Re: Proposal: Nesting SVG Graphics Elements

Hi, Dirk-

Thanks for your frank response. I'm not sure I stated my proposal well, 
because some of your comments aren't clear to me...

On 11/29/12 8:41 PM, Dirk Schulze wrote:
>
> On Nov 29, 2012, at 4:59 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>> On Thu, Nov 29, 2012 at 4:42 PM, Steve Schafer <steve@fenestra.com>
>> wrote:
>>> It seems to me that you're trying to embed what is more properly
>>> handled as SVG editor functionality into the base language. My
>>> personal preference would be to keep the SVG representation
>>> itself as "lean and mean" as possible, and put all of the
>>> interactive manipulation expressiveness into a higher layer.
>>
>> I strongly disagree.  SVG can be hand-authored just fine, but some
>> features are impossible to use in practice, seemingly because they
>> were designed with the same mindset you're espousing.  If a format
>> can't be hand-authored, it can't be reasonably hand-editted or
>> hand-debugged either.
>>
>> As well, as Doug points out, this pulls SVG more in line with the
>> model that authors are familiar with from HTML/CSS, where drawn
>> boxes can be nested inside of each other.  Beyond this basic
>> correspondence, I think it's just plain easier to use - I can't
>> tell you how many times I've started some portion of a drawing with
>> a <rect> using x and y to position it, only to be forced to set it
>> to x=0 y=0 and move the positioning into a <g transform> so that I
>> can link its position with other elements.  With this change, I'd
>> be able to keep my original code and use the (imo more natural) x
>> and y attributes to position things more often.
>
> And that is the main difference between SVG and HTML. HTML is layout
> based, while SVG is positioned based.

I'm not sure that I agree those are canonical features of HTML and SVG.


> Furthermore, your request wouldn't be fulfilled with this proposal as
> well. It is not positioning elements relative to each other but
> nesting.

In my proposal, the nesting would affect the positioning.

In this example

   <rect id="r4" x="100" y="10" width="40" height="40">
     <circle id="c4" cx="70" cy="20" r="20"/>
   </rect>

c4 would have the "computed" positions:
  @cx of 170 (100 + 70)
  @cy of 30 (10 + 20).


> And to your request: Not every concept that works and is reasonable
> in HTML should be adapted in SVG. Instead we should work hard on
> interoperability between both formats. Relative positioning makes
> sense when you add an SVG element in an HTML context. And as you
> said, we can group and transform elements. In the opposite to HTML,
> presentation and content is one part in SVG.
>
> For pure SVG I would strongly disagree with the statement "authors
> are familiar with from HTML/CSS, where drawn boxes can be nested
> inside of each other". As an SVG author I would not expect that at
> all. SVG is a graphics format, not a document layout format.

I've made plenty of SVG files that are all text... but that's not your 
point.

Even if it is a graphics format, why does that necessarily require the 
"flat" structure SVG files have now?  Conceptually, either approach 
makes equal sense... it's an arbitrary choice, really.


> 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?


> 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

Received on Friday, 30 November 2012 03:55:10 UTC