Recently, a browser implementer asked me for examples of SVG. He was having trouble finding good examples of SVG in use, particularly as parts of an HTML document. This question has come up again and again, actually, and it always vexes me. I’ve been active in the SVG community for close to a decade, and I’ve seen thousands of amazing SVG files (and many more of mediocre to average quality), but somehow they seem to have disappeared or bitrotted over the years. Some of those files only worked with the slightly-unstandard Adobe SVG Viewer, or didn’t quite work with Firefox’s incomplete support, I know, but surely not all of them. Where is all the great SVG content I remember, the games and GUIs and design and development? Where are all those files to be found?

I hear some browser implementers say that people just don’t use SVG. Intuitively, this feels false to me, based on my own experience. But could it be true?

The statistical insignificance of SVG is often cited by some people in the WHATWG, based on a large dataset of Web content indexed by Google. In the WHATWG, where HTML5 started, great stock is placed on statistics, particularly those conducted by the editor, Ian Hickson, a Google employee.

There’s no question about it: HTML is the king of the Web. I did some rough calculations, similar to claims I’ve heard before, by counting the number of returns for HTML files versus SVG files. A search for the filetype “.svg” yields around 18,165,500 hits on Google. (Note that this doesn’t count the false hits on the word “SVG” from St. Vincent and the Grenadines, Stan Van Gundy, the Sexy Valley Girls, or any of the numerous other bizarrities that the acronym stands for.) SVG content makes up just 0.106% of all Web content, by my rough estimation. Flash is almost 5 times as common as SVG. That’s pretty grim for SVG.

But wait, let’s put that into perspective. Flash is about 4.8 times more common than SVG. HTML is roughly 838 times more common than SVG. 838 times. Flash content comprises approximately 0.52% of all Web content, and HTML is roughly 189 times more common than Flash. So, Flash is clearly much more popular than SVG (even when you consider that some large percentage of Flash content is actually just encapsulated video content, these days). But that doesn’t mean that nobody’s using SVG. Nearly 20 million documents is pretty impressive, actually, especially given the fact that SVG has been hindered by a lack of native support in browsers for most of its existence (and more recently, even poor support by the Adobe plugin for IE), and a lack of common authoring tools for dynamic content (Inkscape is an excellent vector editor, but it doesn’t yet do animation or interactivity).

Eighteen million documents. That’s a lot of files. So, given that, why is it so hard to find SVG content?

Maybe because the most popular search engine in the world, Google, doesn’t index SVG.

Indexing SVG

A long time ago, back in 2002, I made a page discussing my experiments with text search and translation. The results were not very encouraging, but I reckoned it was just a matter of time. I optimistically wrote to Google to encourage them to enable text search and translation of SVG files.

8 years down the line, things don’t seem to have changed much on that front.

To be fair, many SVG files don’t contain any text at all, not even a <title> element, so indexing them might not yield much. But many other files do have at least a title, and SVG infographics and webapps usually have at least labels that might be meaningful as search terms. Often SVG files are even text-heavy.

It’s not that Google doesn’t take note of the files… obviously, you can search for the filetype, or in the worst case, the specific file URL, and normally get back positive results.  But Google doesn’t seem to search the contents of the SVG files and present them in the relevant result set.  To test this, I tried searching for a few files that I knew to have indexable text content.

As an example, I looked for some SVG files on my little (long out-of-date) SVG promotion site, SVG-Whiz.com. First, I searched for a file I knew to have a cogent block of text, my explanation of the distinctions between ‘display’, ‘visibility’, and ‘opacity’, called HideShow.svg:

