Reinventing Fire » CDF

Pointers on Background of SVG Borders on Mutiny

Schepers — Sat, 21 Aug 2010 21:37:09 +0000

With SVG being integrated more and more into HTML5, both included via and elements, and inline in the same document, some natural questions about SVG and CSS are receiving more focus. This includes box model questions like background and border, and pointer events.

I’m interested in comments from the community on what direction SVG should take.

It’s pretty clear that the intent of the SVG 1.1 spec was that the box-model CSS properties must not apply to any SVG elements. In addition to what the spec states on the subject, my conversations with people who participated in the SVG WG at the time leave me with no doubt on the matter.

The question is, is that the behavior we want? How hard or easy is it to change that in modern SVG+HTML+CSS implementations? What is most useful and intuitive for content authors?

In my opinion, we could specify that some aspects of the box model apply without screwing with SVG’s coordinate-based positioning system. Here are my initial thoughts on some specific properties:

Borders

A borders is different than a stroke. An SVG element, including any graphical (, , , etc.) or container element (, ) can have both a stroke (which conforms to the geometry) and a border (which conforms to the element’s bounding box). A common use case is setting the graphics apart from other content, or doing mouseover highlights of an SVG element; for example, when I mouse over or focus a circle, it would be much nicer, and just as semantic, to simply have a CSS property draw a rectangle around that element as a highlight than for me to generate a rectangle based on the bbox and insert that into the DOM, keep a pointer to it, then remove it when I mouse out.

Paint servers and similar resources (gradients, filters, etc.) should not have any border. Note: is a non-rendering element, akin to , so no border would be visible for that either, but if the content of a is d, any border properties would apply in the same manner as for other properties.

The border should not have any effect on the layout or rendering; it would be strictly visual.

Margin

No effect on SVG content, but may affect HTML content around that SVG content. So, an element with 'margin: 20px;' has a 20-pixel gap around the SVG content, just as if it were

Alternately, maybe margin only has an effect for elements; that might be simpler to specify, implement, and understand for content authors.

Padding

Again, this has no effect on SVG content, but it does affect how the border is drawn. This would be a nice way to compensate for thick stroke widths.

Background

A background is different than a fill. Background is much the same as border; it is a rectangle (modulo the border-radius effects) around the shape, based on its geometric bounding box, taking into account padding.

By default, there should be no background color, including for the element. Right now, there is a WebKit bug in Chrome and Safari which renders a white, non-transparent background for SVG fragments or documents; this is a major pain for any content creators trying to use SVG, much like the old Internet Explorer bug on transparency in PNGs. I hope it receives some attention from the WebKit developers soon.

SVG Tiny 1.2 defines a 'viewport-fill' and 'viewport-fill-opacity'. I think those should be deprecated in favor of 'background' properties; I have no opinion on which should have precedence… maybe they should be seen as aliases of 'background', if that makes it simpler.

A background on SVG content raises the question of pointer events, which is also relevant to borders.

Pointer Events

Should pointer events on the border or background fire on the element itself? I think that the default should be “no”, just to be safe and consistent with older SVG content, but I could easily be persuaded to reverse that. Either way, there should be a new property or set of properties that can modify this, in a manner consistent with how CSS is defining 'pointer-events'.

This touches on the question, asked in a related thread, on whether the element, by default, should be a proximal event target for pointer events. My answer on that is a pretty firm “no”; if you want to have it as an event target, give it a background, or change the 'pointer-events' value.

Questions

A few high level questions:

Is this a change from SVG 1.1 and SVG Tiny 1.2? Yes.
Is this backwards compatible? Kind of. It introduces new behavior that is not consistent with past behavior, but doesn’t explicitly change very much.
Does this break existing content? Very doubtful.
Is this intuitive for content authors? My intuition says yes.
Does this match existing implementations? Some, at least.
Does this provide value for content authors? Yes.
Does this make it harder to implement? I don’t know; I suspect it makes it easier for at least some implementations.
Would defining this improve interoperability? Yes.

Conclusion

I propose we change SVG 2 to explicitly define this behavior. As the editor of the HTML5 spec, Hixie seems to imply that this is not for HTML5 to define, and I tend to agree with that, though maybe some informative mention in the HTML5 or CSS specs for how SVG treats margins and padding might be appropriate. We recently formally closed the Compound Document Formats Working Group, which was formed to look at exactly these sorts of questions, and published its specifications as Working Group Notes for posterity; we wanted to be clear about its status. The CDF WG succumbed to the politics around the reformation of the HTML WG, and probably to good effect overall; but in its absence, we still need to resolve these questions by cooperation between the various groups involved.

