This is a short rant by Charles McCathieNevile, since I find myself talking about this somewhere new every few months. It hasn't been endorsed by anyone, and all feedback, opinions, and flames should be directed at me. Note that this is a rough set of notes, not a polished document for publication.
I began this document on April 7 2000, and it was last modified on $Date: 2000/04/07 20:05:10 $
Contents
What's missing from this at the moment?
There are a couple types of active element in current HTML.
Buttons and links are things with a single possible action. Some form inputs are a bit more complicated, but I'll leave them aside for the minute - most onmouseover behaviours are connected to links or to otherwise inactive elements, and the forms group is in any case working on completely revising the way forms are made, for XHTML.
In the traditional graphical (GUI) web browsing model you can hover the mouse over a link and find out something about it - in early browsers the URI was rendered, but now there are much more interesting possibilities, including giving a title supplied by the author, or some highlighting behaviour.
If you can't use a mouse, how do you get this effect?
In text browsers, or well-designed GUIs, you can move a focus from link to link. This doesn't activate anything, any more than hovering a mouse doesn't activate anything (in standard design conventions - otherwise people would not move their mice much). In a well-designed system, this would generate exactly the same kind of behaviours as exploring with the mouse.
So we have a mouseover and a focus being the same kinds of behaviour on a web page.
The next possible step is to activate the link or button - with the mouse one generally clicks on it, from the keyboard there is a command or two to activate whatever has focus. (With Lynx I use right-arrow. With Microsoft's Internet Explorer I use enter/return)
So we have some keypress event, or some click event, which activates the element. In the model provided by Document Object Model (DOM) level 2, and adopted by Scalable Vector Graphics (SVG), there is a single activate event, which doesn't specify what kind of device made it happen.
Let's look a bit further, to a touchscreen system.
A standard touch-based web kiosk doesn't have any way of giving focus to find out about something - you either activate it or not (one reason why it is important to have links/buttons that explain what they do). The same sort of approach is used by screen and stylus type devices - the palmtop without a keyboard.
This seems weak, but there is a better way of doing what we want to do.
In the common desktop GUI operating system, a user actually clicks on something justto give it focus. From there they can activate it with another step (perhaps a second click, or pressing enter). One of the things that this buys us is the ability to do different things. I don't have to activate an icon on a desktop - I can also delete it, move it, rename it, edit it, etc.
(Funnily enough, when people were designing these systems in the 70s and early 80s touch-screens were a big thing - the way of the future. As far as I can tell the reason we settled for a mouse was just that it was cheaper. Instead of learning to draw with a mouse we learned to use magnification and autocompletion and smoothing and heaps of other assistive technologies, so the cheap little mouse stayed around. Besides, they could be dressed up and cute.)
So far we have a model where we can use highlight effects (rollovers, providing the link destination or title or both) on simple active elements, from a variety of different browsing setups. As it happens, with a model where we have an abstract set of events for triggering this, we can do the same thing in an editing environment - which is one of the things that makes it possible to build a real WYSIWYMG editor (or a WYHIWYMG editor in the case of an audio environment).
In order to provide this functionality, what have we done? We have
described a focus event (similar to the event focusin in DOM or
SVG, or the event onfocus in HTML 4 and XHTML 1), which has a natural pair for
when focus is lost (usually to reverse the behaviour, but there are other
possibilities), and an activation event (like activate in DOM or
SVG - there is no HTML equivalent).
The WAI User Agent group mailing list.
All the people who have helped me form my ideas on this, or pointed out what was wrong with them. Including
Bruce Bailey, Daniel Dardailler, Al Gilman, Philipp Hoschka, Philippe le Hegaret, Masayasu Ishikawa, Chris Lilley, Matthias Müller-Prove, Mark Novak, Gregory Rosmaita, Rich Schwerdtfeger, Ralph Swick, Jason White and the WAI PF, DOM, SVG, SMIL, HTML working groups and the W3C team.