Re: Proposal: Nesting SVG Graphics Elements

On Thu, Nov 29, 2012 at 5:41 PM, Dirk Schulze <dschulze@adobe.com> 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. 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.
>

I agree with Dirk.
This is not the right direction for SVG. It muddies the concepts of all the
tags and will make it much harder to implement.
The HTML and SVG drawing model are completely different and I would be
weary if we try to harmonize them. The HTML folks want to see the box model
everywhere; graphics people do not.

I think that there is a schism in the SVG group.
Some people want high level concepts like markers and connectors that
provide rich content, needs complex specs and are slow to render; other
people want to see the language as lean as possible with a small spec so
UA's can spend their time on making it faster.

What do we want SVG to be? Should it be a retained version of Canvas or
graphical HTML?