I don’t think this should be any different in standalone SVG files than in SVG files referenced or inlined in HTML. That would be very unintuitive, in my opinion.

If this is not controversial, I would be happy to put any or all of this in the SVG Integration spec, which is one of the foundations of SVG 2. If someone disagrees with this, we’ll have to talk about it before I start editing the spec. In either case, it would need to be fleshed out some… I’m probably glossing over some possible stumbling blocks in the box model, which I’d appreciate feedback on.

Please leave a comment if you like my suggestions, if you see a flaw, or have a better suggestion.

Update:

Just to show what I’m talking about, I created a sample. Here is a good example of a bad example; below are 3 instance of the same SVG with the same CSS background and border values, with a border width of 2px. The first 2 are external files referenced as objects, the third is inline in the HTML (you won’t see this one unless you are using preview releases of Firefox 4, WebKit, or IE9); the second image also has a padding and margin of 10px.

I tested this in several browsers, and in the referenced cases, the border width increases the image size, spawning scrollbars; I don’t think that’s a good outcome… it should clip the border, just as it does for any graphical overflow… borders should not contribute to the geometry of SVG images.

In the second case, where I added padding, the argument is less clear, but I still believe that for referenced content, the border and background should not displace the rendered graphics, and should be clipped. For inline content, it would make sense for the padding and margin to be visible in the rendered document, but it should still not change the geometry of the SVG.

Please use a modern browser.

We’d need to specify this in order for it to behave the same across browsers (and authoring tools). So, do people agree or disagree with my conlcusions?

Web Audio Goes to Eleven

Schepers — Fri, 14 May 2010 18:58:42 +0000

I’m really excited about W3C’s new public Audio Incubator Group, just launched today, and open for collaborators, innovators, and instigators. Go take a look for yourself, and see if you can contribute.

To celebrate the occasion, here’s a simple example of an experimental audio inteface, in the world’s first (and worst) audio synthesizer in SVG (you’ll need a special Minefield build to use it). Just click on the keyboard… it’s pretty rough still, but it shows some of the potential:

Please use FF1.5+, Opera 9+, WebKit/Safari3.0+, or IE9+
(standalone SVG file)

For some background, read on after this break…

Background

Years ago, I was one of several SVG developers interested in doing for audio what SVG did for graphics, and we talked a bit about a format we called SynthML. The old Adobe SVG viewer included an audio element for MP3 playback, and I found it really useful for adding subtle sounds for button mouseovers, clicks, and other UI effects, so the idea of programmatic control of music on the Web had intrigued me for some time (anyone remember Thomas Dolby’s Beatnik?), for enhancing user interfaces, adding ambient background music, and providing full fledged music webapps. The SynthML effort fizzled out, and while there are some interesting music markup languages (most notably MusicXML, which is more like the MathML of music), there hasn’t been much traction beyond simple recording playback.

That’s why I was so psyched when I saw what Alistair MacDonald, David Humphrey, Corban Brook, and a few others were up to while attending a Processing.js community event at Bocoup. David hacked up a special build of Gecko to add script access to the raw audio stream of the HTML5 element, and Al, Corban, and friends were building cool demos on top of it.

I immediately knew I wanted to see this as a part of the native functionality of the Web platform, across browsers. In some ways, it’s the last major missing piece from the open Web… the ability to view source and hack sound, the last commonly digitizable sensorium. I also knew that I wanted the use cases and requirements to come from the larger community, the musicians and UI designers and developers who will ultimately be the ones using this functionality to sound out the depths of what’s possible on the Web (okay, I’m corny). So, I talked with Corban, David, and Al, and we agreed that a public discussion forum would be the best way to connect with this community, to get them talking and experimenting and building and sharing.

Chris Blizzard of Mozilla was there too, co-sponsoring the event, and he was extremely supportive of getting this work started at W3C. I wrote up a charter for a public incubator group, and started knocking on doors of the browser vendors, our other members, and the wider community who might be stakeholders, to drum up interest. Pretty quickly, I got support from folks at the University of Rio (PUC-Rio), BBC, and Google; currently, a W3C Incubator Group takes a minimum of three W3C members to kick it off, though once it’s started, anyone can join. With that nicety taken care of, W3C management approved the charter, and the new W3C Audio Incubator Group (or Audio XG) was launched today!