This file has been hosted on my site since 2003, I’ve gotten several positive comments about it, and a direct search for that file URL turns up a few hits linking to it, so it’s seems like a reasonable candidate for indexing. But what are the results of my in-site Google search for the word ‘opacity’? Okay, that just turned up the explanation page linking to the SVG file in question. Fair enough, maybe Google doesn’t treat SVG as a “document” file, only as an image. So, how about an image search for the same term? Nada. So, maybe Google doesn’t consider SVG to be either a “document” nor an “image”… let’s search for the word ‘opacity’ in the site ‘svg-whiz.com’ with the filetype ‘svg’. As specific as that is, at the time of writing, I got not a single resulting hit.

Google can find the files… why doesn’t it do something with them?

Comparison of File Extension Frequency

So, what criteria does Google use to decide which file types it is going to index?

The Google FAQ on search filetypes lists 23 file extensions that it indexes, and says:

There are 13 main file types searched by Google in addition to standard web formatted documents in HTML. The most common formats are PDF, PostScript, Microsoft Office formats [...] Google is also scouring the Web for additional file types that are very rare. You may see them pop up in your results from time to time. [...] PDF formatted files are the most popular after HTML files. PostScript and Microsoft Word files are also fairly common. The other file types are relatively uncommon by comparison.

So, I took the liberty of conducting my own survey of the relative frequency of various filetypes, as collected by Google itself, by using the “filetype:extension” query term. I’m not totally convinced this is at all an accurate means to collect and analyze the data, but it’s what I had at hand.

I put together a table that compares the different file types that Google explicitly mentions. (I thought about representing the data as an SVG barchart, but I was afraid it wouldn’t be indexed… just kidding, the sheer volume of HTML files would make every other bar just a blip.)

I also threw in some other filetypes of interest, including some with functional similarity to SVG, such as Illustrator, PhotoShop, and Silverlight. I expected non-Web filetypes such as Illustrator’s “*.ai” to be disproportionately underrepresentated in the results compared to their actual usage, and that was indeed borne out; it’s hard to know what percentage of SVG files are intended for and presented on the Web (I’ve spoken to many Inkscape users who only use SVG for print or local hard-drive, which surprised me), but I would guess that it is far, far more heavily tilted toward Web usage… but I still thought it would be interesting to compare.

What did surprise me was how “*.svg” compared to such ubiquitous file extensions as “*.txt”, and those for Excel, PowerPoint, and the venerable PostScript. To be frank, the results make me question my methodology, or perhaps the accuracy of Google’s reporting.

Caveat: I originally compiled this information a few months ago, and when rechecking it for accuracy, I got a surprising result. Normally, the Google search for filetype:svg returned 18,100,000 hits, but late one night, it returned only 2,000,000 hits; now, my most recent check showed around 4,300,000 hits. Jumping around in the results for an explanation, I noticed that there is a lot of duplication of Wikipedia content, and since Wikipedia uses SVG, that might account for some discrepancy. One possibility is that the lower figure represents 2 million unique documents, which are duplicated in a lot of places; the same should be said of any HTML content, and probably to a lesser extent of Flash content. I don’t know if this is the right conclusion, but it would be an interesting data point. Even with the much more modest figure of 2 million documents, I still think that represents an impressive body of work, particularly in light of the fact that SVG documents are normally authored individually, not through forum or blog software, or exporting or reformatting of email and text content as HTML.

Conclusions

I don’t think this is some grand conspiracy by Google to suppress SVG. Simple neglect is much more plausible. They don’t seem to see the value in indexing SVG. But the end result is the same: SVG seems to be statistically underrepresented in terms of access through Google searches, and thus, it is harder to find SVG content.

Relying on the results of a search engine that doesn’t index SVG, to draw conclusions about how many people are using SVG is not statistically sound. This is a bit like conducting a phone survey of English speakers in China, and concluding that nobody speaks with a Southern US accent. I reckon y’all might could see the problem with that methodology if you lived here in North Carolina.

SVG is at least as plentiful on the Web, by Google’s own reckoning, as most other file types that Google does index. Search engines, Google included, should index SVG files. They should read the text inside the file, and if the file is referenced in an HTML page, they should associate those keywords with the SVG file, just as they do with raster images. SVG files should display in image searches, as well. Here’s a list of the kind of useful content that can be gleaned from most SVGs:

