- 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. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/
Received on Wednesday, 4 July 2007 17:22:15 UTC