Throws off javascript frameworks that wrap HTML DOM elements
Tendency to use "getAttribute" and "setAttribute" instead (or at least ignore unitType)
And creation needs to be done by the correct DOM constructors or createElementNS() - no .innerHTML shortcuts
XML pedantry (namespaces)
Comparison to Canvas (pt1)
What about HTML5 and Canvas?
Canvas is a writable bitmap buffer (cf ImageMagick drawing to a PNG)
Canvas is procedural only, SVG is a declarative form (scripts change the declaration)
Canvas addresses entire canvas (doh!), SVG addresses collections of objects drawn on the canvas
Canvas doesn't provide structures of addressable objects or compound structuring logic
As you add more items, SVG slows down (DOM growth and overlap of items) but Canvas tends to stay fast (bitmap buffer)
But then if you want to move/change/replace existing items, SVG can do this, Canvas you have to rerender the lot
Similarly resize of canvas area or other transformations
Or "add new item beneath others" (esp with transparency)
Canvas can be quicker, but it depends how many operations such as redraw,
viewport clippping, scaling etc you want to do (in Javascript) as opposed to
SVG having it built-in in native code (much quicker if the tasks match)
Browser event loop means that with SVG you don't know when the redraw occurs and how long it takes (is Canvas drawing synchronous??)
Text support added to Canvas but not as rich as SVG
No CSS support or DOM (including event handling and routing per DOM item)
Canvas can be overlaid but no filters over existing content (filters over HTML5 video etc)
Foreign object support for HTML in SVG (although not in IE9 yet)
Both predominantly 2D, but people do 3D stuff on top (no h/w acceleration of course)
Comparison to canvas (pt2)
What does SVG do for you over and above canvas
SVG gives you "for free" much of what you have to code yourself in Canvas
Features written in browser-specific native code rather than slower javascript
Can integrate with the rest of your DOM work (ie works like you modify the HTML DOM)
But the constructs are generalised and may be too slow
You may end up with a lot of DOM compared to what you're doing
If you're fighting the DOM, or the redraw loop, or events, consider going to Canvas
If you're using Canvas and find yourself writing redraw loops, hit detection logic, sprite libraries etc, consider SVG
Example of "point hits line" calculations vs canvas/svg techniques (next slide)
Scriptable objects (no need to build your own objects for everything)
Events including hit testing of visuals (stroke and fill)
Redraw loop including "dirty" calculations
Clipping etc
Arbitrary transformations
Serialisable form
CSS
Text support (now in Canvas but richer in SVG if needed)
What you don't get
full control of redraw scope and timing (eg memoising specific layers)
single shot cost of complex one-off rendering (backgrounds etc)
Techniques
Some tricks of doing basic stuff in Canvas and SVG
Hit testing
SVG: Use builtin event routing with pointer-events to get/avoid hits on border and fill
Canvas: Draw a 2nd canvas that you don't show, encode the object ID in the colour, then read the pixels from this hidden canvas
Fuzzy hit testing
SVG: Use invisible backing items with opacity='0' pointer-events='all'
Canvas: As above but draw them bigger on the hidden canvas
Layering and bring-to-front
SVG: Implicit DOM ordering, use appendChild to move an item to the end of its parent
Canvas: Change your redraw order
Use CSS for animating reveal of control items
SVG: Control surface sub-widgets with 'display:none' but a CSS hover rule on the parent to make them visible
Don't be afraid to overlay HTML with absolute positioning
Rich tooltips with markup, hover-cards with HTML controls, in-place edit etc
Good bits
What features make life easy
Composition of compound elements (defs; symbol and use; groups; image; svg fragments)
Built in animation (if that's what you need)
CSS including "CSS animation" (hover effects)
Implicit z-layer based on DOM order (no explicit control)
Rich set of primitives
Viewport defining fragments with svg tag
Arbitrary chainable transformations
Interaction support with items / sprites
Control over pointer events per structure
Inherent support for beziers, gradients, filters etc
Memory use seems broadly quite good (anecdotal)
Static performance speed is excellent
Bad bits or missing bits
What should I be careful of
<symbol> and <use> too concrete (no parameterisation)
Control over "ghost" tree for <use> not widely supported
Keyboard and focus support (not an InputElement - focus determined by selecting <text>)
Performance as number of DOM changes increases (but improving)
No 'export to PNG' or similar (cf toDataURL() of canvas)
No image introspection (getPixel()) so you can't examine clipping results
Not as "new" as Canvas and so not so trendy (HTML5 buzz)
Hard/ugly bits
What will be frustrating
Values can be awkward (eg need for expressing units on lengths, esp in CSS)
Built in animation makes scripting wordy (".baseVal.value" etc)
Embedding in HTML had a history of being hit-and-miss (but getting better)
Text support superb except all markup has to be done by hand
getBBox() doesn't return valid results until after items are rendered
Native support within Javascript frameworks lacking
Patchy support for foreignObject extensibility
Complexity: when you're mixing declarative mods, viewports, transformation chains, animation,
scripting, CSS cascades, shims for your DOM wrappers etc etc, then pinning down what's wrong
can be hard (Chrome helps)