Joining the Audio XG

I invite anyone interested in audio, music, speech synthesis, games, or other related topics to get involved, join the Audio XG, and start shaping the future of Web audio on the mailing list, and chat on the #audio IRC channel (irc.w3.org, port 6665, channel #audio). Incubator participation is free and open to anyone who wants to help out.

About the SVG Synth

My SVG synthesizer is a true product of the Web. I know next to nothing about music… I can’t play an instrument, can’t read music, don’t know music theory… I love music, but I’m a consumer, not a creator. I’d love to change that, when I have time, but I’ll settle for now for enabling others.

So, when I decided to make something with the audio API, naturally my first thought was to do something I didn’t know how to do, for which I’m totally unqualified: create a synthesizer in SVG.

I started with the HTML example from the documentation for the experimental audio API on the Mozilla wiki, and converted it to SVG (with a few missteps along the way). As it turns out, the HTML5 audio interface is exposed in Gecko (the Firefox engine) even when there is no HTML content. This was good news for me. It made it even easier to programmatically create sound with it. I suspect that this is something that lies outside any current specification, but it should be codified somewhere.

Next, I looked for a piano keyboard in SVG; I found a few on Wikimedia Commons, but they were not quite what I wanted (and in typical Inkscape fashion, were a little bloated), so ultimately I just made my own, which was trivial to do.

Next, I had to understand which notes each key should sound. So I read a lesson on keyboard basics, which sufficed for my purpose.

Then I had to figure out what the frequency of each note is in Hertz (Hz), which is what the audio API understands. It was no surprise that someone had published just such a table corresponding notes to frequency, with the companion equations for deriving them.

To put the pieces together, I took the simplest possible approach: I handcoded the keyboard (I could have instantiated it with script, because it’s very deterministic, but I favor declarative markup that can be tweaked in an authoring tool); I assigned an id to each key based on the note (C4, Af0-Bb0, etc., where “f”==”flat” and “b”==”sharp”, and the number denotes the octave); I then created an associative array with the note-id as the index and the frequency as the value, so I could look it up with the key’s id; then it was just a matter of sending the frequency to the script from the HTML example, and adding a duration timer.

Finally, just as a decorative flourish, I found a partial musical staff with a treble clef and beamed eighth-note, in SVG, of course, and tweaked it to my liking.

My tools? A Web browser with the audio API enabled (libre source), a search engine, and a text editor.

Voilà! From knowing almost nothing about formal music (I’d never even heard the term “middle C” before), I created a simple synthesizer, and learned a bit about music along the way. That’s the power of the open Web. That’s why I’m so pumped up about this new focus on audio. This one goes to 11.

Platform Games

Schepers — Tue, 09 Jun 2009 16:07:12 +0000

I attended Google I/O a couple weeks ago, and had a great time. They really put the “hype” in HyperText Markup Language 5, identifying things like the Geolocation API and some of the WebApps Working Group deliverables as part of “HTML5″. Not quite accurate, but it was a branding exercise, not a technical one. Notably absent from the things they rolled into HTML5 during the keynote, though, was SVG… in fact, they seemed to go out of their way to avoid it.

But it’s in there.

Behind the curtains, I talked to several Googlers at the conference committed to SVG. Brad Neuberg, a whipsmart Google engineer and all-around swell guy, is making a Javascript shim that takes SVG (referenced or inline) and renders it consistently across browsers, including Internet Explorer, using the Flash plugin. Patrick Chanezon and Ignacio Blanco, also of Google, spoke about SVG and Canvas at JavaOne the week after.

It wasn’t a certainty that SVG integration would make it into HTML5 (rather than HTML6, etc.). I’d been asking for it to be included for a while, but the the editor, Ian Hickson, was resistant to the idea. At one point, he even suggested supporting some other vector graphics language, even a stripped-down custom format (which was likely a testing of the waters… in a similar vein, rather than simply integrating custom namespaces or RDFa or ITS, he reinvented his own syntax for each instead). But ultimately, even he knew that wouldn’t fly for vector graphics. SVG is already too well supported in browsers, in authoring tools, and as a general format for anything else to make sense.

Because it’s all about the platform. And SVG is part of the platform.

