- 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>
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"? cheers Chaals -- 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