• file name: while pretty primative, many files give some clue as to their contents in their name
• text elements: there are several elements in SVG that contain text to be rendered to the screen, including <text>, <tspan>, <textPath>, and <textArea>, and the content should be indexed as if it were text in any other format
• embedded HTML: HTML (and other markup) can be embedded inline in SVG, and search engines should look for that and index it as they would standalone HTML content
• links: Google, and probably most other modern search engines, give weight to files that are linked from other files, and files referenced from SVG content should benefit in the same way; the @xlink:title and @rel can help define the relationship between the files
• descriptive elements: like HTML, SVG has a <title> element that doesn’t display, but adds to the information about its parent file or element, and SVG also has a <desc> element for a longer description
• metadata: SVG can contain RDF, RDFa, microformats, and ARIA markup, which search engines are starting to pick up on these days; these metadata can reveala lot about a file, from its license information to structured content (like calendars or dates or contact info) to intent (such as ARIA roles, which will soon be expanded to include things like different chart types)

And the SVG Working Group would be happy to work with any search engine developers to make improvements to SVG 2 to help make indexing SVG content easier or more fruitful.

I’m not trying to pick on Google here (though I do note that a Bing search for ‘svg opacity svg-whiz.com’ listed the SVG file as the first hit), I’m just noting a discrepancy and an opportunity for improving the experience that people have on the Web with regards to SVG. At the very least, SVG should be recognized by Google as a legitimate file type, rather than a formata non grata.

Update

Rob Russell delivered great news to us in his SVG Open keynote. As of August 31, 2010, Google now indexes SVG and delivers it in some search results. Kudos to Google for stepping up! I’m very pleased… solid results only 6 weeks later. (I guess I should thank Slashdot, too.)

I was sitting at the bar with Chaals and Danny Ayers (who I’d previously only known through mutual friends and by reputation) at the Fairmont Springs at lunch. He’s an RDF guy, and I put to him the question I’d put to Harry Halpin last night (while watching Super Troopers); Harry likes the loose structure of microformats (though he acknowledges the utility of established ontolologies for constrained domains like medicine and physics), and I wondered if maybe the linguistic model of exemplars would be useful in RDF and OWL to add some flexibility.

But if formal ontologies are too rigid, I think microformats is too loose. It’s great that people are tagging their content, and useful things can be done with these tags in the short term. But microformats is not immune to language drift. Someone will see a tag, misgrok the meaning from context, and idiosyncratically misapply it to other content. This is exacerbated by the international and multi-language nature of the Web.

For example, let’s say that someone had tagged some content with the word “meme” 15 years ago; it would clearly have referred to Dawkin’s model of “idea evolution” (where a concept is spread not through accuracy, but through adaption to its mental environment… an idea akin to Colbert’s “truthiness”). But a few years ago, it spread into common use as a synonym for “fad”; so far, it retains some superficial similarity to Dawkin’s idea. In a few more years, it will probably be a very dated word (like “groovy”) and may well shift to a meaning like “old-fashioned”; it would then have completely lost its essential meaning. So, a diagram of Dawkin’s model tagged “meme” would then be misinterpreted, misindexed, and regarded with confusion by a future reader.

In the long haul, RDF provides a more time-proof solution by providing conceptual context, not just a cluster of words.

In addition to geometric shapes, SVG has advanced graphical text capabilities. In SVG 1.1, there are several elements specifically designed for the presentation of text. At the most basic level, there is the <text> element, which can have child <tspan> elements that can be positioned and styled independently of the other text content, like this:

Then there are more advanced options, like rotated text
or the <textPath> element

