Re: SVG 1.2 Comments

Dean Jackson wrote:

> Hi Scooter (brought back memories of the Muppet show!)
>
Yup!  Although my nickname predates the Muppets and comes more from the 
early Yankees (or so I'm told).

>
> 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'll try to, but like many people, its really hard to keep up with the 
specifications coming out.  I haven't commented on the SVG 1.2 
specification until now basically because it took a deadline to force me 
to "speak now or forever...".  

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

And I honestly doubt he expected that to happen.  I think he was merely 
trying
to set the stage for his more thoughtful (and detailed!) comments.

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

I think that this may be one of the problems that I have reading the spec.
The absense of any scenarios or explicit use cases (even as a companion,
non-normative document) would help me understand the WGs positions.
I look at all of the extra elements for vector effects, and while some 
descriptions
are coming out in the dialog about what uses they were intended to meet, to
me as an author they look like more complexity.  If, on the other hand, 
I understood
the use cases better, and why SVG 1.1 doesn't meet them, I would get a 
better
picture.   One of the implementation challenges we've been facing in the 
Mozilla
SVG work is that there are relatively few examples for many (most?) of 
the features,
and so we wind up spending a lot of time trying to figure out what was 
intended.
Of course, this takes away from time spent implementing.

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

Understood.  The problem is that Opera is a small company, and Mozilla 
is made up
of volunteers, and membership on the WG is a high resource activity.  I 
fully appreciate
the "Catch-22" that this puts us all in, but here we are.  How can  we 
devise ways to
work more closely, recognizing that Mozilla is not what the W3C had in 
mind when they
set up their organization.

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

I agree with this comment, but I think we need to figure out better how 
to do it.
We (all three or four of us) are committed to implementing SVG in 
Mozilla/Firefox,
and getting it enabled for broad deployment.  Its just not possible for 
any of us
to commit the time to WG membership at this point.

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

Which I applaud them for.

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

SVG Full seems pretty difficult to implement in a cross-platform, 
existing desktop browser.
Maybe tighter collaboration on feature/implementation cost trade-offs 
would be good.  Ian's
comments about CSS 2.1 and the breadth of the test suites are relevant 
here also.  As I mentioned
before, a fair amount of time is taken to figure out how things are 
supposed to work, when a
better test suite (that doesn't use <embed>, please) would give us a 
great deal of guidance.

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

I understand that Adobe is including XHTML support within the ASV
plug-in, and that they plan on including SVG support in many of their
product.  This is great news!  However, that doesn't detract from my
comment.  At this point, Adobe is not, nor do they consider themselves,
a browser vendor.  I think their vision is that ASV is an important tool
to allow them to sell SVG-enabled tools, much as the Acrobat Reader
is critical to their overall Acrobat market.

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

But you have segregated them.  The WG has defined a separate profile to
specifically meet their needs, including the statement that CSS might not
be present.  If there is one web (which is a sentiment that I agree 
with), don't
you think that (X)HTML and CSS are part of it?  How much of the one
web gets cut off if I only have an SVG UA without strong XHTML and
CSS support?  Not trying to be antagonistic (honest), merely trying to
understand the position that has led to certain approaches by the 
working group.

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