Re: Proposal: Nesting SVG Graphics Elements

Hi, Steve-

On 11/30/12 6:35 PM, Steve Schafer wrote:
> 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.

I think it's valid to consider the impact on hand-authored content, 
machine-generated content, and hand-refined machine-generated content. 
The proposal doesn't make any of them more difficult, so far as I can 
see, but it does make certain things easier.


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

To a certain extent, it doesn't matter that HTML+CSS is flawed (as if 
there were a perfect programming language or markup out there)... what 
matters is that it's a model that millions of people are familiar with, 
so if we can introduce concepts that are similar enough that it makes it 
easier for people to understand without introducing new problems, that's 
a good thing.


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

The current proposal is still just a thought-experiment. It doesn't 
introduce any implementation ambiguities, because it isn't yet ready to 
implement.

If we develop it further, we must do so to the point where there are no 
such ambiguities... after all, that's what a specfication should be.

Regards-
-Doug

Received on Saturday, 1 December 2012 04:48:40 UTC