Re: SVG 1.2 Comments

John,

Note that this is a reply just form one member of the WG. WG might or might 
not agree with it - it will take some time to review these comments.

At 10:28 PM 11/9/2004 -0800, 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.

We absolutely want to hear from you and you should not feel intimidated by 
the tone of the discussion. The fact that your UA is doing other W3C 
standards is a definite plus as well.

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

Last Call means that this is your last chance to look at it. Really we 
encourage people to look at the working drafts as we work on them; in fact, 
proper time to discuss many big items (like should SVG allow automatic text 
wrapping) was probably about two years ago or more. (In my selfish view...) 
a lot of implementation work happened since then. Big changes late in the 
cycle really inhibit willingness of managers to invest developers' time in 
following the draft. Nevertheless, better later than never.

Yes - and one important difference about Last Call period is that the WG is 
required to review (and, I think, respond) to all comments made on this list.

>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 think that WG won't give official response to every single message; it 
will probably go by the thread. I can assure you that there are several 
members of the WG that have fairly good understanding of the sentiments 
expressed here. (Actually I do agree with several points in Ian's comments. 
It is just that discussion centers around the things that people don't 
agree on. Fire is always brighter than the background).

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

There is a fact that the WG reviewed a proposal for the automatic text 
wrapping which was very close to the one made by Ian and rejected it 
because it did not satisfy the use cases. It was not just "talked" about, 
we do have a process and we do try to satisfy the use cases. It was also 
not "discarded", but rejected, for the grounds that were explained.

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

I cannot speak for the whole WG here, just for myself. I would be 
*extremely* interested in Opera, Mozilla and Safari implementing SVG as a 
first class citizen. However, SVG 1.0 became a Recommendation more than 3 
years ago and none of the above browsers have any significant portion of 
SVG implemented. No one from the above browser teams is a member of the WG, 
even though all of them have W3C membership, moreover they have formed an 
organization which is in many respects tries to bypass the W3C process 
(www.whatwg.org). I know that SVG is somewhere on their lists, but 
somewhere very low. On the other hand we have incredible level of interest 
in SVG from the mobile vendors, who participate very actively in the WG. So 
there is no conspiracy there - people that represent HTML browsers *chose* 
not to join the WG and people who represent mobile devices *chose* to join.

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

SVG is meant for the web. The problem is not the lack of the profile for 
mixed namespace browsers, but in the lack of implementation in the major 
browsers, which for better or for worse care more about IE compatibility 
than W3C standards (I cannot blame them). If IE came up native SVG 
implementation, my guess is that we'd see much more movement in this area 
from other web browser vendors. On the other hand in mobile area there is 
no dominant browser and ability to innovate is better.

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

We'd like to work more closely with folks from Mozilla and Opera, it would 
be nice if they join the WG, of course, or at least monitor the draft more 
closely. Certainly sending comments saying basically "the stuff that you 
did for 3 years is garbage, throw it away" as Last Call comments does not 
help. Forming whatwg.org does not help. Ridiculing SVG WG in personal blogs 
does not help. (all of those thing are perfectly OK things to do, but they 
do not suggest any serious interest in SVG).

My comments that you seem to refer to said that
- adding automatic line breaking adds only 10-20% of code to SVG 1.1 text 
engine
- it is quite natural to have a single text engine that does both CSS and 
SVG text layout and I have a sizable chunk of CSS done in this way

Note that even if line breaking is tossed out of SVG 1.2, the second point 
still holds. Doing SVG 1.1 text layout is not all that easy mostly because 
of internationalization and rich text features - it even has line breaking 
(e.g. bidi has to be implemented in multi-line form), but just not 
automatic one. Everyone I know who implemented any reasonably complete SVG 
1.1 text engine agrees with the above two points. Line breaking is actually 
a piece of cake in comparison with combination of bidi, vertical text, 
glyph-orientation and baseline alignment (all four can be used together and 
interact in some funny way).


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

We certainly plan to hand off these APIs to Web Application APIs. The 
change that you outline is not subtle and reflects actual usage of SVG on 
the web. In ideal world these APIs (along with so called browser "Window" 
interface) would have been defined long time ago, unfortunately this has 
not happened and before SVG WG started the process of standardizing this 
there was no activity in W3C to do anything about it.


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

I think a lot of this is because SVG 1.2 was not yet merged with SVG 1.1 - 
which as I understand will happen.


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

This is very clearly stated in sXBL draft: http://www.w3.org/TR/sXBL/


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

I am not going to wade into that firepit either! I have enough burns already.


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

You bring up a very good point. In general, the answer for "big text" in 
SVG is *not* making text size bigger, but zooming in. If you simply make 
text bigger it will simply clatter the rest of the graphics and will likely 
to be more confusing to the reader. Here is a practical way to do it: emebd 
your SVG with width and height expressed in em or ex units and put a 
viewBox on the top-level SVG element. That will automatically scale both 
text and graphics up when larger default font size is chosen. On the other 
hand, there might be some SVG document that are specifically designed to 
work with wide range of font sizes. For such documents automatic line 
breaking is a must, since font size is not known in advance (of course, 
consistency of how exactly lines are broken is of much less important in 
this particular case).


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

Multi-page and printing enhancements is something we were actually 
chartered to do.


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

Text editing is a nice building block for having rich graphics 
applications. People do it today with SVG 1.1 APIs and scripting - but it 
invariably ignores internationalization and cannot be made accessibile. 
That has to end. Think of some twiki-like web app, but for diagrams, for 
instance. People like to edit text in-place, not in a special pop-up box.


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

Certainly something is required from the implementation. On the other hand 
you can implement it any way you like you are not tied to a particular way 
of doing it.


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

- double stroking (two strokes with different styles).
- stroke width or fill pattern that does not change on zoom
- "setback" for markers so that line does not overlap with the marker: 
----- * -----
there are many more, esp. in mapping


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

It would probably help you if you played a bit with any interactive SVG 
implementaton. I think some of the issues that you have come from looking 
at SVG too abstractly. Once you develop a feel for it, many things will 
just click into their places, as the features that we add do attack real 
problems that people have. If you just have a handful of elements and use 
it only to augment XHTML, I can understand your feeling that the whole spec 
is "too complex". It really is not once you start working to it.

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

I guess it would make it easier for some people if HTML group defined it, 
but I think you'd agree that they belong to *Hyper-Text* Markup Language 
even less than to SVG. Now that Web Application group is formed they will 
be handed over to it, but it will be quite a bit of time before Web 
Applicatons WG even produces the first draft. When these features were 
started to be done there was no one in W3C working on them.

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

In reality, every more or less complete SVG implementation that supports 
scripting has these functionality as extension APIs. Practically every 
SVG-based web application uses these extension APIs. The likelihood of 
these APIs ever going away gets smaller every year.


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

I can understand that it is not easy to integrate in in the existing 
Mozilla HTML code because a lot of code is HTML-centric. If you look at the 
task of implementing both HTML and SVG in the same browser it does not look 
nearly as bad. You do need some sort of framework to do even very simple 
SVG, and it is natural to have troubles with resource linking, for 
instance,  which is very common in SVG and almost non-existent in HTML. 
Once you do generic resource linking engine, it does not make all that much 
difference if you refer to a gradient or a filter - it is handled by the 
same code. (BTW, gradient referring to other gradients actually came from 
the need to use the same gradient stops (possibly changing over time) with 
many different objects).

Thank you for your comments and keep getting SVG into Mozilla!

Peter


>-- scooter
>
>John "Scooter" Morris, Ph.D.
>
>
>
>
>

Received on Wednesday, 10 November 2004 09:28:31 UTC