- From: Al Gilman <asgilman@access.digex.net>
- Date: Sat, 14 Nov 1998 12:02:41 -0500 (EST)
- To: charlesn@srl.rmit.EDU.AU (Charles McCathieNevile)
- Cc: phoenixl@netcom.com, w3c-wai-ua@w3.org
to follow up on what Charles McCathieNevile said: > True table navigation would allow the user to find out where they are in > the table, and would apply either the algorithm specified in HTML 4 or > use the TABLE attributes and elements to provide additional context, such > as headers which apply ot the current cell. > > It would then enable movement to the next cell in a row or column, or > along an arbitrarily defined AXIS. > > This is the kind of implementation that would be ideal. > > A User Agent which allowed the user to navigate within a page by > element, traversing or ascending/descending the document tree, would > provide some of these functions. It would be possible to move across a > row, cell by cell, or to move up and down rows. This provides no context > information, and requires the user to remember where they are. This > strikes me as the minimum acceptable native implementation, assuming that > all the information is exposed for a 3rd party product which actually > does the job properly. Element navigation could be limited to walking the parse tree, but let us not assume it would. In the case of tables there is defined column semantics. Column traversal could also be supported as navigating the structure defined by the markup. The range of verbs available for navigation among the elments of the document, and the extent of display within the local neighborhood of the logical web around that element are mix-and-match independent channels in the composition of a solution. And it makes sense for the browser itself do do some of each. We keep bumping into methods that are feasible through what is now called style. CSS2 allows the style rule to query the TITLE of a link source and inject the TITLE text in a .before pseudo-element. Likewise if we were to define a computed pseudo-attribute I-am-a and give it a value of the closesest preceeding TH in the current column and a computed pseudo-attribute I-go-with with the value of the closest enclosing TH in the current row. This allows what has sometimes been called a readout rule to be constructed such as "The <I-am-a> of <I-go-with> is <current element contents>." The relationships defined by the document are not just the parse tree. Column membership and headers=idref attributes are examples of graph relationships beyond the tree that are clearly identified without any guessing by the markup in the document. And we can consider asking the browser to do a little guessing. There is plenty of precedent for that in successful browsers. [One tactical problem is that HTML4 fails to recognize the distinction between I-am-a and I-go-with relationships.] These relationships can be exploited as navigation paths and information retrieval channels for adaptive presentation, as Scott pointed out with his expanded presentation examples. This is just a little more of what has been demonstrated to be beneficial. Consider the examples of tool tips populated with the TITLE attribute, and the role cues of "link" etc. that clearly are a help in pwWebSpeak. Here are the sorts of things that I can imagine asking browsers to do. 1. Support a effective-headers pseudo-attribute for all table cells. This is where the guessing algorithm goes: it populates this pseudo-attribute. Effective-headers inverts the SCOPE indication and adds in guessing rules to come up with a list of the elements forming the logical neighborhood of the current [TH or TD] element. 2. Subclass effective-headers into i-am-a and i-go-with sublists. Note that row and column indications are possible values for these. For example i-am-a="column 3", i-go-with="row 7". 3. Expose the pseudo-attributes defined above so that they can be accessed from style rules as attribute values are retrieved. 4. Support this attribute-retrieval function of CSS2. 5. Support the .before and .after etc. per ... 6. Support structure navigation of row and column substructures in the context menu for any table cell. Priorities: top: next/previous in substructure mid: home in substructure (probably first; possibly key) trace about- or meta relationships (i-am-a relationships) least: pick-from-list for contents of substructure (value of query) pick-from-list for superclass tree adjust readout pattern for class of current context 7. Support enough elment navigation so that the user can navigate the current selection to an arbitrary table cell. > Charles McCathieNevile >
Received on Saturday, 14 November 1998 12:04:26 UTC