Inline SVG
This is a explanation of how to implement the inline SVG capabilities of the Adobe SVG Viewer (version 3).
SVG (Scalable Vector Graphics) is an XML dialect that describes vector images, sort of like Macromedia Flash. What sets it apart from that format, though, is that it is a text-based (i.e. human readable), data-driven open standard. Just like with Flash, however, you currently need to have a viewer plug-in for your browser to render it properly; you currently do not have an SVG plug-in. I'm afraid that if you want to make any sense of this page, you'll have to bite the bullet and install the latest version of Adobe's SVG plug-in:
I got the basics of this from the folks on SVG-Developers List (the best forum for SVG discussions). Specifically, I followed the example made by Max Dunn, at Silicon Publishing.
This uses a special property of ASV3 that exploits Internet Explorer's Binary Behaviors. Thus, it only works for ASV3+ with IE5+. It is a bit of a hack using quasi-namespaces (the 'xmlns' bit you'll see below --akin, as I understand it, to XML data islands, another IE technology).
Below are a few examples of 'inline' SVG images. An embedded SVG image is a separate file that is stuck into a page, just like a bitmap or JPEG, and so is not actually part of the document; an 'inline' image is one that is written directly into the HTML of the page (using XML namespaces), and is therefore part of the main document itself. The following example is the template for this very page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:iSvg='http://www.w3.org/2000/svg'>
<head>
<object id='AdobeSVG' classid='clsid:78156a80-c6a1-4bbf-8e6a-3cd390eeb4e2'>
</object>
<?import namespace='iSvg' implementation='#AdobeSVG'?>
<title>
Schepers.cc Home</title>
</head>
<body bgcolor='#ffffff'>
<div id='bannerhead' align='center'>
<h1>
<a href='/' title='Back to front page'>
<iSvg:svg id='bannerhead' width='500' height='140' >
<iSvg:g font-style='italic' font-size='100'>
<iSvg:rect x='10' y='20' width='480' height='110' rx='15' ry='15' fill='black'/>
<iSvg:text x='20' y='105' fill='yellow' stroke='red' stroke-width='2'>
Schepers
<iSvg:animateColor attributeName='fill' attributeType='CSS' from='rgb(128,0,0)' to='yellow' begin='0s' dur='4s' fill='freeze'/>
<iSvg:animateTransform attributeName='transform' attributeType='XML' type='rotate' from='-30' to='0' begin='0s' dur='2s' fill='freeze'/>
</iSvg:text>
<iSvg:text x='112' y='81' fill='yellow' stroke='red' stroke-width='2' font-family='Garamond'>
.
<iSvg:animate attributeName='x' begin='1s' dur='1.5s' from='112' to='120' fill='freeze'/>
<iSvg:animate attributeName='y' begin='1s' dur='1.5s' from='81' to='38' fill='freeze'/>
</iSvg:text>
<iSvg:text x='88' y='104' fill='yellow' stroke='red' stroke-width='2'>
c
<iSvg:tspan>
c
<iSvg:animate attributeName='x' begin='0s' dur='2.1s' from='88' to='84' fill='freeze'/>
<iSvg:animate attributeName='y' begin='0s' dur='2.1s' from='104' to='123' fill='freeze'/>
</iSvg:tspan>
</iSvg:text>
<iSvg:g>
</iSvg:svg>
</a>
</h1>
</div>
<div id='navLinks' align='center'>
<a href='lastpage.html' title='Previous'>
<iSvg:svg ID='prevLink' width='176' height='48' >
<iSvg:ellipse cx='80' cy='24' rx='76' ry='24' fill='#6699cc' stroke='none'/>
<iSvg:ellipse cx='69' cy='24' rx='62' ry='20' fill='white' stroke='none'/>
<iSvg:text x='18' y='32' fill='#6699cc' stroke='none'
font-family='Comic San Serif MS' font-size='24'>
Previous</iSvg:text>
</iSvg:svg>
</a>
<a href='nextpage.html' title='Next'>
<iSvg:svg ID='nextLink' width='176' height='48' >
<iSvg:ellipse cx='100' cy='24' rx='76' ry='24' fill='#6699cc' stroke='none'/>
<iSvg:ellipse cx='110' cy='24' rx='62' ry='20' fill='white' stroke='none'/>
<iSvg:text x='98' y='32' fill='#6699cc' stroke='none'
font-family='Comic San Serif MS' font-size='24'>
Next</iSvg:text>
</iSvg:svg>
</a>
</div>
</body>
</html>
Explanation
Allow me to explain what's going on:
- You can't really use any modern HTML DOCTYPEs (like the transitional XHTML one); this is not valid XHTML. Update: I found recently that I could use a truncated form of the DOCTYPE for transitional HTML 4.01, as long as I removed the URL; this still qualifies the markup as being quirky and non-standards-compliant, but it's better than nothing.
- Note the XML NameSpace reference in the <html> tag; I'm declaring my own pseudo-namespace called “iSvg” (for “inline SVG”, which isn't quite accurate, but there you go)... you could just as easily call it “fred”. This is what I use to resolve the scope (the NS) of the tags I use (keep going, I'll address this further).
- In the <object> tag, I'm invoking an ActiveX object called “AdobeSVG” and telling IE where to find it, by its UUID (the long number marked “classid” --this is a registry key for ASV).
- In the <?import?> tag I yoke the “iSvg” for processing by ASV3 (“AdobeSVG”).
- The <div> isn't necessary, it's just there for organization and styling (the center alignment).
- The <h1> tag is an example of what I meant by a graceful fallback... you can use CSS here, too; in case the visitor isn't using IE, or doesn't have ASV3, it will still style the text, so you don't have some inexplicable sore thumb where a slick text effect or banner should be.
- The <a> tag is obviously a link; it worth noting that this is the only placement of the anchor (that is, external to the SVG), that seems to work for linking.
- Now you just write SVG, prefacing each SVG tag with “iSvg:” --this is because IE itself doesn't know what to do with, say, an <ellipse> tag, so it would leave it blank (which is what happens in other browsers with this content); it'll pass it along to ASV, as we have instructed to do, and ASV renders it. However, browsers do know what to do with plain text (even if it's in some weird non-HTML <text> tag... it renders it. Thus, any text in an SVG block will still be shown --pretty handy... in my opinion, the fact that SVG treats text as text is one of the cooler things about it.
DISCLAIMER: This site in general --and this page in particular-- is not comprised of valid XHTML, despite my higher leanings. In order to experiment with the custom SVG namespace, I've had to use proprietary and non-standard code that most likely only works with Internet Explorer 5.5+ and the Adobe SVG Viewer; hopefully, when a true XML browser becomes available and widely used (what's stopping you, Adobe?), I can refactor this site to be compliant. In the meantime, please understand that I use the term “Inline SVG” somewhat loosely.
Limitations with Inline SVGs
There are a few things that you cannot do with inline SVGs that you can with standalone SVGs. I will list these as I find them. It is not clear if any of these limitations will be fixed in the upcoming ASV6, or even that inline SVG will be supported at all.
- You cannot zoom in or out.
- In ASV3, inline SVG will not print with the rest of the page.
- Mouse events do not register with the individual elements, but only at the root element (see below).
- Pages with inline SVG are not valid (X)HTML, and must use a partial DOCTYPE sans URL. For that matter, however, most pages that use SVG will paradoxically be invalid HTML, since the <embed> tag is far more reliable and less prone to crash than the compliant <object> tag in every broswer I know of, and so is almost universally used; this is a flaw of the browser, though, and authors can only work within the constraints of the implementations. Jim Ley recommends using an <iframe> to place SVG in a page, and while this imposes some limitations on how well interdocument communication works (that is SVG to HTML and vice versa), I find this to be pretty effective.
- Linking inline SVG directly with CSS classes; clearly, individual attribute-based style declarations work, as do property-value descriptions in a style attribute, but neither internal nor external style classes seem to be supported. Thanks to Rui Isidro for pointing this out. As I mentioned above, however, if the browser does not support inline SVG, anything contained in inline <text> elements will still render, and be styled by whatever the dominant CSS declaration indicates.
Interactive Inline SVGs
One of the most interesting things about SVG is the ability to include interactivity, though script or SVG's own Declarative Syntax (drawn from the SMIL specification). Unfortunately, for the present, inline SVGs are limited with resect to interaction; mouse events do not register with the individual elements (such as <rect> or <circle>), but only the root element (<svg>). Here is an example of onmouseover and onmouseout events on the root element changing the value of the <rect> element's corner-rounding attributes:
To illustrate this point, try clicking anywhere on the image below. The SVG root has the ID attribute 'svg_root', the circle is 'svg_circle', and the rect is 'svg_rect'. The click event spawns an alert with the value 'this.getAttribute("id")'. As you can see, no matter where you click, 'this' always refers to the root element. Targeting individual elements is possible, by using 'getElementByID', but locating the source of an event is not. This may change in later versions of the Adobe viewer.
Changing Inline SVGs with HTML Form
Here is another simple example of a work-around, using an HTML form:
Hopefully, as new generations of browsers or more sophisticated plug-ins become available, these workarounds won't be necessary. Within a year or two, I think we will see a widespread adoption of SVG and XML, allowing multiple namespaces within documents, as well as composite documents working seamlessly together.
ⓢ