Re: 'nextFocus' attribute -- lift it to a 'tour' structure

Al,

In HTML4, there were two options for link traversal: either accept the  
linear order as implied by the structure of the document, or, even if you  
only wanted to reorder two links, number every link in the document to  
give the required order, and keep that up to date every time you added a  
link.

The proposal for XHTML2 is to just mark (pairs of) links that don't follow  
the implied document order, which for authoring is an order of magnitude  
easier to do, and trivial to keep up to date. I would strongly disagree  
that it is just as view-specific as fontFace is, because it is simply  
layering an alternate navigation structure over the implied structure.

As I understand it, you are proposing to take reinstate the old method,  
but out of line from the document (a sort of metadata). I understand that  
this would make different orders possible, but I disagree with your claim  
"There is no one universal tour for a given content structure." Personally  
I have never had the need for other tours than the default one, let alone  
different ones for different views. I can understand that there may be  
occasions where other tours are needed, but not in the absolute way that  
you claim.
It is certainly not clear to me that your proposal "is more efficient than  
the solution in the present draft and at the same time more robust  
(resistant to author errors where one element in middle of tour is dropped  
in edits)."

It seems that to achieve what you are proposing, a value for the proposed  
"role" attribute could be applied to existing <nl> elements, and achieve  
the same effect.

Best wishes,

Steven Pemberton

Al Gilman <Alfred.S.Gilman@IEEE.org> wrote:
> http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_nextfocus  
> Summary of as-in-draft:
> Transitive closure of nextFocus arcs defines one tour hardwired into
> the content.
>
> Feature replaced:
> http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex
>
> Recommeded alternate strategy:
> Tours to be implemented by out-of-line structures collecting references
> to tour stops.  This strategy covers both
> - hierarchical intrapage navigation with author-nominated hotspots and  
> branches
> - simple linear tours ordering author-nominated hotspots.
>
> The latter case can be covered by a <tour> element with an
> attribute of type IDREFS that lists the tour stops in order.  This is
> more efficient than the solution in the present draft and at the same
> time more robust (resistant to author errors where one element in
> middle of tour is dropped in edits).
>
> It is also architecturally better, as tours are view-specific, best if  
> adapted
> to the delivery context.  The 'nextFocus' attribute is view-specific just
> as fontFace is.
>
> Discussion:
>
> Tours are functionality that should adapt to the delivery context.
> There is no one universal tour for a given content structure.
>
> The best tour for an eyes-free user (such as a screen reader user) is
> likely a breadth-first walk of the page Table of Contents.  This
> resembles the left nav bar which is a tour of the vicinity abstracted
> using the structure of the site map.
>
> The best tour for a high-input-event-cost user (such as a switch
> user) is likely a sweep of all activatable element in descending
> order of click-through frequency as determined from the server logs.
> This resembles the right highlights bar which is a tour of the vicinity
> in a concept net topology.
>
> Strategy:
>
> So the behavior should be cast in the standard framework.
>
> A tour is a selection and ordering of tour stops with iterate and
> optionally initiate methods.
>
> In this way a tour is cut from the same cloth as the 'find,' findNext'  
> service.
>
> The declarative part of a tour is
>
> a) an order-significant list of the tour stops -- this can be one
> attribute of type IDREFS b) a 'nextInTour' event bound to this list
> c) [optionally] a 'startTour' event bound to this list.
>
> The initial default navigation behavior is defined by the XHTML 2.0
> specification by a standard reference method that handles the events
> declared above and computes where to go based on the current focus
> and the list defining the succession. But this means that this is not
> the only possible behavior.
>
> This construction allows multiple tours to be defined and
> communicated by the author.
>
> It allows the User Agent and/or AT to replace the author-nominated
> tour through the established event capture mechanism [to be confirmed
> by careful review].
>
> Al
>
>

Received on Wednesday, 20 October 2004 13:42:33 UTC