SVG 1.2 Comments

Here are some comments that I have been working on in response to the 
SVG 1.2 last call.  I've been really trying to read all of the comments 
and discussion in www-svg, and I frankly have been less and less 
comfortable about adding my comments to the mix.  Why?  Well, for two 
reasons, mainly.  I seem to represent a very minor focus of the SVG 
specification, someone who is attempting to add some SVG functionality 
to an existing web browser, and I'm probably the least knowledgeable of 
the folks working on SVG in Mozilla.  Second, and perhaps more salient, 
is my confusion of the tone and WG response to comments made in the 
list.  I will freely admit that Ian Hixie's unfortunate initial response 
(throw the whole thing out and start over) did not set a really positive 
tone, the increasing animosity in the list makes me wonder whether the 
working group really wants comments, or at least comments from folks 
such as me, who have a very strong need for SVG+MathML+XHTML+Javascript 
in a browser that scientists are willing to use every day.  Note, this 
is not an accusation, this is a perception. 

I am also confused by the nature of the "Last Call", and the process.  I 
am not very familiar with the W3C, so I could use some education.  When 
I began putting my comments together, it was my understanding that 
comments would be submitted to the working group, which would consider 
them in total, and develop some form of formal, thoughtful reponse.  The 
"Last Call" is, as I understand it, the formal opportunity for 
"outsiders" who have not been part of the working group's process to 
read the output of the working group and give their input, which 
necessarily means that many of the comments will be new to the working 
group, and will come from views not well represented on the working group. 

I have concluded that I must be in error concerning the process.  It 
seems like the model is that each of the features of the specification 
be argued out in the forum until someone is convinced that the "other 
side" is right, without much opportunity for formal response from the 
working group as a whole, or even a recognition of the general 
sentiments being articulated by the posters.   I can certainly see the 
advantages to this more public form of discourse, but it seems like it 
might lead to more hard feelings than otherwise necessary. 

In particular, the sense that I have is that those providing comments 
(in particular the implementors of Opera and Mozilla) are raising some 
very solid concerns about implementing specific features within the SVG 
1.2 specification.   Given that we haven't seen any comments so far from 
Apple or Microsoft, the comments by members of the Opera and Mozilla 
development team represent a significant population of potential users 
(users of web browsers), and they seem to be speaking with a certain 
amount of unity.  One response that I've often seen by members of the 
working group is "we talked about that and discarded it".  Is that a 
valid response?  Of course, it may have been discussed, and may have 
been discarded for completely valid reasons, but without sharing the 
nature of that discussion, and the reasons for discarding the 
proposal/approach, its hard for those of us "outside" to understand what 
the rationale is, so (as a reader), I'm left really struggling to 
comprehend the positions of the working group.

I guess I'm also very confused by the positioning of the working group.  
It seemed to me that working with Opera, Mozilla, and Apple to implement 
SVG would be very important to the working group, as it would certainly 
have a significant impact on the use of SVG as part of general web 
content.  It is my perception, however (don't shoot me, I recognize the 
difference between perception and fact) that the SVG working group isn't 
really that interested in whether Mozilla, or Opera, or Apple, or even 
Microsoft implements SVG or not.  My perception is that the working 
group is working very hard to court the manufacturers of cell phones and 
other mobile devices, which is why they have defined SVG 1.2 Mobile.  
Why is there not an SVG 1.2 Web?  Is this audience not of at least equal 
importance?  Given the lack of a profile for mixed-namespace web 
browsers, I can certainly understand the perception of many of my 
colleagues that SVG is "not meant for use on the web", but for use 
"within embedded devices".  Is this true?

