- From: Charles McCathieNevile <chaals@opera.com>
- Date: Mon, 28 Jan 2008 18:39:25 +1100
On Mon, 28 Jan 2008 10:02:26 +1100, Matthew Paul Thomas <mpt at myrealbox.com> wrote: > Michael(tm) Smith wrote: >> >> Jerason Banes <jbanes at gmail.com>, 2008-01-25 23:41 -0600: ... >> Another long story short: accesskey mark is already in use in a >> significant amount of existing content, so leaving it unspec'ed >> for implementors does not seem like a practical option -- not if >> we care about trying to ensure that behavior of that content is >> consistent/ interoperable across UAs. > > But that's precisely the problem: accesskey= *can't* be consistent and > interoperable across UAs, or even across browsers, because browsers > compete (amongst other things) on their user interfaces, and therefore > they have different user interfaces, and therefore they conflict with > different values of accesskey=. If that problem had a good solution, > removing the attribute would not have been necessary. The problem does indeed have a god solution, which is to remove the stupid suggestion about the activation behaviour (alt/cmd/etc) in the spec. iCab, Opera, Amaya and Firefox have already implemented something intelligent that lets you avoid conflicts. > The specification could include an explicit statement of the form "UAs > must ignore the accesskey= attribute", but any such statement would be > in the yet-to-be-written "Rendering" section. And an unimaginatve and unintelligent approach anyway. >> ... >> Most handsets don't have keyboards or real pointing devices that >> let you quickly point and click on links; instead they just have >> numeric keypads and "5-way" directional pads that are basically >> the equivalent of arrow keys plus an enter key/mouse button. >> >> In the context of delivering content to those devices, it's useful >> to provide numbered access keys for quick access to certain links >> on a page -- to save users the time and trouble of needing to use >> the 5-way on the handset to scroll to the links and activate them. >> ... > > Since most pages that contain links don't also use accesskey=, handset > vendors should find a way to allow easy navigation of links regardless > of whether the attribute is present. They do. However, accesskey, which is to primarily designed to give an increased navigation priority to certain links, is very useful for handsets, and not actually very complicated to implement, in a way that is consistent with the existing markup. It might not be the same across all implementations, but there is very little restriction needed to make an implementation compatible with almost any imaginable UI. And all of this has been proposed before, implemented by people in various ways in javascript or via proxy-based scripting as well as in user agents, and is hardly rocket science. http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html gives you a set of implementation techniques, links to a set of minimal changes required to the spec, etc. (There is more that could be done in an advanced implementation, but it isn't really complicated). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Received on Sunday, 27 January 2008 23:39:25 UTC