Already, inline SVG (that is, SVG mixed into a single document with XHTML) works in all the browsers that support both XHTML and SVG (that is, all but Internet Explorer), and even worked in plain-text HTML in Internet Explorer with the Adobe plug-in almost a decade ago. Steven Pemberton points out that that was the true innovation of XHTML, the ability to plug in new syntaxes and new functionality without having to change the core of the language or revisit parsing rules. It has been argued that XHTML’s extensibility is superior to HTML5′s parsing rules that only work with a set vocabulary.

But the browser vendors were determined that text/html, being more common and robust than XHTML, had a market advantage, and so to fit in with that, SVG needed to work not just with XHTML, but also with text/html. There were compromises along the way with SVG… probably chief among these are parsing issues. Unlike XHTML, SVG was designed from the ground up for an XML syntax. HTML uses a much more complicated parsing that defines error recovery behavior for things like missing quotes around the attribute values, case insensitivity, and non-well-formed markup, and it doesn’t support namespaces properly. SVG in text/html has to (some say “gets to”) follow some of these rules in order to fit in. The SVG WG was a bit reluctant to adopt these changes, out of concern that SVG might fly into tag soup, making it harder for existing authoring tools and XML-based SVG viewers, as well as generic XML processing tools.

But ultimately, we had to agree that SVG needs to conform to the platform.

So, we’ve taken a step backwards in some ways: right now, there’s pretty much no non-conforming SVG content in the wild, and the Adobe SVG viewer was fast, and had features still not found in some browsers. But we’ve now got better error recovery, and SVG in almost all major browsers, which is more robust than a single-vendor plug-in, and is ultimately better for authors and users. The way to use it with HTML is now better defined:

as with HTML, for SVG in text/html, you don’t have to use quotes on your attribute values (if the value doesn’t contain spaces, etc.)
authors don’t need to declare namespaces (in fact, this was the case with the Adobe SVG Viewer already, so not really much of a loss)
mistakes in casing for element and attribute names will be corrected
well-formedness errors will be recovered as best as possible, rather than halting rendering
custom namespaces, such as round-tripping metadata inserted by authoring tools, will not be supported
most importantly, normal valid, well-formed SVG with no custom namespaces will Just Work, whether as a standalone document or referenced as an external file, or inline in text/html or XHTML.

In fact, though HTML5 is not yet done, SVG inline in text/html already works in special experimental builds of Firefox and Opera, and should work out of the box soon. Forward-looking authors can already use SVG in modern browsers, using XHTML, and that content will soon work when served as text/html as well. The final barrier to common use of SVG is being solved by Brad’s “SVG Web” shim, allowing SVG content to work in IE. This will not be a perfect solution; it would be better if IE supported SVG natively without making developers jump through hoops, but that won’t happen for at least a couple years (if at all), and SVG Web at the very least will bridge the gap. I’ve seen it run, and it’s pretty impressive already.

That SVG has had to bend in the wind gives the SVG language a unique opportunity to innovate. If the syntax is already going to need an update in existing browsers and authoring tools, we can reexamine some old assumptions and past missteps, and extend SVG to be better integrated with HTML and CSS and existing scripting practices. And even more importantly, we can examine use cases and make SVG better suited for what authors need to do.

Why is HTML5 a powerful enough platform that Google throws it’s weight behind it, despite the inaccurate and ungainly name? Is it the error-correcting parsing? No, that’s a good feature, even if the need for it is unfortunate, but it’s unclear that this is better than XHTML. Is it the new features like the and elements, which allow it to compete with the most common use of Flash? No, that capability has been possible using XHTML and SMIL for years, and is even part of SVG Tiny 1.2 (N.B.: HTML’s script interfaces are simpler and better than SMIL’s, but its lack of synchronization or timing containers is a big step back). Is it the new WebApp-centric user interface focus? No, we would probably be better served by a language designed for making UIs (like XUL).

So, what is the true power of HTML5? Coordination. Getting all the browser vendors to standardize on a common set of features. HTML5 is not a technical achievement, it’s a social movement. It’s an instantiation of the Open Web in the form of several specifications across several groups, and implemented fairly uniformly across all major browsers and platforms. This is largely in response to user demands to the browser vendors. They are tired of the special-casing and workarounds that make their lives and jobs harder and less satisfying, that make users struggle… they want a consistent platform, one without script libraries or shims or plug-ins or arcane rules. And the browsers realize this, and know that a rising tide raises all ships.

