W3C home > Mailing lists > Public > www-archive@w3.org > November 2004

Re: SVG 1.2 Comment: Detailed last call comments (all chapters)

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 5 Nov 2004 13:57:03 +0000 (UTC)
To: Antoine Quint <ml@graougraou.com>
Cc: www-archive@w3.org
Message-ID: <Pine.LNX.4.61.0411051321110.8631@dhalsim.dreamhost.com>

On Fri, 5 Nov 2004, Antoine Quint wrote:
> > 
> > [Taken off www-svg since JonF requested that I not send non-SVG-related
> > content to the www-svg list. cc'ing www-archive instead.]
> Let's just say that you might not make as much of a fool of yourself on this
> list where no one is aware this thread continues. Well done.

It should be quite clear by now that I have no worries about looking like 
a fool. If you want to forward my message (or this one) to www-svg, feel 
free to do so. Jon asked me not to, I'm acquiescing to his request.

> > > Can you elaborate on how <canvas> makes dynamic graphics generation 
> > > easier with a concrete example?
> That's just code, not a detailed analysis about how <canvas> is a fitter 
> contribution to web development than SVG for the creation of "dynamic 
> stock graphs, maps, and the like".

My apologies, I thought by "concrete example" you meant "code". What did 
you mean by "concrete example"?

If you want "a detailed analysis about how <canvas> is a fitter 
contribution to web development than SVG for the creation of "dynamic 
stock graphs, maps, and the like"", then you are asking the wrong person, 
since I never said that it was.

I did say that "dynamic stock graphs are easiest done with something like 
Apple's <canvas>". I think that is true, because updating path data in an 
SVG fragment is harder than simply plotting a new line using the canvas 
APIs. I may be mistaken.

A better example of something that <canvas> makes easier is things like 
games (things like Doom, platform games, etc). When you need fast frame 
rates, where you really don't need a DOM, where objects will be created 
and dropped at a moment's notice, where bitmap sprites are to be thrown 
around like there's no tomorrow, etc.

But I never said that <canvas> was better than SVG. I didn't even compare 
them. I don't think they are competing technologies. I'm recommending that 
Web browsers implement both <canvas> (and the rest of Web Apps, once it's 
ready) and SVG 1.1.

> > Say you wanted to draw a circle around a point on a photograph, as 
> > part of a Web page. Radius 10px, two pixel black stroke, no fill. In 
> > the examples below I've omitted the fallback content in both versions, 
> > in order to concentrate on the differences.
> You sure didn't ignore the pedantic programming style to make sure your 
> comparison was well-biased.

I used the SVG DOM, on the assumption that it was designed to be better 
than the Core DOM (otherwise, what's the point in having it).

> First, strip off the <html> that you don't need in that case, and the 
> stylesheet since we don't need it anymore (you can't position a circle 
> using CSS in SVG).

The context of this was a a photograph in an HTML document. So you need 
the <html> there, and you need the stylesheet to position the <svg> 
element itself.

If you drop <html> and the stylesheet, you might as well drop it in the 
<canvas> case too, and use <canvas> as the root element. It makes about as 
much sense.

> Code length doesn't have anything to do with code complexity by the way. 
> I trimmed down DOM calls to a minimum here, but if you wanted to do it 
> in a more verbose and possibly clearer way (using a separate 
> setAttributeNS() call for each attribute) then complexity remains the 
> same as it's only one method reused all over again.

Your example still looks more confusing than the <canvas> equivalent, to 
me. But I guess it's a matter of personal preference.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 5 November 2004 13:57:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:38 UTC