The future of SVG text support holds still more. In the next version of the SVG specification, SVG Tiny 1.2, there are even more useful text features, like the <textArea> element that automatically wraps text to a shape (rectangles on for mobile devices, but any shape at all in future versions of the specification). There is also the new ability to make any text editable by simply including an attribute to the text element. And there are great features from SVG 1.1 (the current version) that are not yet widely implemented, such as SVG Fonts, which let you embed a font into an SVG file so the reader sees the page the way the author intended it, and the <tref> element that lets you directly quote text without duplicating it. All these features will give more control to authors and give a better experience to users.

But is that enough?

The Study of Meaning

Semantics is the study of meaning; a cluster of dots in the shape of a word doesn’t mean anything to a machine, but real words and sentences can be connected to concepts, and that is why this is important in a graphical format like SVG. All of these text features really are text, not just images of text. They can be searched for, copied, indexed by search engines, and understood by screen readers. Screen readers are a kind of assistive technology that reads pages out loud for people with vision problems. It’s not just for people; machines like it, too. It has semantic value, and this moves us toward the Semantic Web. There is also the <switch> element, which is an excellent way to provide different text content, such as your own translations, depending on the user’s computer systemLanguage. Obviously, this adds meaning by disambiguating different possible translations that a computer-based translation might not catch (because people are smart, and computers are merely fast). And it’s not just the visible text that provides meaning, but also the metadata (or “data about data”). SVG’s <title>, <desc>, <metadata> elements are not rendered onto the screen (although the Opera browser does provide a tooltip for the title text), but can be indexed by search engines, and the use of script or special browser capabilites (such as native browser support for RDF, a special kind of markup that describes the relationship between terms used in the metadata) can provide extended functionality. As you might expect, the <title> and <desc> elements are meant to be human-readable, while <metadata> elements more frequently contain computer code.

A Semantic Argument

But in a recent post to SVG-Dev, a representative from Adobe pointed out some possible shortcomings of SVG’s text capabilities compared to HTML or PDF. Adobe is using SVG in its new Mars project, which is an XML version of their popular printable document format. Now, I don’t find HTML to have very much semantic content either (see this very long post on semantics from a couple of years ago), but Adobe’s Leonard Rosenthol points out that computers (specifically screen readers) can’t distinguish between paragraphs and columns of text, and particularly not tabular content (where each cell in a table has a context in both a row and a column). I don’t think that paragraphs or columns are particularly semantic (and certainly aren’t universal even among written languages). They are largely cosmetic print conventions, and although of course that matters for printed formats, it’s not as important for accessibility or spoken-word understanding, nor for machine understanding; although admittedly paragraphs do represent some structure (I’m having flashbacks to composition class in high school here), most often columns are simply a convenience of text flow within a constrained area and carry no distinction from one another, and where they do, it is typically simple tabular data. Tables are another matter, though, because of the specific associations involved in cell position. There are other semantic orthographic properties of documents that matter more than print conventions, and which have sometimes been passed off as merely stylistic, such as emphatic text (represented by boldface, italics, or relative font sizes) that is indicated by tone in spoken language.Acronyms, abbreviations, definitions, and quotations all have HTML representations (although they are too rarely used), and there is no equivalent of those tags in SVG (by design); but that meaning is limited to a specific knowledge domain, that of generic textual reference. There are other specific domains that have highly structured tagsets just dripping with meaning, like Chemical Markup Language (CML), Linguistics Markup Language (LGML), Music Markup Language (MML), MicroArray and Gene Expression (MAGE — contrasted with the almost inevitable Bible Markup Language)… mapping, geography, mathematics, psychology, literature, sociology, physics, architecture… every area of human endeavor has a systematic structure that is (or will soon be) encoded in some kind of tagging scheme, whether that be in the form of XML, RDF, or some other format. But these semantics are largely lost on the Web.