My personal advice to vendors who have excellent authoring tools, but who want to also control the runtime environment? The Web has moved on from vendor lock-in and black-box plug-ins. In a world where there is coordination between multiple vendors to deliver and support a central set of technologies, where everyone is unifying on a standard Open Web platform, from Apple to Google to Mozilla to Nokia to Palm to Opera to Vodafone. Nobody wants the hassle of being the only one to maintain the platform, but they all want the ability to change it without going though the gatekeeper of a single vendor.

It’s all platform games, and if you want to play, you have to jump to the next platform. Google knows this… they are hosting the next SVG Open, and are aggressively pushing the whole platform. Looks like a fun year ahead!

CSS Link Hack in SVG

Schepers — Mon, 19 Jan 2009 04:09:15 +0000

While answering a question about styling SVG with CSS in the Freenode #svg IRC channel (yes, people still use IRC), I threw together a simple example to illustrate. I like to do this, since in keeps me in practice, and gives me a chance to check the state of current implementations in the fast-changing world of SVG browser support.

The question was how to use CSS stylesheets, both internal and external, with SVG in Inkscape. While I know that Inkscape makes heavy use of CSS inline style declarations on elements (more than is to my personal taste, to be honest), I didn’t (and don’t) know if it has any UI features for adding internal stylesheet blocks, or links to external stylesheets. So I made a little test…

svgstyle.svg

svgstyle.css

circle
{
   fill: lime;
   stroke: green;
   stroke-width: 10px;
}

Which looks like this (at least, in Firefox, Opera, Safari, and presumably Chrome):

Please use FF1.5+, Opera 9+, WebKit/Safari3.0, or IE with an SVG plugin!

Both internal styles worked fine in Inkscape, but the external reference did not, showing just a black circle. I’m not really surprised. Note the clunky way that you have to link to external stylesheets in SVG:

That’s really XSLT-licious. I have to confess, I don’t really care for PIs (insert dated Magnum PI joke here), or XML prologs in general… they seem somehow clumsy and un-XMLy, like a throwback to SGML. And as far as I know, they can’t be created or changed dynamically via clientside script. Compare that to the relatively easy and straightforward X/HTML way of linking to external stylesheets:

In the SVG WG, we intend to allow authors to reference external stylesheets in a manner a little more modern and consistent with what authors are already used to using, in some upcoming spec. We could do that a couple of different ways. We could allow them to use an xlink:href attribute on the



Two Tech Predictions for the New Year (or So)
Schepers — Mon, 07 Jan 2008 18:50:41 +0000

Okay, first a disclaimer: none of this speculation comes from “insider information” I’ve gotten as an employee of W3C; but being surrounded by the swirl of standards, I suspect I may have picked up on a zeitgeist.  I’m interested in seeing how well my predictions play out.
Prediction 1: Microsoft will merge its browser and office platforms 
That’s what I would do if I were them.  Right now they are in a bit of mindshare competition with online apps, like Google Docs; as Web apps transition to the desktop (like, the downloadable desktop GMail client), Microsoft will take their core competencies (the desktop Office suite) and make it more Web-friendly.  They’ll take advantage of the fact that desktop apps are often more robust and speedier, and tie in the  chief benefits of Web apps: distributed authoring, ease of deployment, and ubiquitous availability.  To enable the latter, they also make a Office-lite Web app, sold as “software as a service”, for those who’ve bought the real product (though of course it won’t be as good as their desktop version); they might open this up in the razor-and-blade sales model.
They will merge two of their products, SharePoint Server and Exchange Server, into a sort of portal/wiki thing that ties into their new Office Browser.  They will probably integrate chat (MSN, or whatever) into the whole thing, so you have some uber-communications suite: email, chat, collaborative distributed document creation, and all that enthralling office goodness.
This could be IE8 (or IE9), or a totally new product, but it will probably be a new version of MS Office.  It will be their typical monolithic entry into the agile Web space.  And of course, it will use OOXML as a native format.
Why I’m wrong: I think this would be smart, but the different divisions of Microsoft actually compete for resources.  I wonder if they could play nicely together for long enough.
Update (25-01-2008): I’m actually going to Microsoft next week to talk about standards stuff.  Maybe I will get an inside scoop.
Prediction 2: A cross-platform browser based on WebKit (but not Safari) will supplant Firefox
WebKit has a cleaner, faster (if less complete) engine than Mozilla, and it’s already been reused by Apple for Safari, Nokia for their mobiles, Adobe for Apollo (I think), and by Google for Android.   But all those are controlled, as far as I can tell, by their name-brand deployers.
I think a new, more open repackaging will happen.   It will be standards-based, and truly open-source, from the engine on up to the executable.  It will implement Widgets (as being specified at W3C), so that people can make simple desktop applications based on common Web technologies.  But the key enhancement will be a new, cleaner, lessons-learned, easier-to-author Extensions platform.   Extensions, in my mind, are the most brilliant thing about Firefox, allowing slightly-above-average users to create new features for the browser, or to use features added by others; this gives great community buy-in.  But it will be even easier to do in this new browser; this will probably necessitate a new XUL-like language, too, so people can add chrome, or it might just be in the form of script APIs.   But what would be even smarter is to have the Extension editor, and Widget editor, built right into the browser, so making a new theme or feature or widget is as point-and-click as possible, with common tasks encapsulated (though for advanced enhancements, some scripting will be needed, in a smart editor with code completion).
Oh, and it will have SVG support.
Naturally.
Why I’m wrong: This is just my dream browser.  Browsers are a hard market to break into, because there’s established competition, and you’re not making a product you can sell… you have to give it away.  There’s already a lot of momentum around other efforts.  But this is the browser I want.  Too bad I’m so lazy.



