[dojo-contributors] SVG/VML/Canvas API discussion

Tom Trenka ttrenka at gmail.com
Mon Apr 17 11:46:05 EDT 2006


Hi all,

Since the Iterator discussion went *so* well (<sarcasm/> but not
really), I figure it's time to start asking questions about an
SVG/VML/Canvas library, since it would seem that some think this would be a
very useful thing.  So let me kick off the discussion (since I'll probably
write it)...

The nominal purpose of an SVG+VML+Canvas library would be to add a single
layer of abstraction over the two vector (and one bitmap) drawing languages
so that a developer can write one set of code, and have it render properly
on the major browser platforms.  However, I have some issues with this, so
let me lay this out first before diving into a request for purpose+proposal.

1.  My personal feeling is that widgets (one of the core uses for something
like this) should not be limited to an encompassing API for drawing, and
that there's no real difference (aside from platform) between writing markup
in VML and SVG and writing markup in HTML.  All three are valid, existing
markup languages; to force an API over two of these languages would be a
detriment to the system.

Note the use of the term "force".  I'm not suggesting the API isn't needed,
just that we shouldn't force things to rely on it that we release ourselves.

2.  In the same vein, we shouldn't ignore the need for core files in the
same vein as style.js and html.js for the other markup languages.  svg.js is
already a part of the library (even though a good portion of the
functionality in that file is stub functionality that isn't working yet).  I
might expect there to be a vml.js at some point as well; I will certainly
add it when I get a better sense of what kind of helper functions are needed
(particularly when we finally address DnD with vector markup).
---
All of which to say is that I'd like it to be clear that any vector API
could (and probably will) rely on some core files but it should not be the
other way around.

Now that that disclaimer is out of the way...what do we think we want out of
such an API?  What kind of opinions are there as to the shape of such an
API?  What does Dojo really need in these terms?

I'll put forth a suggestion, and then let's discuss:  I would say that we
would start with a script-based API, modeled on the Canvas API, upon which
we could write general purpose widgets to represent drawing primitives (and
eventually more complex ones).  Before anyone objects, let me try to be
clear:  when I say "modeled" on the Canvas API, I'm referring to methods and
the general results of those methods.  The Canvas API is based on OpenGL,
which makes sense from a scripting standpoint; I don't see any reason why we
shouldn't use the same approach.

I know one of the things Alex has asked me for is that any primitive drawn
be able to fire and respond to events.  Not sure how we'll pull that off
with actual Canvas drawings, but I'll cross that bridge when we get to it
(probably it will involve looking for a mouse click on the canvas element
itself--if that's supported--and then analyzing the current rendering to see
what the top most element is that one clicked on, what fun).  What other
things would you want out of such an API?

trt

(for the record, I will certainly be looking at the Google ExplorerCanvas
code but I'm pretty sure we won't incorporate it because of
licensing...unless, Alex, you want to take a close look at it and see?  My
inclination is to learn from it but not use it, just to be safe, plus I'd
hate for Dojo to be reliant on other projects--since it seems like one of
the goals here is to be the other way around).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060417/f985ba6e/attachment.htm 


More information about the dojo-contributors mailing list