Re: SVG 1.2 Comments

Chris Lilley wrote:

>On Wednesday, November 10, 2004, 7:28:01 AM, Scooter wrote:
>
>
>SM> Here are some comments that I have been working on in response to
>SM> the SVG 1.2 last call. I've been really trying to read all of the
>SM> comments and discussion in www-svg, and I frankly have been less and
>SM> less comfortable about adding my comments to the mix.
>
>Its unfortunate that you, and perhaps others, are discouraged from
>making last call comments by the rather combative attitude of a few
>people who chose to use last call as a way to either get the SVG WG shut
>down,or at least mired in process and unable to progress.
>  
>

Chris, while I've already given my opinion on Ian's initial vent, I 
don't think
its fair to state that the tone is completely attributable to "a few 
people", nor
that there is a conspiracy against the working group.  The tone has, in my
"outsiders" view cut both ways, from extremely agressive on one side, to
extremely defensive on the other.  There's plenty of feathers flying, 
and they're
coming from both chicken coops (wow, isn't /that/ an ugly metaphor! :-) )

>I thank you for getting past that and sending in your comments anyway.
>
>  
>
Your welcome, and I appreciate your reponses.

>On the contrary, that is one of the target audiences of the
>specification. You should also check out the recently launched Compound
>Document Formats (CDF) working group, which is even more relevant to the
>mixture of SVG with (X)HTML by reference and by inclusion.
>  
>
I've been pointed to this several times, now.  I will certainly try to 
look at it.

>I appreciate that the rather hostile atmosphere caused by Hixie's attack
>has made genuine progress more difficult, but I for one am trying to
>separate out the genuine technical comments (such as yours) from
>flamebaiting and trolling.
>  
>
See my comment above.  Frankly, after reading through Ian's more thoughtful,
second response (post-vent), mine are comparatively uninformed.  He has done
a much more complete review of the specification that I had, and I am an
implementor (well, in my "spare" time...).  I think that the problem is 
that many of
us have waited until there was a perceived deadline to make comments on 
the spec.
In my own case, I can only plead that contributing SVG code to Mozilla 
is not my
"day job" and it took a deadline for me to carve out the time.

>SM> who have a very strong need for SVG+MathML+XHTML+Javascript in a
>SM> browser that scientists are willing to use every day. Note, this is
>SM> not an accusation, this is a perception.
>
>Its an accurate one. The market is clearly there. We live in a
>technological society - the number of people in the scientific,
>engineering, technical, financial etc sectors who could use
>multinamespace documents with graphics, mathematics, and text is
>substantial.
>
>  
>
Agreed.  My users would love to see this!

>That's right. Typically there is some discussion, if the point the
>commentor makes is not clear, or further information is required, etc.
>The focus of such discussion is on clarifying the comment, pointing out
>areas of the spec that might satisfy the request, etc.
>  
>
Good, that all makes sense.

>The lengthy and somewhat heated discussions here are atypical, both for
>W3C ad a whole and for SVG in general. Naturally, if someone uses Last
>call to lodge a comment that SVG should be abandoned, W3C shut down,
>things like that, there will be reaction and angry discussion, which is
>not helpful. I am reminded of an old nettiqutte maxim, "don't feed the
>trolls".
>  
>
In the spirit of letting things calm down, I'm just going to let this 
slide....

>The formal responses come in a disposition of comments document, showing
>each last call issue raised, how it was handled, etc. None of the
>responses from various working group members here count as that formal
>response.
>  
>
Great!

>Some of them are valid concerns, I agree. Some are not. Some of the heat
>has come from trying to tell the difference.
>  
>
Hmmm...  Well, I understand that that might be true from your 
perspective.  Ian, and
others, are raising concerns and comments that map pretty closely to the 
frustrations
that we see as part of the Mozilla SVG team (all four of us). 

>SM> I guess I'm also very confused by the positioning of the working
>SM> group. It seemed to me that working with Opera, Mozilla, and Apple
>SM> to implement SVG would be very important to the working group, as it
>SM> would certainly have a significant impact on the use of SVG as part
>SM> of general web content.
>
>It would be, if they were interested in implementing. I have been asking
>senior Opera employees, for example, to implement SVG for many years
>now. The response has always been along the lines of 'not now' or 'too
>hard'; perhaps because the focus has moved away from W3C standards and
>more towards replicating a Win/IE clone experience on other platforms.
>  
>
OK, but Mozilla /is/ interested in implementing, and we're trying (honest).

>The success of mobile implementors like Zoomon, Bitflash, KDDI,
>Macromedia and Nokia has shown that it is entirely possible to implement
>SVG on a mobile platform with highly constrained processor, memory,
>etc;its more a case of seeing a business opportunity and wanting to do
>it, frankly. I have said in the past thatthere are two ways to approach
>writing a web user agent; one is to implement a bunch of W3C specs, and
>one is to reverse engineer every strange quirk and foible and outright
>bizarre mangling that current legacy user agents implement and that
>legacy content depends on. Its very difficult to do both. So to some
>extent what you see here is a clash of cultures, legacy broken HTL world
>vs modern, standards-based, XML-focussed world.
>  
>
Agreed, but as much as I really try to use standards in all of my web 
development
work (XHTML, CSS, etc.) at the end of the day, there is still the 94% 
guerrilla, and
some of my users still use IE.

>Moilla shows that it is possible to implement to both worlds, at the
>expense of multiple codepaths; having a MathML implementation and an SVG
>implementation, for example. As you say, that presents a very compelling
>user agent for the substantial scientific, engineering, and
>economics/finance markets. But it still takes effort and it depends on
>how many people are working on which codepath; and also how easy it is
>for people to submit code, get it checked, and have it added to the
>codebase. People are very interested in seeing SVG in Mozilla, although
>if their code is rejected or blocked they may loose interest after a
>while. its a case of nurturing those developers that want to help.
>  
>
Send them our way -- we'll "nuture".  The problem is that resources are 
limited.  It
is absolutely true that there is a backlog of reviews and superreviews 
for SVG code.
If you look at the gradient additions, its an absolute horror.  But, its 
not because of
r/sr backlog, its because of the learning curve that I had to go 
through.  The r/sr is
a critical part of the learning curve and the meritocracy that makes up 
Mozilla.  I
/will/ continue to complain about patches that sit in the queue, but 
that is part of the
process, just like people continually complain about how long standards 
take.

>SM> It is my perception, however (don't shoot me, I recognize the
>SM> difference between perception and fact) that the SVG working group
>SM> isn't really that interested in whether Mozilla, or Opera, or Apple,
>SM> or even Microsoft implements SVG or not.
>
>Not at all. Although, after asking and trying to get the desktop HTML
>browsers to do this for so many years, its certainly fresh and
>encouraging to see SVG get implemented from scratch in a fairly brief
>interval in the mobile phone space, and start showing up on dealers
>shelves. There is faster turnover in that space - people get a new phone
>every 18 months, so the 'how to get joe public to download a newer
>browser or change to a better one' is somewhat solved there. In
>addition, there is not the mass of legacy content there that binds them
>to an older browser.
>  
>
Which leads to my comments about an SVG 1.2 Web...

>SM> My perception is that the working group is working very hard to
>SM> court the manufacturers of cell phones and other mobile devices,
>SM> which is why they have defined SVG 1.2 Mobile.
>
>Yes. There is a focus on that market and it is helping get adoption
>there.
>
>SM> Why is there not an SVG 1.2 Web?
>
>On the desktop, because the legacy HTML browsers were not interested in
>adding the newer XML based specifications - SMIL, MathML, SVG  - into
>their fragile rendering layers. New XML based stuff could go  in that
>did not affect rendering, such as P3P as an obvious example.
>  
>
OK, but we /are/ interested, and active.  So, I guess that Mozilla can 
take the high
ground and say that because we are doing all of that, and (by your 
estimate) we
(and I in no way speak for mozilla.org, or even the SVG team) are the 
only legacy
HTML browser that is, it would really help us to define an SVG 1.2 Web that
was focused on a simplified implementation path and authoring experience 
in a
"general web" domain.

>SM> Is this audience not of at least equal importance?
>
>Yes. And eventually, as the amount of modern standards based content
>increases because of mobile use, the desktop folks are going to want to
>see it too. At the moment there is a bit of a chicken and egg situation
>- not so much content, so no pressure to upgrade, so not much content,
>as the amount of deployed user agents  that can view it is below
>critical mass.
>  
>
Agreed, which is why I got involved with the Mozilla SVG project.  SVG 
solves a
problem for my users, but we need a solid user agent to take advantage 
of it.

>SM>  Given the lack of a profile for mixed-namespace web
>SM> browsers,
>
>http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/
>  
>
Sorry, I should have been more specific -- an SVG profile.

>SM>  I can certainly understand the perception of many of my 
>SM> colleagues that SVG is "not meant for use on the web", but for use 
>SM> "within embedded devices".  Is this true?
>
>No, its not true. Its meant for use on the Web, clearly. There has just
>been resistance from some legacy user agents to adding it. Mozilla is a
>classic case where that is not true, although there have been setbacks
>in terms of getting code on the trunk, getting it enabled, having to
>switch backend renderer because of licensing issues, etc. Meanwhile the
>regular progress in SVG-enabled builds has been gratifying to see.
>  
>
Glad to hear it!  There are some people working really hard on this 
stuff, of which I
am one of the least productive.

>Amaya was another attempt, at W3C, to show how XHTML and MathML and SVG
>could usefully be integrated together.
>  
>
In my early attempts at the gradient code, I used amaya to get an idea 
of how things
should look.  What it told me was that gradients must be really hard, 
cause all I got
was a black box....

>The decision to not do any SVG 1.2 in Mozilla is also disappointing,
>since Mozilla will not be able to help SVG 1.2 get through CR. Although,
>its not clear if that is a decision of the Mozilla foundation or just
>the policy of a couple of people' I hope that latter and that wiser
>voices will prevail. A bit of conditional compilation could easily make
>"1.2' and '1.1' builds available and many in the SVG developer community
>would I suspect be interested in helping to implement there.
>  
>
I don't know about any decisions of 1.1 vs. 1.2.  I am very aware that 
we are working
hard on 1.1, and are a long ways from having a very complete implementation.
I can't imagine thinking about 1.2 at this point, because the list of 
1.1 features yet
to be implemented/cleaned up is so long.

>If implementors start with an SVG-only codebase and start extending out
>to XHTML, that seems at least as valid as starting with (X)HTML and
>expanding out to SVG. In some ways easier, because instead of 'DOM 0'
>etc there is a DOM 2 codebase to build on.
>  
>
I wasn't commenting on the validity of Adobe's efforts, nor their 
approach.  Merely
their statement that something was "easy' because they had done it.  
Their experiences
don't equate to mine.

>SM> was relatively straightforward only serves to minimize the
>SM> complexities of implementing a specification like SVG into an
>SM> existing large, cross-platform code base.
>
>I agree that integrating any rendering component into an existing and
>large codebase is hard, depending on how well modularised and extensible
>that base is, whether it is already using XMLparsing and an XML DOM and
>is namespace aware, etc.
>
>SM> Again, I may be missing something, here, and if I'm really way off
>SM> base, let me know. I am honestly confused.
>
>No, you are not far off base. Its unfortunate that some of the fighting
>here has soured things somewhat. Hopefully we can put that down to a few
>misguided individuals, and move on.
>  
>
How about we just move on?  I think that putting anything down to 
individuals,
misguided or not, is counter-productive at this stage.   As an 
implementor who is
participating (in a small way) in the Mozilla SVG implementation, I am 
concerned
about the complexity of the SVG 1.2 specification w.r.t. my uses, and my 
implementation
tasks.  SVG 1.1 has a great deal to offer for my purposes as an author.  
SVG 1.2 adds
lots of features, but they seem to be for use cases that don't map well 
to my own, I think.
I could be really wrong on that, however, its hard to tell because the 
use cases and more
complete examples aren't available at this stage (at least to me).

>SM> End of meta comments...
>
>I'm going to close my comments there and respond to the technical
>comments in a separate email.
>
>  
>
Great!  Thanks for the responses.

-- scooter