Re: Proposal: Nesting SVG Graphics Elements

On Thu, 29 Nov 2012 16:59:33 -0800, you 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.

I've hand-edited SVG (and other XML formats) for many years. I've also
hand-edited plenty of HTML+CSS and even machine-generated PostScript as
well. Yes, it's doable, but I certainly wouldn't want to create a
complex layout that way. And, despite your claim above, the number one
reason I do hand-edit these formats is for debugging machine-generated
documents.

As for the HTML+CSS layout model, I wouldn't necessarily put that up as
a pinnacle of achievement... It works, but it's ridiculously easy to
construct documents that are perfectly valid syntactically, but whose
behavior is unpredictable or just plain broken. I'd hate to see SVG go
down that path (any more than it already has, but that's a topic for a
different discussion).

I agree that the current SVG method of <g> + transform is not the
simplest thing to use, nor the most elegant to read. But it has the
advantage of being about as unambiguous as possible. I'm all for
syntactical clarity, but not at the expense of implementational clarity,
and as others have pointed out elsewhere, the current proposal
introduces a whole host of ambiguities in that regard.

-Steve Schafer

Received on Friday, 30 November 2012 23:35:39 UTC