Re: Proposal: Nesting SVG Graphics Elements

On Thu, 29 Nov 2012 21:38:25 -0500, you wrote:

>Hi, Steve-
>
>Thanks for your response.
>
>On 11/29/12 7:42 PM, Steve Schafer wrote:
>>
>> It seems to me that you're trying to embed what is more properly handled
>> as SVG editor functionality into the base language.
>
>I'm not sure what you mean here... can you elaborate?

I come at this as an implementor, on both ends, so to speak. I write
layout editors that generate SVG, and I also write code that reads and
manipulates SVG (but is not, at this time, a full-fledged SVG rendering
system). From that point of view, it is vastly simpler to implement
complex functionality on the editor side, and have it generate
"canonical" SVG, than it is to attempt to write code on the output side
to handle yet another way of expressing the same basic idea.

I'm not at all averse to syntactic sugar, but I do oppose sugar that
leads to ambiguity. Others have pointed out some of the problems, but my
biggest beef is with the nesting itself: Nesting implies containership
of some kind, but your proposal (assuming I'm understanding it
correctly) does not address containership; rather, it's about
association and relative positioning and overlaid painting.

So, going back to one of your examples, this slightly modified version:

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

And this one:

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

render indistinguishably.

That just gives me chills up my spine. ;-)

If this were in a WYSIWYG editor, what would happen in each case if you
click-dragged the rectangle? The circle? Would the dragged ogject move
(a) together with the other, (b) with respect to the other, or (c) it
depends on the nesting?

-Steve

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