If, on the other hand, the developers of mixed-namespace web browsers 
(note that I'm specifically /not/ using the more generic term "user 
agent").  Then I would think that the working group would be working 
more closely with the folks from Mozilla and Opera to see what things 
they see as hard to implement, and what things they see as easy.  Having 
comments from a plug-in vendor that implementing something in their 
plug-in was relatively straightforward only serves to minimize the 
complexities of implementing a specification like SVG into an existing 
large, cross-platform code base.  Again, I may be missing something, 
here, and if I'm really way off base, let me know.  I am honestly confused.

End of meta comments...
*
*General comments*
*It is my belief that the focus of SVG should be on Scalable Vector 
Graphics, regardless of the pressures put on the working group by 
constuencies that are hoping to provide a broader base upon which to 
build applications.  In Section 5.1 of the Architecture of the World 
Wide Web, it clearly states that "Orthogonal abstractions benefit from 
orthogonal specifications" and that "A specification should clearly 
indicate which features advance into territory rightfully governed by 
another specification."  The example within that section even talks 
about the historical attempt by an HTML specifications to align with the 
HTTP specification, only to have the HTTP specification diverge, making 
"the two specifications awkwardly at odds with each other".  In 
particular, I strongly believe that the SVG Working Group's attempt to 
introduce networking APIs into the SVG standard is strongly at odds with 
the principal of orthogonality outlined in the Architecture of the World 
Wide Web.  The subtle changes in the wording between the SVG 1.1 and SVG 
1.2 specifications outline this.  From SVG 1.1:

    "This specification defines the features and syntax for Scalable
    Vector Graphics (SVG) Version 1.1, a modularized language for
    describing two-dimensional vector and mixed vector/raster graphics
    in XML."

 >From SVG 1.2:

    "SVG is a modularized XML language for describing two-dimensional
    graphics with animation and interactivity, /and a set of APIs upon
    which to build graphics-based applications/. This document specifies
    version 1.2 of Scalable Vector Graphics (SVG)." [emphasis mine]

I believe that mixing a modularized XML language for describing 
two-dimensional graphics and a set of APIs for network interaction is 
beyond the scope of the SVG Working Group charter.  While I recognize 
the utility of a set of standardized APIs for network interaction, file 
upload, and persistent storage, I believe that these interfaces should 
be standardized by a separate working group that will meet the needs of 
SVG, XHTML, XForms, and other web applications, and not be contained 
within a specification which should be focused on vector graphics.  As 
such I recommend that Appendix B be reworded to state that these APIs 
are not part of the SVG 1.2 specification, but are requirements for a 
future Web Applications working group and may be subject to change by 
that working group.  In this way, the current specification can offer 
these as guidance to SVG implementers without suggesting that the SVG 
Specification is now the appropriate home for Web Applications APIs, 
which requires specific input from the XHTML, XForms, SVG, and many 
other working groups.

Profiling SVG*
*This section provides strong guidance to implementors of SVG Viewers by 
discouraging any profiles other than Tiny, Basic, or Full, yet nowhere 
do these profiles get defined within this document.  If its critical to 
adhere to these specific profiles, than those profiles must either be 
defined within this document,  or linked to directly from this 
document.  Should there also not be feature strings corresponding to the 
implemented profile??  This would also be a place where it makes sense 
to talk about a "Web" profile.  There has been a lot of discussion in 
the www-svg list about the fact that it didn't make sense to "saddle" 
SVG Mobile implementors with "all of CSS".  However, I believe that 
there is lots of opportunity for an intermediate position when you are 
certain that CSS is available.

XML Binding Language for SVG
I'm not qualified to comment on the details of this, but as I understand 
the discussion, the intent of sXBL is to act as a placeholder or stopgap 
implementation until XBL is standardized.  This has been stated so many 
times, that it must be true, but shouldn't that be stated in the 
specification?   Implementers could make design decisions based on the 
existing specification only to be very surprised when a more broadly 
defined XBL specification is released.

Flowing Text and Graphics
I am /not/ going to wade into this firepit!  Plenty has been written 
that represents both sides of the multi-line text issue and I don't feel 
that I have much to add.  I do believe that there is a lot of room to 
simplify the SVG Text design without giving up on the stated 
requirements for flowing text within a region.  As an implementor, the 
number of elements really seems extreme.  As a content author, it seems 
completely overwhelming, and I honestly fear for the compatability 
issues that might result when I combine the various SVG text elements 
with CSS styling (I /do/ want to use CSS within SVG!).

One additional point, with all of the conversation surrounding precise 
line breaking algorithms, etc., I'm a little confused on how that would 
work when I use my "I'm over 50 and need larger fonts because my eyes 
are so bad" stylesheet?  I think that we  may re-introduce some of the 
consistency problems we used to have when we tried to do pixel-level 
design of web pages -- authors will make assumptions based on how their 
device renders the content, only to be surprised when users change font 
sizes and find that content is no longer visible... I know that an event 
has been defined to handle this case, but I have serious doubts that 
most authors will add code to gracefully handle the condition.

Multiple Pages
I guess someone really wants to define pagination for certain 
applications, but I don't see this being useful for most of my 
applications, so I'm going to let others more knowledgeable than I comment.

Text enhancements
OK, so editable text /really/ makes no sense to me in my mixed-namespace 
works.  So, I can edit text, what do I do with it?  Can it live in an 
HTML Form?  Is it available to an XForm control?  It seems that the only 
function value is to have a field that is available for script to get 
access to.  OK, but if I can have editable text, and have to write 
scripts to take advantage of the editted content, wouldn't I also want 
buttons, and menus, other widgets?   I guess I don't understand the use 
case in a browser context.

Streaming
I really think streaming should be left as a UA decision and not made 
part of the SVG Specification.   Other people have already commented on 
this and the very wording of this chapter indicates that the working 
group is uncertain themselves.  At this point, this is a very complex 
specification already.  Don't add anything not absolutely necessary!

Progressive rendering
Not sure that this even applies to the work that I'm doing in Mozilla, 
which doesn't get SAX startElement events (at least that I can see).  
Looks like this section is making certain assumptions about the 
underlying implementation, which seems inappropriate, but maybe I'm just 
confused (a common state).

Vector Effects
It must be getting late, because I really don't understand the need for 
all of this complexity.  Is there a concise use case that someone can 
give me that justifies all of these additional elements?  As I said, as 
an author, this spec looks incredibly complex to take advantage of.  
Perhaps I just need some more examples (with images) that show how it 
might be used to accomplish something that could not be accomplished in 
SVG 1.1.


Well, I've probably made enough enemies and demonstrated my complete 
ignorance of the workings of the W3C, SVG, etc., etc. so I'll stop 
here.  I've already given my input on the API additions in the 
appendices, which I really feel are inappropriate in SVG.  I still have 
never heard of a use case that would makes necessary for SVG, but not 
equally neccessary for HTML, etc.  Maybe these are features that are 
required for the mobile community, I wouldn't know about that, but 
perhaps they could be excluded from the "Web" profile.  I think that 
saying that the security is left up to the UA is completely 
unacceptable.  Some of the comments have pointed out the Java has 
similar functionality, but the Java specification includes a fair amount 
of documentation about the sandbox model.  I think that if it is 
absolutely necessary for a graphics standard to specify network 
interfaces, then it should also specify the security model for all of 
the same reasons.  If you don't then it is likely that implementations 
will diverge and you will get incompatibilities.  As specified, I for 
one would complain bitterly if it was implemented in Mozilla without 
some mechanism to completely turn it off, which would lead to the exact 
kind of divergence that the comments in chapter 2 suggested you hoped to 
avoid.

My overall comment is that while it is clear that there is a lot of work 
that went into this specification, it seems very complicated and not 
well suited for implementation within an existing browser.  As I said 
before, perhaps that is a secondary audience, which is fine, I'm frankly 
having enough trouble with implementing my little piece of SVG 1.1 in 
Mozilla (did gradients /really/ have to be able to refer to other 
gradients?!?  Sheesh!)

-- scooter

John "Scooter" Morris, Ph.D.

Received on Wednesday, 10 November 2004 06:30:43 UTC