RE: Proposal for Changes to Keyboard Navigation

Hi, Tantek-

Thanks for the reply (twice, actually... I missed the first time you
replied, for which I apologize).

Tantek Çelik wrote:
| On 4/14/04 11:53 AM, "Doug Schepers" <doug@schepers.cc> wrote:
| 
| > The first is relatively minor: for directional navigation [1], in 
| > addition to URIs, nav-index values of elements in the 
| current document 
| > should be valid values for nav-up, nav-down, nav-left, and 
| nav-right.
| 
| This fails as soon as you have multiple elements with the 
| same nav-index value, which is allowed, just as it was 
| allowed for the tabindex.

I see my error. I missed (or misunderstood) the part that states that
nav-index is not unique. Having duplicate nav-indices seems a bit daft, or
at best klugey, but I can see a use-case for it, so I'll gladly drop this
point.


| > I recognize that this is not
| > necessarily the initial intent on directional navigation --that 
| > directional navigation was partly intended for inter-document 
| > navigation-- but this use case is particularly pertinent in SVG, at 
| > least (and probably in other host languages like HTML, sometimes).
| 
| No.  There is no difference in the use case you present.

Ok. Reading the new draft of the Spec (much more clearly worded) makes that
clear.


| > This aspect of it, admittedly, is a bit muddled... when does a 
| > directional nav key move to another document, and when does 
| it stay in 
| > the same document?
| 
| See the <target-name> value parameter for the directional 
| navigation properties.

Thanks, that resolves this issue. Please note that my original email was
posted before the current draft of the Spec; both the wording and that
particular point of confusing BNF have changed since I wrote that email.
There was a seeming contradiction (at least to me) between the <uri> and
<target-name>, but the change from <uri> to <id> clarifies it.
 

| > The second is that currently, there is currently no provision for 
| > hierarchical navigation [2] within a document. I propose that 
| > nav-index allows, as an optional value, a parameterized list of 
| > integers rather than a single integer. Each parameter would 
| act as a 
| > local index for that heirarchical "level," and would 
| require a special 
| > key sequence for navigation up or down levels. This is just one 
| > possible solution, of course, but it outlines the problem domain.
| 
| This seems far more complex than necessary, both for the 
| author and the user.

I agree. My proposed syntax is ugly, and while it made sense to me, it
doesn't seem to be clear to anyone else. I would like to see other syntax,
or a different mechanism.


| Directional navigation solves this problem handily by 
| flattening the navigation into 2d space of the rendering, so 
| the user does not have to think of going "into" or coming 
| back "out of" any particular area -- they just navigate right 
| through it.

I don't agree. You are presuming that a single document cannot have complex
nested (perhaps "modal") subsections, and for HTML, this may well be the
case; if an author wishes to have a new subdocument open, they will
typically do so in another frame, or in a pop-up, or will use a dialog box.
However, in SVG, it is common to represent this dialog within the same
document, and this is the context in which having hierarchical navigation
makes sense and is desirable. I believe that this same issue would also
appeal to those browsing the Web on mobile devices with small screens and
more limited navigation options.


| > In addition, a special cue (visual,
| > and/or aural, and/or whatever) should be given when hierarchical 
| > options exists.
| 
| I can see this possibly making sense for "CSS-VR" styling 
| scenario, but since such features have yet to be 
| defined/designed, it seems premature to discuss 3D navigation 
| details, though I can see it eventually being interesting to 
| talk about.

Again, I disagree. But this may be outside the current scope of CSS, which
focuses on the traditional HTML document system, so I reckon it's a moot
point.

Regards-
-Doug

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 6/30/2004

Received on Saturday, 3 July 2004 09:59:14 UTC