SVG has taken pains to avoid including specific semantics in the specification, in order to remain a neutral presenatation format. The only semantics are derived from the graphical geometry, which nevertheless can be extended to related domains like mapping and geography (and possibly feng shui). But it would be ideal if the underlying structure carried all the rich semantics of the graphical data being presented, if a circle were identified as an atom, or a rectangle were a flowchart box, if your computer knew what we know when we look at something, or even explaining it to us when we don’t know what we’re looking at. These are true problems that need a solution. How can we add semantic properties to SVG, to the Web in general?

Technical Solutions

RDF

I’ve already mentioned RDF. This is one way to add extra information to the geometric presentation. Let’s use molecules as an example (see source):

The code would look something like this… I say something like this because A) this is only a snippet and B) I’m no RDF guru and I’m sure I got something wrong:

<svg>
<line x1='840' y1='170' x2='600' y2='170'>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="http://www.example.org/bond">
<m:atom_link rdf:resource="http://www.example.org/carbon-oxygen" />
</rdf:Description>
</rdf:RDF>
</metadata>
</line>

<g fill='gray'>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="http://www.example.org/carbon">
<m:bonds_to>
<m:oxgen rdf:about="http://www.example.org/oxgen" />
</m:bonds_to>
</rdf:Description>
</rdf:RDF>
</metadata>
<circle cx='400' cy='170' r='20'/>
<circle cx='400' cy='230' r='20'/>
<circle cx='600' cy='170' r='20'/>
<circle cx='600' cy='230' r='20'/>
<circle cx='500' cy='200' r='100' fill='url(#carbon_fill)'/>
</g>
</svg>

The <metadata> element as a child element is obviously associated with its parent, thus “tagging” it. There is no established method for placing the <metadata> element to best associate collections of elements, but setting it as a child of a <g> (group) element containing all the relevant children seems a likely choice. This allows us to say that circle is a carbon atom, and that line is a molecular bond. On the downside, RDF is a bit verbose, and it isn’t ideal to tag text.

Text content in RDF (or any given XML format) is not visible. This is because SVG dictates that content inside unknown elements (that is, elements not defined in the SVG specification) is not rendered, even if it is also the child of a <text> element.

Microformats

Microformats may be a good option here. While most people associate the class attribute with CSS styling, both the HTML and SVG specifications list one of its roles as “general purpose processing by user agents.” I haven’t seen any microformats user agents (browsers or other programs) that specifically support SVG, but it shouldn’t be hard. The basic syntax and functionality would be the same. Basically, you might say something like <text class=”acronym”>SVG<title>St. Vincent and the Grenadines</title></text>.

A minor problem with this is that SVG Tiny 1.1 doesn’t have the class attribute, but this should work fine with SVG Full, and SVG Tiny 1.2 does include the class attribute specifically for uses other than styling (e.g. micoformats). A potential negative with microformats itself is that since it is such a loose ontology, I’m not sure it will scale up to complex contexts, and I think that it will be subject to the same semantic drift that natural languages suffer (where one word takes on a new meaning, like “decimate”); in fact, since there will be no immediate feedback, as is present in spoken language, I think the drift will be accellerated. This makes for stale semantics down the line, but it will probably suffice for the short term (and who knows how long the content will last anyway?).

XBL2

Finally, there is a new technology being published by the W3C, one originating with Mozilla, called the eXtensible Binding Language (XBL2). Among other things, it allows an author to create templates that attach a presentation format, like HTML or SVG, to any arbitrary XML. So you could take your Chemical Markup, or Genealogy Markup, or whatever, and create XBL SVG templates for it. Whenever there is a element that matches one of your templates, the appropriate SVG (or whatever) markup is created and tied to the target element, preserving the original semantics while providing an appropriate visualization. Since this is a new technology, the obvious drawback to this approach is that there aren’t yet browsers that support it. Also, it may not be appropriate for mobile devices. But I think this will be the rich option available within the next couple of years.

Conclusions

SVG has inherent accessibility features, and specific built-in geometric semantics. With a little work, semantically rich documents and applications can be built using SVG in combination with the appropriate ontology and a semantic tagging mechanism.