Hear, hear!

Jeff, contact me offlist and I can give you some of my SVG eye-candy.

It seems like some Mozilla folks (with very notable exceptions) have a case
of "not invented here" (where "here" is anywhere but the W3C). In the face
of such a blatant bit of FUD, I feel I have to serve as an SVG apologist.
Stop reading here if you're not in the mood for a...

<rant>

Some criticisms of SVG that Vladimir cites: 

* "Has scene DOM (SVG DOM, though)": "Has scene DOM"? No, it hasn't. SVG has
a timeline-based animation mechanism; Flash is frame-based (which is more
like scenes). And the SVG DOM *is* the DOM, with compatible extensions that
allow for graphics-specific functions. Is he criticizing it because it uses
graphical features? I suppose that SVG should be more like Canvas, which
uses standard DOM methods like: 
  beginPath();
  moveTo(10, 90);
  lineTo(50, 10);
  lineTo(90, 90);
  lineTo(10, 90);
  stroke();

* SVG is "Somewhat hard to mix with HTML (not XHTML)" while Canvas "Behaves
like an image in both": What's hard about using SVG with HTML? I've been
doing exactly that for 6 years, and it's not hard... because it has a DOM.
Is he talking about inline SVG? If so, it's natural that SVG shouldn't work
as well as with XHTML, since HTML is not XML, and thus cannot have mixed
namespaces. But the kicker is comparing that unfactoid with the
apples-to-oranges non-DOM raster nature of canvas. Why are those on the same
line?  

* "Difficult to do data-driven rendering... Need to do DOM manipulation for
each change": First, only true with scripted changes, not declarative
animation. Second, that's the *point* of the DOM.... to reflect the current
state of the document!

* "Complex to write by hand": Unlike Canvas... which is impossible to write
by hand, since it's only an ephemeral scripted display.

* "Spec tries to cover too much": Just wait until Canvas matures... when
they try to meet a wider array of actual user needs, canvas will bloat like
a dead fish.

* "Multiple Profiles": Apparently, the intention of unifying devices of all
types around a single Web is a bad idea...

* "Tooltips? Audio/Video? Network IO??": HTML (a document description
language) has tooltips, the object tag for multiple media types, and
declarative server access (through forms). Is that a good thing...? Maybe
not, but it met user needs, and the Web would not have been as successful
without it. But, here's the question: how easy is it to get audio and video
to work reliably (or at all) across browsers, without using some proprietary
technology like Quicktime, Real, or Flash? So, even though HTML took a step
toward supporting those things in some fashion (through the flawed "object"
element), they still don't work 6 years after the HTML 4.01 Specification
came out, because they were underspecified. SVG is inherently a multimedia
language (raster, vector, and animation support were mandated from the
original charter), and video is a natural extension of that mandate; it
seems silly to leave out audio from that, doesn't it? SVG has worked to
serve as a host language for the relevant parts of SMIL (since SMIL is only
a hosted language), and these capabilities certainly make more sense in a
graphics language than a text-document format.

The case for network interfaces is less compelling, I agree... but it makes
sense in a historical context. The SVG WG realized the need for innovation
to help drive the creation of standards-based WebApps, and no other working
group was chartered to do this work. DOM had lain fallow for years; in fact,
it is only because of the initiative of the SVG WG in coordination with
other forward-thinking groups (one of my favorites, XForms, included) that
the new WebAPI working group was chartered to take up these necessary
improvements to the existing DOM. As the WebAPI group takes on the task of
such things as Cross-Domain XHR, the SVG Spec will defer to that
specification instead, as it intends to do for the Wheel event (another
long-unspecified bit of necessary Web infrastructure).

Vladimir cites an "exhaustive" 4 bullets worth of existing documentation for
SVG, leaving off svg.org and wiki.svg.org...

Without trying to sound too bitter or unfair, while I am sure he knows
canvas very well, he doesn't seem to know much about SVG.

Finally, I note that they use the "<canvas>" affectation for Canvas, which
obfuscates that it is, in fact, not XML, not DOM-based, and not intuitive or
compatible with existing Web technologies.

</rant>

Okay, now that I've defused that little bomb of a presentation, let me state
my real position on Canvas.

I think Canvas is fine. I've seen some neat stuff done in Canvas, and look
forward to seeing more. The Web is large, and I think that there is room for
a variety of approaches to solving user needs, even if they overlap a bit.
For one thing, Canvas does 3D, which SVG does only grudgingly, by design. I
don't think this has to turn into a religious war, when it could be a set of
complementary technologies. After all, they are both implemented natively in
the same set of browsers, so everybody wins.

In short, I don't see Canvas as competition to SVG.... after all, it doesn't
have a Networking IO, and what's a graphics format without a Networking IO??

Regards-
Doug
 

Jeff Schiller wrote:
| 
| http://people.mozilla.com/~vladimir/xtech2006/
| 
| About 5 slides on SVG and 14 on <canvas> (including some stuff on
| Canvas3D).  
| 
| What got me about this presentation is the slide-pack has about 8
| slides with some really cool-looking <canvas> demos:  a video game, a
| plush web-stat chart, funky animations, colourful borders, widgets. 
| And in the whole slide-pack, only one single SVG example:  a very
| crude-looking chart made from the Dojo toolkit that looks like it was
| produced by Excel 2.0.
| 
| Where's the SVG love here?
| 
| In my mind, the potential uses for SVG vastly outweighs those of
| <canvas>, yet SVG seems to be losing mindshare left and right.  Will
| there be any mindshare left for SVG when WPF arrives?  
| 
| For my own sanity, can we get a list of cool SVG demos and experiments
| that are out in the wild?  I'd like links to these demos in one
| central place (not multiple emails in a newsgroup) so we can point
| people to one URL and say: Look, here are some cool examples of what
| SVG can do.  For this reason, I've started  the "SVG Roadshow" post at
| GetSVG.com:  http://www.getsvg.com/general/announcements/svg_roadshow
| 
| Thanks,
| Jeff



------------------------ Yahoo! Groups Sponsor --------------------~--> 
You can search right from your browser? It's easy and it's free.  See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/1U_rlB/TM
--------------------------------------------------------------------~-> 

-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my 
membership"
---- 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/svg-developers/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to