logo

SVGKit

Introduction

All you need to work with SVGs at the basic, browser-independent level. Create a new SVG at runtime. Load SVG data from a URL. Conveniently handle quirks of three ways SVG can be included in browsers: object, embed, and inline. Handle different browsers and different SVG engines. Has convenience functions for DOM manipulation ala MochiKit. It manages the internal SVG DOM objects: HTMLElement, SVGDocument, SVGElement

Once you have an SVGKit object, adding content is simple. Inspired by MochiKit DOM, there is an all-caps function for every tag defined in the SVG spec.

svg.append(CIRCLE( {'cx':50, 'cy':50, 'r':20, 'fill':'purple', 'fill-opacity':.3) );

It's annoying to have external javascript files in an SVG, especially a big library like MochiKit and SVGKit, but for anything more than a simple demo, it's worth it. You can also pick which functions you want to include and paste them into your SVG.

Live Demos

Overview of Code

There is a single object SVGKit. You instantiate one for each SVG you want access too. You can use its constructor to grab an existing SVG, load an SVG from a file, or create a blank SVG to draw into. The goal of the code is to grab the svg element and be able to manipulate it independent of the browser/plugin and the technique used to include the SVG on the page. In many browsers this is just not possible for some or all methods.

Browse Code in SVN Repository

JavaScript access to SVG (not SVGKit specific, but a reference for everybody)

There are several different ways for JavaScript to access SVG content. The there are three major DOM elements you need to worry about, each of which has a corresponding member in a SVGKit object.

Here's a summary of the most common ways to get access to the all important SVGSVGElement in JavaScript. Different browsers impliment different methods to varying degrees:

htmlElement svgDocument svgElement
<svg> (inline) the svg tag
 document or svgElement.ownerDocument same as htmlElement
<embed> the embed tag htmlElement.getSVGDocument() svgDocument.rootElement or svgDocument.documentElement
<object> the object tag htmlElement.contentDocument svgDocument.rootElement or svgDocument.documentElement
<iframe> the iframe tag can never access can never access
inside svg not applicable document svgDocument.rootElement

Constructors

For <embed> or <object> -- The SVG won't necessarily be ready when the constructor returns because the document loads in the background. All real graphical manipulation has to passed to svg.whenReady(callback), which will register an onload callback to allow it to load in the background.) If you are creating a new SVG, what really happens is an <embed> or <object> tag is created referencing an svg file with no graphical content. This means you have to manage a URI to empty.svg. Another issue with<embed> or <object> is that if they get hidden (for example the div they're contained in becomes invisible) the browser will just forget about the SVG DOM and all of your hard work. I'm thinking about registering an onhide event which saves the xml and then restores it on load. The answer probably is that <embed> or <object> just suck for all of this.

For inline <svg> -- Creating a new SVG is as simple as creating a DOM element. Loading an SVG from a file is difficult because an xml loader must be used and the SVG extracted and properly recognized as SVG content so you have access to the graphical DOM methods and your content shows up. If you load an inline SVG from a file, you're going to have to register your graphical manipulation with svg.whenReady(callback) as above.

Overview of Functionality

To Do