Underscoring Accessibility
Schepers — Wed, 17 Oct 2007 21:57:54 +0000

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:

While in HTML, you would have something like:


Enable Accessibility


Let the drama unfold…

Act I
Scene I
XHTML defined a new point of extensibility, the ‘role’ attribute, which was intended to be use to add semantics to an element.
Scene II
The WAI Working Group  decided to use that as the point of entry for adding accessibility behaviors to custom controls.  Custom controls are things like an interactive tree selector, or a slider knob; they extend the limited set of form-based controls that browsers settled on, and they are increasingly used in script libraries like dojo or Scriptaculous.  SVG developers have been making custom controls using script and/or declarative animation for many years, since SVG doesn’t have any native controls at all, but can be used to build visually glitzy ones; they just aren’t treated as controls by AT (Assistive Technology) apps.  ARIA can be used to tell the AT that a collection of elements is meant to represent a particular type of control, and report what its current state is (on, off, hidden, selected, etc.).  So the SVG WG has been eyeing the progress of the Role and ARIA specs.
Act II
Scene I
The HTML5 movement, under the banner of the WHATWG, gained critical mass and was brought into the W3C for standardization with all major browser vendors.  The ARIA proponents worked hard to get ARIA’s accessibility functionality integrated into the standard.  Simon Pieters of Opera and Aaron Leventhal of Mozilla made a proposal for integration of ARIA using a limited ‘role’ attribute.  Because XML Namespaces don’t work right in IE (and not very intuitively in CSS), it was proposed that the different states of ARIA would be referenced and set in HTML5 using the prefix ‘arai-*’ instead of ‘aaa:*’ or ‘aria:*’.  I was only vaguely aware of early discussions of ‘role’ in HTML5, and despaired of its ever being adopted, knowing the resistance to generic extensibility.  But Simon and Aaron were actively working on getting ARIA integrated into the next releases of Opera and Firefox, to enable accessible Web apps.
Scene II
Dave Raggett (who originated forms in HTML) made an independent public request for the ‘role’ attribute to be added to SVG; I jumped on this, expecting that it would be done using the built-in extensibility mechanism provided by XML Namespaces.  Much to my dismay, immediately was made aware of Simon and Aaron’s proposal, which uses different syntax to how it would be done in SVG.  Much email discussion ensued, and a little biting of thumbs.
Scene III
I talked with the SVG Working Group about the ‘role’ attribute (step one in integrating ARIA), and while there were some reservations, we agreed that it would be great if we could do it.  (Note: really boring issues of process elided here… assume I explained why it’s kinda bad timing for SVG right now.)  But we decided to first gather opinions about how best to do so from the SVG community and other interested parties.  But the issue of ‘role’ was buried under the talk of whether or not to use the controversial and dreaded Namespaces (e.g. ‘aria:checked’ versus ‘aria-checked’).  It’s undesirable to add arbitrary attributes to SVG, because the content wouldn’t validate and couldn’t take advantage of all the XML tools that already exist.  And there are like 70 attributes, so we couldn’t just adopt them all… and if we did, what would happen when ARIA v2.0 came out?  Ugh… messy.  But the HTML5 guys insisted they couldn’t use namespaces.
Act III
Scene I
Rich Schwerdtfeger of IBM, who’s heavily invested in getting ARIA implemented, set up an informal call involving the Dramatis Personae (and a few others who couldn’t show up).  I talked it over with people on “my” side, and reviewed the XML Namespaces specification.  A little reflection revealed to me that, in fact, both approaches were using namespaces… just the syntax is different (‘aria:*’ versus ‘aria-*’).  And while the Namespaces spec doesn’t describe any other mechanism than the namespace declaration and prefix, neither does it procribe it.  I saw a possible way out.
The uninformed reader will assume this is some persnickety, trivial detail; such a reader would be right, but it’s still a pain to coordinate on crap like this.  Everyone assumes they are right, the other guy is wrong, and everyone should just do it their way.
Scene II
The teleconference happened today, and arguments were presented, and assumptions were challenged, and a verbal duel took place.  Issues with delimiters in IE and CSS were explained and explored.  The colon was a real problem, but so was the dash.  Making the “aria-*” string is a klutzy, short-term, one-off solution, and couldn’t really cut it as a true namespace prefix.  SVG has many attributes that contain the dash (‘stroke-width’, ‘fill-rule’, ‘font-size’, ‘stroke-dasharray’, ‘fill-opacity’, ‘pointer-events’, ‘font-family’, ‘shape-rendering’, and many more); it’s a common convention to separate words in attributes with a dash.  No future (or present) language could safely use ‘font-’ or ‘shape-’ or any other prefix to integrate with SVG.
But Aaron Leventhal, a very pragmatic guy, pulled out just the medicine I think was needed.  The underscore (“_”).  It works in IE, has no special meaning in CSS, is a legal (if underused) character for attributes in XML, doesn’t cause problems for the HTML parser, and doesn’t conflict with any conventions in SVG.  It’s probably underutilized because it’s just slightly harder to type than a dash (on my keyboard, it’s the same key, but requires the shift key be depressed).
_!!
Scene III
The final scene has been lost in the mists of the future.  But here’s my plan, if nothing gets in its way:  to create a new namespacing specification that uses the underscore as its prefix delimiter.  It would differ from Namespaces in XML 1.0 in three ways:

