W3C home > Mailing lists > Public > public-html@w3.org > September 2007

@role etc Re: Proposal for Keyboard Shortcuts for HTML5

From: Charles McCathieNevile <chaals@opera.com>
Date: Mon, 24 Sep 2007 04:27:17 +0200
To: public-html@w3.org
Cc: "Dan Connolly" <connolly@w3.org>
Message-ID: <op.ty4zrrbfwxe0ny@widsith.local>

Hi Sander,

it seems we are moving towards consensus here... Things we agree on are  
snipped below.

On Sun, 23 Sep 2007 19:30:13 +0200, Sander Tekelenburg <st@isoc.nl> wrote:

> At 13:08 +0200 UTC, on 2007-09-22, Charles McCathieNevile wrote:
>> On Sat, 22 Sep 2007 07:52:33 +0200, Sander Tekelenburg <st@isoc.nl>

>>> Sounds awfully semantic to me. Wouldn't it be better if HTML would  
>>> allow authors to mark up such *meanings*, and leave it up to the
>>> UA to provide the appropriate keyboard shortcut?...
>> This is indeed the sort of thing that @role is designed for - and in
>> particular the extensibility of @role was meant to cope with such a  
>> case.

There are, as you have noted elsewhere, other existing constructs that do  
some of the same things. @rel is implemented (in extensions of natively)  
in most browsers, so there is a single way in a given browser to activate  
all "next", "index", etc links that have a defined @rel.

There is also an extensibility mechanism in HTML 4 based on the profile  
attribute. It isn't very clearly specified in HTML 4 how this should  
actually work. It provides identifiers that you can use, but no way to  
avoid clashes between two profiles and no way to automatically discover  
anything about a given profile. From time to time people have suggested  
this is useful for stuff like microformats (although the microformats  
community seem to be happier with a centralised authorty model) as well as  
values for rel. But as far as I know the GRDDL folks are the only ones who  
have done much that is useful with @profile. DanC could probably comment  
usefully here.

> Thanks. OK, so @role, or something similar, then seems to be something to
> seriously consider for inclusion in HTML5. (But I seem to remember there  
> are objections?)

The major problem people have with @role is that its current flavour uses  
namespaces for the attribute (it is iportant that it work in SVG (and  
potentially other XML languages) and that the values themselves use  
namespaces (to allow for decentralised extensibility).

>>> 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".
>> The current design of role allows for this with extensibility. But there
>> is a proposal on the table with a lot of support that in order to have
>> @role in HTML 5 it would lose the xtensibility
> Sorry, I can't follow that last sentence. What proposal, on which table,  
> and what "support"? (By parties?)

ARIA as currently specified[1] relies on namespaces. For text/html we need  
to remove those from the attribute name somehow (or convnce us browser  
venors to implement namespaces again in HTML, and having been there we  
think that is a bad idea in general). But the use of namespaces for the  
value of the attribute is also seen as problematic - it complicates  
programming and use. On the other hand, without it any new role (video  
control buttons, webmail functions, adding friends, ...) relies on some  
standardisation method to avoid clashing, which compromises extensibility.

Some people hate namespaces, some think they are a relatively good  
approach to solving the name clash problem that extensibility potentially  
brings. The question is really "where is the sweet spot between simplicity  
and power that leads to the widest interoperable usage"?



   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)
Received on Monday, 24 September 2007 02:27:35 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:22 UTC