Re: Proposal: Nesting SVG Graphics Elements

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. Furthermore, your request wouldn't be fulfilled with this proposal as well. It is not positioning elements relative to each other but nesting. 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.

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. It needs a lot of specification work either.

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

Greetings,
Dirk

> 
> ~TJ
>

Received on Friday, 30 November 2012 01:42:28 UTC