Re: Proposal for Keyboard Shortcuts for HTML5

At 00:07 -0700 UTC, on 2007-09-22, Maciej Stachowiak wrote:

> On Sep 21, 2007, at 10:52 PM, Sander Tekelenburg wrote:
>
>> Sounds awfully semantic to me. Wouldn't it be better if HTML would
>> allow authors to mark up such *meanings* [...]
>
> It might be useful to do this for common commands, but many
> interesting application commands are not common to other types of
> applications, so are unlikely to be predefined.

Perhaps you can expand then on the sort of use cases your proposal targets? I
mean, you mentioned web mail, and a "compose new message" command. Such a
command is likely to be in every web mail client, so it seems obvious to me
that it would be useful if the key combo for that command would be the same
across web mail clients. So your example suggests the opposite: that there
are likely many functions that are common across web apps, which would thus
benefit from being recognised as such by UAs.

[...]

> For individual applications that get used a lot, the
> common operations are likely to include some of the unique ones. So
> even if we find some set of operations that could get common
> shortcuts, I think a normal shortcut key facility would still be useful.

Sure, we agree. There's no way we can predefine all possible cases. But I
suspect that many will be common, and it would be of great benefit to both
users and authors if HTML would define those; leave the authoring problem of
thinking of good accesskeys, and the inconsistency-across-sites problem, to
just the cases that are so unique that that's the only way to handle them.

>> If the same key combo works
>> across sites, it would be picked up by many more users. It would
>> also be a
>> much bigger incentive for authors, which in turn would mean more
>> users are
>> being served.
>>
>> (I haven't really thought about what syntax this would require.
>> @role might
>> be appropriate, but I'm just going by its name; I haven't looked
>> into @role.)
>>
>> The main problem with this would be that with a predefined set of such
>> "roles", there could still be cases where authors wish to provide
>> keyboard
>> access to non-predefined "roles". I'm not sure what might be a good
>> approach
>> to handle that. Possibly the old @accesskey can be upgraded to serve
>> those
>> special cases. But even there I'm not sure... I used to be an
>> @accesskey
>> advocate, but in the last few years I've gotten more and more
>> convinced that
>> it just isn't a good idea at all to let authors define key combos.
>> That's the
>> exact opposite of what I advocated at
>> <http://www.euronet.nl/~tekelenb/WWW/LINK/> (where the main point is
>> "consistency across sites"). So perhaps better would be to also have
>> one
>> generic "role" that authors use for non-predefined "roles", and let
>> UAs
>> assign 'any' key combo to that that is still available.
>
> Sounds complicated to me.

You're quoting so much that it isn't clear to me exactly *what* sounds
complicated to you.

[...]

>> Btw, I'm sure you're aware of iCab's accesskey implementation:
>> showing the @accesskey value right after the element.
>
> I wasn't aware of it, and I don't see it working in iCab 3.0.3. This
> is my test case: <input accesskey="a">

Hrmpf, you're right. It does so for <a>, but not for <input>. Might be a new
bug. It does work for <label> though: <label accesskey="a" for="id">a
label</label><input id="id">.

[...]

> In general adding stuff
> to the visible page contents is likely to discourage authors from
> using the feature.

Yes, that's an issue with this approach. Moving things to the chrome might
well have a better chance at succeeding. Then again, UA vendors have shown
almost no interest in similar chrome opportunities when it came to <link>,
let alone <a rel=>. Why would they now suddenly see that light? And why only
for something as (comparatively) limited as document-specific accesskeys?

[... @accesskey in iCab]

> Using a non-default preference setting doesn't sound like a win for
> discoverability either.

In iCab it used to be the default for many, many years. It only quite
recently became an option, and off by default. I don't know why. Possibly
because too many web publishers treat the Web as WYSIWYG, and the additional
content messes up their design. Moving this to the chrome could solve that.

>> I tend to agree, and think this is a strong argument for providing a
>> means to
>> semantically indicate an element's function, and let the UA assign the
>> appropriate key combo; not leave that to authors.
>
> I'm dubious, mainly because I don't think a reasonable-sized list
> could cover enough commands to work for a wide range of web apps.

Could you elaborate on that range of web apps? List use cases?

I mean, stuff like <a rel="home" accesskey="h" href="/">Home</a> probably
applies to well over 99.9% of webpages. In fact, UAs could assign an
accesskey based purely on the rel value, even when there is no accesskey
attribute. In fact, UAs could make <link>s and <a rel=> available in the
chrome, easily discoverable and displaying keyboard equivalents.

Such things would cover keyboard shortcuts for a *lot* more cases than
document-specific commands.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Sunday, 23 September 2007 05:53:36 UTC