It would make the namespace prefix string fixed.  In XML Namespaces 1.0, any string is allowed to be used for any namespace prefix.  For example, if you were feeling particularly contrary, you could delare that the string “svg” is the prefix for XForms content, “xforms” is the prefix for MathML content, and “math” is the prefix for SVG content; in reality, nobody does this, for obvious reasons.  In my proposal, there would be a central “registry” of sorts for the most common prefixes; my suggestion is that such a registry should be defined in the CDF WICD profiles (though I haven’t consulted that group), and that a User Agent that supports multi-namespace documents (aka Compound Documents) would know what those prefixes stand for.  The most obvious ones are “svg”, “html”, “xhtml”, “xforms”, “mathml”… oh, yeah, and “aria”.  That this is less inherently extensible than the colon-delimited unfixed prefix might even be a bonus, ensuring that the combination of technologies has been combined systematically and specified, promoting interoperability betweem UAs.  Prefix names would consist only of letters and digits, forgoing the dot and the dash, and of course the colon and underscore; a possible exception that occurs to me is the use of the dot to serve as a versioning convention, so you would have “aria.2_checked” to represent an ARIA v2.0 ‘checked’ attribute.
As a consequence of #1, there would be no declaration needed or specified.  The supporting UA would simply know the ” name + _” prefix, and treat it as it should be treated.  This makes copy-paste authoring easier, since authors wouldn’t have to know or care about the namespace declaration earlier in the scope of the copied content.
This specification would not reserve the underscore, but merely allow supporting implementations to assign special meaning to the combination of ” name + _”.  This would prevent some problems in existing XML processors.  Languages that register their prefix name would be encouraged to pick something that is unlikely to conflict with other partial attribute or element names.  (I toyed with the idea of making this an extension mechanism for attributes only… not element names.  I haven’t thought that through yet, though.)

This would be more intuitive for creatinging documents, since authors (and authoring tool) could depend upon a convention.  Supporting XML processors would have a much easier time resolving namespaces.  Languages and UAs could support both namespacing schmemes, if they so chose, to allow for custom or unconventional namespaces that aren’t registered; the two schemes are orthogonal and (I believe) compatible.
Let the rotten tomatoes fly.