RE: SVG12: nav-* properties

Hi, Maciej-

Maciej Stachowiak wrote:
| 
| On Jun 27, 2006, at 7:06 PM, Doug Schepers wrote:
| 
| > Bjoern Hoehrmann wrote:
| > |
| > | * Doug Schepers wrote:
| > | >We have very sound technical reasons for our decision, 
| > |
| > | Glorious are the SVG WG members, who lead us to salvation, who did
| > | fight the evil that would doom us all to mortal sin. 
| >
| > Aw, shucks!
| 
| I think this may have been a hint on Bjoern's part that it would be  
| helpful to actually state the technical reasons in question, 
| not just assert they exist.


Bjoern is an invited expert to the W3C, and thus has access to the same
resources I do.  He can and does read the SVG WG list, where this has been
under discussion.  The minutes of the joint session at the Technical Planary
where this was discussed are available to him [1] (I wish I could make it
public, because it was very informative, but we aren't allowed to do that). 

In fact, he's a brilliant guy, and I'm sure that our technical reasons for
our decisions are clear to him.  Whether or not he likes them is another
matter.  He did not ask (or, as far as I could tell, even hint) for our
technical reasons, he merely pushed a point of process.  Had he asked, I
would have gladly supplied them. 

Since you seem to be asking, I'll summarize the technical background for
you. 

There are two main navigation mechanisms in question:
* linear navigation: nav-next and nav-prev
* directional navigation: nav-[cardinal direction](-[diagonal direction
modifier]), like "nav-down" or "nav-up-left"

(In addition, there are several other requirements and different mechanisms
for navigation, especially among the accessibility group, some of which SVG
also specifies. If you are curious about those, I'll be happy to discuss
them. I'm particularly interested in navigation.)

At the TP, among the concerned groups, the general consensus was that for
linear navigation, using an idRef or a URL was preferrable over the use of
numbers. Among other reasons, this means that if navigation changes, you
don't have to iterate through the entire document to change all the
navigation indices.

Similarly, the general consensus for linear and directional navigation held
that a URL, rather than an idRef, is necessary if you want keywords like
"self" as well as the URL.  This was put forth by the XHTML WG, and adopted
by the SVG WG.

As for 8-way vs. 4-way directional navigation, there were minor concerns
voiced that it might not be necessary (although we believe it is), and that
having specified the diagonals, it might be impossible to navigate to them
if the user only has 4-way capability (this is plausible, but unlikely, for
reasons stated below). 

Also, it was the opinion of a small minority that the UA should always
decide on the navigation, rather than leaving it up to the author. SVG
allows for this by the default value of 'auto' for all the nav-* attributes.
But the fact that SVG presents the geometry of shapes in a manner entirely
orthogonal to the document structure, and that the position of shapes can
change, means that SVG must have some way to allow the author some optional
control here.

Finally, we think that SVG is extremely robust and consistent in that an
author can specify either directional or linear navigation, or leave it up
to the UA to navigate the author-specified (and default) focusable elements.
This combination should allow any navigable element to be accessed.

In short, just as I said before, we have looked at all the mechanisms being
specified, chosen the most robust options, and discussed this explicitly
with the other groups.  This is why I think that we are doing the right
thing.  It is possible that some issues are not yet fully settled for full
compatibility, which is one reason that we are following up on it.  We have
done, and are doing, due diligence in the matter.

I don't think that the differences in how SVG handles navigation are either
profound or insurmountable.  If the result of further joint negotiations
(which, may I add, the SVG WG is initiating, following up on the CSS WG's
hosting at the TP) yeilds a common (but different) navigation framework
which meets all the use cases of the various groups, the SVG WG will gladly
move to that instead.  I think that the technical concepts and the shared
will are there to make this happen.  

Pending any such work, however, we believe that SVG Tiny 1.2 is robust
enough on this matter to move on.

On a personal note, Maciej, I appreciate your interest in the matter, and
the clarity and insight you bring to all your posts to this list.  
 
[1] http://lists.w3.org/Archives/Member/w3c-html-cg/2006JanMar/0115.html

Regards-
Doug

Received on Wednesday, 28 June 2006 22:28:10 UTC