This is as days pass by, by Stuart Langridge

My ARIA "stylesheet" hack came up on the WAI-XTech mailing list. Some of my commenters here, and some of the people on the list, seem to have misapprehended what the proposal was designed to do; I've mailed the list, but it seems useful to post these clarifications here too.

1. I am not proposing adding ARIA to CSS. An "ARIA stylesheet" looks like a CSS stylesheet because that's a convenient way to apply properties to elements, but they aren't the same thing.
2. I'm not proposing that the technique requires JavaScript. My suggestion is that browsers natively understand how to retrieve an "ARIA stylesheet" and apply the ARIA attributes defined therein to elements, as per the selectors in the "stylesheet". The JavaScript implementation was just to demonstrate how it would work, and a prototype for how people might support older browsers which don't have this native "ARIA parsing", in the same way that there are JavaScript libraries which mimic HTML5 WebForms handling for older browsers that don't yet support <input type="range">.
3. The "ARIA stylesheet" only dictates the initial setup of a page, in much the same way that a CSS stylesheet does for presentation. If I use JavaScript to alter the style of an element, that change is not reflected in the CSS stylesheet text, but it is obtainable through element.style or getComputedStyle(). In the same way, altering an ARIA attribute on an element through JavaScript would work perfectly well, and the current value is obtainable through element.getAttribute("aria-role") or similar.
4. I understand that ARIA is semantic and therefore belongs more directly in the HTML than mere presentation does. However, distinct advantages to moving ARIA information out into a separate document do exist:
   1. It allows me to "ARIAify" an entire website very easily, much as having CSS in a separate stylesheet allows me to change the design of a site very easily. At the moment, to "ARIAify" a website I have to edit every single page in great detail. If a site is already properly marked up and relatively consistent in the way it uses that markup, adding ARIA roles and attributes could be done relatively easily by adding one file, the ARIA stylesheet, and a <link rel="aria" href="..."> element to the head of each page.
   2. It avoids the validation problem, that ARIA attributes will currently cause a document to fail validation
   3. It reduces bandwidth required to serve a site, meaning that sites load faster and servers work faster and cheaper, in two ways:
      1. The "ARIA stylesheet" can be cached by browsers, meaning that it needs only be served once per site; embedding attributes in the markup means that every page gets larger and the attributes are not cached
      2. User agents that are not tied into native accessiblity APIs (for example, users who do not have the accessibility APIs switched on because they don't need them) do not need to fetch the ARIA stylesheet at all, saving even more bandwidth

Hope this helps clarify my thinking. Comments are welcomed.

Don't forget the pancakes on Jif Lemon Day, they say. Some days I really miss Sam.

Yesterday I did a talk at the inaugural Multipack Presents event in Birmingham, about some whizzy JavaScript stuff that people might not know about. It covered things that are nearly available for use everywhere (getElementsByClassName, Array.forEach) right up to things that only have an implementation at the moment in one browser (server-sent events (Opera), local SQL database storage (Webkit)). The idea was to say firstly "look at all this cool stuff that's coming up" but more importantly to say "look at all this cool stuff you can use right now if you want to!" Talk available for browsing and downloading over at the Whizzy JavaScript Stuff talk page, anyway. Thanks to the Multipack for having me; I hope there are many more of these events! There are event photos on Flickr, and I'm told there may be (incomplete) video of my talk available at some point (when there is I'll link to it).

Yesterday at the Multipack Presents event, Matt Machell spoke about WAI-ARIA, which is a way of marking up HTML with accessibility hints. (Think of it as an accessibility microformat, pretty much.) Anyway, the way it works is by adding loads of new attributes to HTML: to say "this div is actually being used as a slider", you say <div id="myslider" aria-role="slider">. There are lots of similar new aria-* attributes: aria-describedby, aria-minvalue, and so on. Anyway, I asked: why did loads of new attributes get invented? Why not have an "aria stylesheet", where instead of <div id="myslider" aria-role="slider">, you put #myslider { role: slider } in a separate ARIA "stylesheet" file? And Matt said, hm, dunno, why don't you write something to do that? So here it is. This is in no way complete. Requires jQuery, too. What you do is add

