Reinventing Fire

Korzybski remarked that “the map is not the territory”, reminding us that we shouldn’t confuse our mental models for reality. But maps, and data visualizations of all kinds, are really powerful, conveying complex ideas easily, and even shaping (or misshaping) perceptions about facts. This is one reason why decentralization of mapping resources and services is good; no one organization should control our common maps.

SVG is a natural fit for mapping. There’s even a detailed proposal by KDDI’s Satoru Takagi-sensei for tiling, layering, and coordinate resolution that fits on top of SVG, which I’d like to see standardized.

I’ve had an idea for a small open-source project for a while, which I’ve discussed with the brilliant Andreas Neumann of Carto.net; he’s been too busy planning SVG Open every year to help out with it thus far, and I don’t have the skills to do it without a great investment in time.
Read the rest of this entry »

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?

Read the rest of this entry »

Since I was Down Under for the annual SVG Sydney F2F anyway, I made plans to meet with some key players in the Annodex Foundation. They are doing some amazing stuff with video on the Web, far ahead of anything I’ve seen elsewhere. I first met Silvia Pfeiffer at the W3C Video on the Web Workshop a couple of months ago. She threw a small barbecue on Saturday, and we met again for dinner and drinks at Coogee Beach on Sunday evening, this time my my friend Andrew Shellshear, who I stayed with over the weekend and who is doing some neat stuff with video himself.

We talked about true video hyperlinking, media metadata and searching and APIs and the Semantic Web and accessibility, proxies and caching and bandwidth, codecs, uploading and streaming, and sundry other things regarding video as a first-class citizen of the Web. This is a hot area to watch for Web standards, because it needs to be done right, and it needs to be open.

Dramatis Personae

• Doug Schepers (a Montague)
• Anne van Kestern (a Capulet)
• Simon Pieters (a Capulet)
• Henri Sivonen (a Capulet)
• Rich Schwerdtfeger (a Franciscan)
• Aaron Leventhal (an Apothecary)

The Prologue

Over the past few weeks, there has been a long, drawn-out discussion about how to integrate ARIA (an accessibility specification) into both SVG and HTML in a uniform way. There have been two main camps, as there usually are in these matters: the XML advocates, and the HTML5 (WHATWG) advocates. Both sides want to make sure that all content works the same across all browsers, authoring tools, etc. (collectively called User Agents), but they differed in how they thought it should be done.

The XML True Believers have held that the way forward for the Web is to enforce a strict, well-defined syntax for Web languages, and that to extend or combine languages, a differentiating mechanism called “namespaces” would be used. Namespaces in XML are specified to take the form “schepers:doug”. They declared a do-over on HTML, recasting it in the new XML mold (XHTML), and planned for browsers to be stricter on new content, and for authors to have learned their lessons.

The HTML Young Turks came forward with the observation that no matter how well you define a syntax, people will make mistakes (or not know the right way to do things), and that the way to recover from those mistakes is to define error-handling behavior for each kind of mistake; they also believed that since they could now reconcile older “broken” content with new browser behavior, that they were constrained to define behavior that would work in all past browsers, as much as possible, and to degrade gracefully in those that didn’t. But this required a more rigid parsing mechanism that doesn’t work well with extensibility, a problem exacerbated by Internet Explorer’s idiosyncratic and variable (one might even say spasmotic) behavior regarding the colon (“:”), meaning XML Namespaces didn’t work right. Also, the colon has a special meaning in CSS, yet another wrinkle.

So, XHTML and SVG are based on the XML model, and the new HTML5 is based on the new-old model. This difference wasn’t really much of a problem for SVG, though, because SVG and HTML are two different languages…

But of course people want to use them together. (More on that in some other post.)

The obvious way around that is to have two different parsers (a parser is a program that reads a formal syntax and makes a model of it for the browser to act on), and when you encountered SVG inside HTML, you would switch to the stricter parser. HTML would have its model for naming attributes (with no colon), and SVG would have its attributes (with a colon).

But there’s a hitch. ARIA is an accessibility technology meant to work in HTML and XHTML and SVG (and other presentation languages). The functionality for ARIA is defined in its own specification, but it’s not intended to be used on its own… it has to be integrated into a host language. It would be confusing for authors to have to use two different syntaces for the same functionality in different languages.

For example, in SVG you might have:

<svg version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:aaa="http://www.w3.org/2005/07/aaa">

<g xhtml:role="checkbox" aaa:checked="true">
<rect x="5" y="5" width="20" height="20" rx="5" ry="5"
fill="none" stroke="crimson" stroke-width="2"/>

<text x="30" y="22" font-size="18" fill="crimson">
Enable Accessibility</text>
</g>

</svg>

While in HTML, you would have something like:

<html>
<ul role="checkbox" aria-checked="true">
<li>Enable Accessibility
</ul>
</html>

Let the drama unfold…

Read the rest of this entry »

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?

Read the rest of this entry »