Reinventing Fire

Well, today is my birthday, so I’m giving you all a present. I’m finally releasing my Grafox extension, which extends Firefox’s native SVG functionality. I’ve gotten quite a lot of requests for this, which strikes me as odd, since I haven’t promoted it much at all. I’ll also note that Holger Will also has a Zoom & Pan extension that is quite good.

Grafox adds zoom and pan controls, and support for text-wrapping, editable text, and declarative animation, among other things. And at this stage, it adds them all badly. I’m releasing it now not because it’s stable (in fact, it was more stable a few versions ago), but because it’s unlikely to get stable bit-rotting on my harddrive, and I’ll be more inspired if I have an audience. I’m also releasing it as an open source project, in a sense… anyone can take any piece of it they need, and more importantly, anyone can submit patches or feature requests. I’m hoping that by the time Firefox 3.0 hits the wire, Grafox will be stable and functional.

The permanent home for it will be on my Grafox page. Try it out, and let me know what you think.

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 »

Firefox is my browser of choice. I really like Opera, and it has excellent SVG support, but I’m a creature of habit, and I can’t shake using Firefox. One of my favorite things about it is that you can trick it out to fit how you use it. I’ve installed quite a few Extensions (community-made bits of browser functionality) that I use all the time. They have become such a part of my browsing experience that I have even forgotten they aren’t standard, and when I had a hard-drive crash and had to reinstall, I was a bit at a loss why FF didn’t have some of the core functionality I’d come to rely on… until I reinstalled the extensions. I’ve even made one for my last employer, and in my spare time, I’ve been working on an image- and SVG-specific extension for Firefox, which I’ll be releasing shortly.

One of the other things I love about FF is the context-menu option for “View Selection Source”. I use it to figure out how certain bits of a document are marked up (though I also use Firebug for that). In my standards work, I also find myself needing to cite particular sections of large documents, such as technical specifications or documentation. I cite them to point out errors, to show where a bit of functionality is specified, to help out people with questions by pointing them to a reference, to defend my interpretation of a technical issue, and all sorts of other geekademic occasions. Since these documents are usually quite long, it’s necessary to get as close as possible to the relevant section when supplying a link, and fortunately, specifications tend to be very well marked-up, with logical document structure and plenty of ID attributes for ease of linking. View Selection Source is really great for that, because I can select a section header, open up the partial source in a new window, find the id, select it, append it to the original URL preceded by an octothorpe (“#”), and use that as a reference link; of course, sometimes the id isn’t where you expected it to be, and you need to look around for it a bit…

Okay, you see my problem. As relatively easy as View Selection Source makes the task, it’s still a bit… shall we say, labor-intensive. To be honest, it’s not quite as cumbersome as it sounds, and I’m so used to having to kluge around like that when programming that it somehow never occurred to me that it could be easier.

It just got easier. I spent a few hours putting together a Firefox Extension that automates this process. You just right-click on the section you want to link to, and select “Copy section link”. Idiri, my extension, automagically finds the nearest preceding link to where you’ve clicked, and copies it to your clipboard. It also highlights the element that it found an id on, as a visual indicator that it’s done its job and to let you know where you’ll be linking to. Simple.

You can download Idiri (from “id” for identifier, and “iri” for “internationalized resource identifier”, a fancy way to say URL or Web address), and let me know what you think. More details below…

Read the rest of this entry »