<link rel="aria" href="first.aria">

to the head of the page, then include jQuery:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

and then finally have this snippet of code:

<script>
$(document).ready(function(){
  $("link[rel=aria]").each(function(){
    $.get(this.getAttribute("href"), function(data) {
      $.each(data.split("}"),function(idx, stanza){
        var parts = stanza.split("{");
        if (parts.length != 2) return;
        var sel = parts[0];
        $.each(parts[1].split(";"), function(idx, directive) {
          var bits = directive.split(":");
          if (bits.length != 2) return;
          $(sel).attr("aria-"+bits[0].replace(/^\s+|\s+$/g,''), 
          bits[1].replace(/^\s+|\s+$/g,''));
        });
      });
    });
  });
});
</script>

which takes an "ARIA stylesheet" which looks like

#first {
  role: slider;
  described-by: #second;
  value-min: 10;
  value-max: 30;
}
p + p {
  role: main;
}

and applies the specified ARIA attributes to the specified elements, by CSS selector. This is rambunctiously untested, and the parser for the "stylesheet" is pretty noddy and not at all error-tolerant. If people find this useful as a concept then I'll try and trick it up into something a bit better.

For the last week I've been in Berlin with the Launchpad JavaScript team building a set of cool widgets using YUI3 that will gradually start to appear in Launchpad and make its UI nicer. The LP guys have started to write up the things that they're doing over on the Launchpad blog. I've learned quite a lot about YUI3 in this week; I need to do a writeup (or more probably a set of individual writeups and tips about stuff I've learned). Now is not the best time, though, since YUI is being incredibly frustrating with its widgets; they don't clean up after themselves, so if your widget creates HTML then it's your responsibility to remove that HTML from the document later. And my widget seems to be creating its HTML twice, which is less than excellent. Frustration abounds. That aside, though, this has been a good week; got a lot done, and I want to see Canonical be part of the web community like we're already part of the Gnome/Linux community. Building cool stuff and talking about it and releasing it is going to help, there.

"Doctor, Doctor, my toe hurts." (Doctor amputates patient's leg, and his right hand and his nose into the bargain.) The solution to "my audio isn't working right" is not "uninstall PulseAudio". Nor is it to complain that your distro didn't give you an "uninstall PulseAudio" button. Stop suggesting it. I ran into one small audio problem and half the responses to other people mentioning it were "you need to completely remove PulseAudio". Stop recommending that to people. This has been a party political broadcast on behalf of the "there's a time in the evolution of everything that works when it didn't work" party.

Lots of conversation about IE6 holding everything back (Christian, Robert, et al), which is something that people have been talking about for ages (me last year, me in 2005, Zeldman in 2001 in a more general sense). A point to remember here: no-one (well, no-one serious) is suggesting that IE6 users get a site which says "you are using IE6: bugger off." Instead, the suggestion really is that IE6 get the same treatment as Netscape 4: it gets the unenhanced version of your sites. You're already building sites that work in every browser (if you're not, go away and start doing that), and you're already building sites that give Netscape 4 the version without many enhancements. Why not move IE6 into that category? If your argument is that IE6 people will not like your site without enhancements because it doesn't do as much or doesn't work as well then...you're not building sites properly. Stop doing that.

I still don't have a decent name for "Linglish", the toy scripting language for the Linux desktop that I was playing around with a couple of days ago. I've added a couple more features to satisfy my curiosity about how hard it would be to do, and I've read the comments on the previous post with a great deal of interest. Thanks to everyone who chimed in with thoughts.

First, what Linglish can now do:

tell screensaver to lock A simple command: just tell one application to do one thing. ask banshee's engine for uri Request the value of something from an application. If you do this from the command-line, the value is printed out:

$ python linglish/runner.py -c "ask banshee's engine for uri"
file:///home/aquarius/Music/New%20Order%20-%20World%20in%20Motion).MP3

