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

Re: Accesskey - spec proposal

From: Michael(tm) Smith <mike@w3.org>
Date: Thu, 5 Jul 2007 02:22:08 +0900
To: Maciej Stachowiak <mjs@apple.com>
Cc: Charles McCathieNevile <chaals@opera.com>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <20070704172206.GD22006@mikesmith>
Maciej Stachowiak <mjs@apple.com>, 2007-07-03 10:55 -0700:

> 2) Something that is used only on mobile-specific sites will not help us 
> design a feature for mobile devices that can browse the real web, not just 
> the "mobile web". Are any of these sites even using real HTML? My 
> impression is that Japanese mobile-specific sites are coded using a variety 
> of mutually incompatible mobile-specific languages, like cHTML, XHTML 
> Basic, XHTML-MP, etc.

That would not be an accurate description of the current state of
things in Japan, but I guess this isn't the place to go into
details about it.

The practical reality around this is that there are thousands of
content providers who are currently using accesskey in their
existing content. I would think that ideally we would want to
facilitate making that existing content usable, interoperably,
across HTML5-conformant browsers, at as little cost as possible to
the content providers (because among other reasons that gives them
a business incentive to migrate it to HTML5).

To look at it from another perspective: If I'm a browser vendor
and I  want to displace whatever existing mobile browsers (other
than their own) is already being used (preinstalled) on a
particular handset model, and want to get the money (in license
fees or search deals or whatever) that is currently going to
whatever other vendor has a deal for shipping their browser on
that handset, then I need to the support existing content that
users are already accessing today from that handset -- which most
likely means, among other things, supporting accesskey and
inputmode. Otherwise, what I am offering to provide is a degrade
in user experience over what users of that handset have now.

So if I'm a browser vendor interested in getting that business,
I'm working to make sure I support those features, and if my
competitors aren't, hey, that's great for me -- because it puts me
at a competitive advantage against them in terms of feature parity.

But since I'm not a browser vendor, what I'd much rather really
see personally is that the we come up with a spec for describing
backward-compatible-with-existing-content, interoperable behavior
for at least the existing cases where access keys are in wide use.


Michael(tm) Smith

Received on Wednesday, 4 July 2007 17:22:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:23 UTC