Re: SVG 1.2 Comments

Hi Scooter (brought back memories of the Muppet show!)

On 10 Nov 2004, at 17:28, Scooter Morris wrote:

>
> 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 think you make a very fair point. However, I'd really like to
emphasise that the SVG Working Group appreciates all the comments.
It's unfortunate that the exchange with Ian got heated, but I think
that's because we know each other (Ian and the SVG Working Group).

Ian's comments were very helpful, and I think it is fantastic
that he read the specification in such detail. I'm sure it was
a significant investment of his time. I appreciate his effort
(and I think he knows this... don't you Ian?). It's unlikely
that I'd ever get that much time to review and comment on
a CSS specification :(

I'll vouch for the Group in saying we are extremely interested
in SVG+XHTML+whatever. In fact, we started a Compound Document Formats
Working Group at W3C in order to address this use case.

Please send in your comments!

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

The formal requirement is that the SVG Working Group MUST consider
*every* comment made during last call, and MUST respond to each
comment. The goal is to reach consensus if possible. In many cases
it is, in other cases it isn't.

For example, despite the really long and sometimes heated discussion on
flowing text, I'm fairly confident we can reach consensus sometime
(eg. Ian seems to be happier with the suggestion that we provide
a method that allows the UA to use its own algorithm). The opposite
example is Ian's suggestion to drop the entire spec, where I doubt
the W3C would be happy with any resolution that accepted that comment.

There is also a requirement that we get some form of
acknowledgement from the person that made the comments as to
whether or not they are happy with the resolution.

In summary, all comments are equal. All comments are considered. All
comments are resolved (to some level of satisfaction of the submitter
and the Working Group).


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

It's probably a little terse :)

>  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 it just comes down to how much effort we can invest
to explain our position. Sometimes it gets a little difficult to
put the time in (there are only so many hours in the day, and I'm
sure everyone hates being involved in long heated email threads).
Be assured that I've never tried to dismiss a comment by saying
"we looked at that and decided it wasn't acceptable". Normally that
means "we spent hours and hours arguing over this, multiple times,
and eventually concluded that it didn't meet our use cases/requirements
and we believe we found a better solution". Sometimes it is
extremely difficult to remember all the points of view, and it takes
a huge effort to go back through all the minutes to explain why
something was rejected as opposed to an alternative accepted.

One thing I've found with standards work, like normal project
management, is that you often have to make resolutions and stick to 
them.
You can't constantly open past history. Honestly, my experience is
that when this happens 95% of the time you have the same discussion
and come to the same conclusion (and everything has slowed down
as a result). Hopefully you get to recognise the other 5% at
the start, because they are the ones you want to reopen.

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

You're right. I'd like Opera, Mozilla and Apple to join the Working 
Group,
where there is a much higher level of communication (we meet on the 
phone
and face to face for example). I'm sure it would help them, and it would
certainly help us.

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

I'm sorry you have that perception.

Here's my feeling: That there is a valid market (and Web) desire for
something that addresses what SVG does. This applies to both desktop
and mobile devices (it's the same Web). Unless we get strong support 
from
the community a proprietary solution will dominate. Open source and
open standards need to work together, not complain about each other.
Open standards and closed source should also work together, but
probably will complain about each other whether we like it 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.

That's true, but it is probably better expressed the other way around.
Many manufacturers of cell phones joined the Working Group in order
to develop SVG 1.2 Mobile. The original SVG language didn't really
address the constraints of this market, so instead of choosing
a proprietary competing technology, the manufacturers joined the
group to make SVG more open and interoperable.

> Why is there not an SVG 1.2 Web?  Is this audience not of at least 
> equal importance?

Definitely. We really believe that SVG Full is appropriate for the
Web. However, it seems that getting SVG Full implemented on desktop
browsers is going to take a long time, or we *may* have to do something
like what CSS did (admit that CSS 2.0 didn't really work and come up
with a CSS 2.1 that is supposed to).

At the moment, we're more like CSS 3, which I assume is also targeted
for the Web, but doesn't look like it will be implemented (or even
finished) for many years. I'm not criticising CSS here, btw :)


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

We definitely consider it as meant for use on the Web.

In defence, SVG probably went to more effort than any other 
specification
to use existing Web technologies (including JPG, Javascript, PNG, DOM, 
SMIL,
XML).

The W3C, in another working group, are developing profiles for
mixed-namespace web browsers. It makes a little more sense to do it
outside the individual working groups (because it is mostly
about coordination).

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

Just on this point, Adobe have said (in this forum) that they are
implementing XHTML with SVG. They don't seem to consider themselves
as just a plugin vendor, and definitely are not implementing
SVG in isolation. There are also many other members of the working
group that are developing browsers to handle multiple namespaces.

That's not saying that Opera and Mozilla are not important. Not at
all. Just that there are a lot more browser vendors. One reason
that you don't hear complaints from them is that they actively
participate in the Working Group, unlike Opera and Mozilla.

[And I did avoid using "user agent" but probably still clashed with
your definition. I assume you meant desktop web browser, but my feeling
is that there is only one web, so mobile browsers shouldn't be 
segregated]

Again, I encourage Opera and Mozilla to join the Working Group
which is a much more effective way of working than through
this email list. (ie. unlike you, they have the opportunity for
a better working environment, and we'd like them to take it -
we'd be able to work out how to make it a public forum if
that is what they desire)

>   Again, I may be missing something, here, and if I'm really way off 
> base, let me know.  I am honestly confused.

Thanks for raising your concerns. We talked about it and discarded it.

Just kidding.

Everything you've raised is a valid concern, and I'm glad you told
us (and in such a nice manner :)

For the general comments, we'll address them separately (thanks to
Ian and others we have a sizeable queue to get through).

Dean





>
> 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 09:03:34 UTC