tell banshee's engine to pause tell screensaver to lock Run more than one command in a script tell tomboy to FindStartHereNote tell tomboy to displaynote with the result Call a command which returns something and then do something based on that: Tomboy has no "show the Start Here note" function, but this does it fine by getting a reference to the Start Here note and then displaying it. The latter command could also have been written as tell tomboy to displaynote it or tell tomboy to displaynote FindStartHereNote wait for banshee's eventchanged ask banshee for currenturi tell tomboy to createnote with it Wait for an application (Banshee) to send a signal (a song has stopped playing or started), then when it happens ask for the value of a property (the path to the currently-playing song), and finally call a different app (Tomboy) to create a note with that path as its name. This example will then exit: if you want to create a new note every time the song changes, then wait repeatedly for the signal rather than just waiting for it.

Next, some musings:

One thing that this has revealed to me is that there are quite a few apps which I'd like to interact over D-Bus with which don't provide an API to do so. The glaringly obvious example here is Nautilus (and indeed there is a bug requesting a D-Bus API), and a part (a small part) of why I've built this is that if there's an easy way to encourage people to write little programs controlling their desktop then that will encourage application developers to build APIs to their apps. Zenity doesn't have one either, which makes interaction from these little Linglish scripts a bit difficult; I suppose I could build "display dialog" commands into the language but that seems a bit off. On the other hand, one of the advantages here is that there's nothing stopping someone building a thing which is just a D-Bus API and which then calls out to Zenity to do the work. A second is that our D-Bus APIs are not necessarily brilliant. Picking a silly example, if you want to find Tomboy's version using Linglish you have to tell tomboy to version, which sounds rather stupid; it should be "ask tomboy for version", but Version() is a method rather than a property in Tomboy's D-Bus API. (I'm not picking on Tomboy here; they have a pretty comprehensive API, and I've been testing and developing Linglish using primarily Tomboy and Banshee.) Linglish is sort of designed with the conceit that methods are verbs, hence the "tell someapp to dosomething" syntax, which sounds deeply weird if your methods are not actually a verb. It's also jolly hard to work out what D-Bus APIs are actually available. Well, that's not true: if you're me, or a hacker like me, then you can use J5's fantastic D-Feet D-Bus browser. I think this problem is best solved with tools used to create the language rather than the language itself, although there's more on this in the future-development section below. There were plenty of comments on the last post saying that this was a stupid idea and that it made much more sense to have a syntax like screensaver/lock or screensaver.lock() rather than tell screensaver to lock. I, personally, do not agree with that. I'm not necessarily suggesting that I'm right and they're wrong, or that neophytes will indeed find my way easier: just that this is an alternative way. If you think that Python or Smalltalk or any one of a dozen others are a better approach, go for it: I'm certainly not stopping you.

Thirdly, questions about what it might do in the future and whether those things are a good idea:

The original conception I had for this in my head is now basically done. You can send commands to programs, you can tie programs together, you can get info out of a program and print it out. It would be able to do half the little scripty tasks I want to do on my desktop (assuming that the APIs existed to do them, which they mostly do not). Here are future things it could do, in rough order from small to big:

1. Be cleverer about calling methods on applications with more than one object. At the moment you have to tell banshee's engine to pause, because Banshee exports more than one object. Since only one of those objects actually has a Pause() method, tell banshee to pause makes more sense.
2. Have Linglish be able to document an application. ask linglish about tomboy which then prints out Tomboy commands you could use by introspecting Tomboy's D-Bus API would be pretty nice. One big problem with this is that for most apps they need to be running to find out what API they offer, so ask linglish about banshee would start it up.
3. There are currently no control statements. This is a problem if you want to do anything even semi-complicated in a script, especially since the common approach to D-Bus signals in Linux apps seems to be to generate a SomethingHasChanged and then pass a whatchanged parameter; Banshee fires StateChanged('paused') and StateChanged('playing') rather than Playing and Paused signals. NetworkManager has something similar. It's understandable why: you get one signal in a few different flavours rather than a multitude of signals. Inconvenient for this, though, because to vary what the script does based on a parameter you have to have an if statement (or something similar). I've been thinking about this: I do not want to build a proper language. If you want that, learn Python. But...maybe it needs control statements. I don't know. I'm against it, but if this is useless without them then that's a strong argument that the effort is not worth it.
4. A script editor. This would allow people to write scripts without having to know the names of any of the functions you need to call -- popup completions and the like. This is even more problematic than ask linglish about whatever, since there's no way of saying "which apps in the world offer a D-Bus API?" -- most apps do not install an activation file, which means they must be running for any script editor to even know they exist. It's also a lot of work, although most of the heavy lifting is done by GtkSourceView.
5. Packaging and stuff. If this is likely to be useful I should make .debs of it and so on and make it easy for people to install and everything.

