Re: @accesskey and multiple characters

On Wed, 22 Jul 2009, Hallvord R. M. Steen wrote:
> when Ian added the @accesskey definitions to the spec (as currently defined in
> [1] ), he said in an E-mail [2]:
> > For future extensibility, I have also required tokens with more than 
> > one character to be ignored for now. We can later add identifiers for 
> > various purposes, e.g. accesskey="help" to mean that the user agent's 
> > default"help" key should be used, whatever that is.
> This unfortunately rules out using @accesskey as a replacement for 
> certain things sites are already doing with JS - the example I have in 
> mind is GMail's "gi" shortcut for going back to the inbox. I don't know 
> if this is more important than the potential future extensibility. I'd 
> lean towards allowing multi-character shortcuts since they are already 
> used and using a <command>+@accesskey construct could make GMail more 
> accessible to AT UAs..
> [1]
> [2]

Assuming the proposal is to make accesskey="" with multiple-character 
values set up key sequences (as in Emacs key bindings), and that this is 
not currently supported in browsers (which I don't think it is -- correct 
me if I'm wrong), then I think we should probably wait until the browsers 
have implemented what is specced so far before adding this new feature.

It seems reasonable in principle, though, and the current extension model 
could allow for that just as it could allow for keywords. We could even do 
both, e.g. by chaining keywords or letters with hyphens, as in "C-S" or 

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 1 August 2009 09:28:26 UTC