And finally...

The overarching question: is doing more of this a good idea and worth the effort? Your comments gratefully accepted.

Just a quick note to say that the LugRadio Community Hero and general video god, Tony Whitmore, is doing a great job of getting videos of talks from LugRadio Live UK 2008 available online for people to watch. They're not all there yet, and more will be showing up over the next short while, but there's already a really good proportion (including the LugRadio live show). Go grab them: LugRadio Live UK 2008 talk videos

After a few hours of fiddling around, I've come up with a thing I'm calling "Linglish": it's a very simple scripting language for the Linux desktop. It looks a lot like AppleScript, and it's nowhere near finished. It basically allows you to write in a sort of bastardised English which then calls D-Bus functions, so you can say things like:

• tell screensaver to lock
• tell banshee's window to present
• tell banshee's playerengine to pause
• tell tomboy to createnamednote with 'My Named Note'
• tell guake to add_tab
• wait for tomboy's noteadded then tell banshee's playerengine to toggleplaying
• wait repeatedly for tomboy's noteadded then tell banshee's playerengine to toggleplaying
• wait 6 times for tomboy's noteadded then tell banshee's playerengine to toggleplaying

Like I say, it isn't finished yet (the above all works, but there's lots more that needs to happen). At the moment, for example, there's no way to run more than one command, or to get a return value from any function and react on it. The question is, is this a good idea that's worth pursuing? This will never be (and is obviously never intended to be) a replacement for a proper language; if you want to do something semi-complicated, drop into Python or JavaScript or Vala or C and make the D-Bus calls yourself. However, I can see it being useful to help people who don't want to get to grips with proper programming but still want to control their applications. If you think it's a bad idea, please let me know why and what you think should happen instead. If you think it's a good idea, then here are a couple of other thoughts that I've had on how it might evolve:

• A script editor program would be nice, which could dynamically inspect D-Bus to help you write scripts. It could compile a script to an executable that wouldn't need the script runtime either without too much difficulty (one big Python script, perhaps, or using glick to make an actual executable).
• Obviously it needs to be able to run multiple commands, and have later ones react to what happened in earlier ones. I'm imagining an ask banshee's engine for position sort of sentence, which would get the Position property and then stash it in an invisible result variable, meaning that the next command could be tell banshee's playerengine to seek to the result + 20 or something similar.

Key question is: is this worth pursuing? Or is it reasonable to demand that people who want to script our desktop should learn a more real programming language? Code (written in Python) in svn at http://svn.kryogenix.org/svn/linglish/; it's only half a dozen files. If you want to fiddle with the grammar to add new ways of parsing commands you'll need yapps2 (in Ubuntu as yapps2), and you'll need the yapps2 runtime to actually run any commands (in Ubuntu as yapps2-runtime). Syntax: python linglish/runner.py -c "tell tomboy to createnamednote with 'named note'"

The Opera guys have been putting together a Web Standards Curriculum -- a sort of school textbook of modern web development. Anyway, after a certain amount of cajoling from Chris "Dark Sanatic" Mills I came through on my promise to actually write some articles for it. They've now been published in the JavaScript section, if you like that sort of thing: one on modifying the HTML DOM tree and one on simple animation. Enjoy. (I am proud I was not as whiny as Nyman -- if you saw excerpts of my emails to Mills & co they'd all say "oh, piss, yes, I did say I'd do that, didn't I? I'll get it done this week, promise." Who'd be an editor, eh?)