W3C home > Mailing lists > Public > www-html-editor@w3.org > July to September 2004

Navigation Lists Lack Adequate Structure and Other Thoughts on Navigation Lists

From: R. Douglas Ezell <rdouglas@iglou.com>
Date: Tue, 27 Jul 2004 11:02:23 -0400
Message-ID: <41066E7F.3090201@iglou.com>
To: www-html-editor@w3.org

In my opinion, Navigation Lists in the current XHTML 2.0 Working Draft 
lack adequate structure for the real world.
Currently, the structure looks like this:
<nl><!--Navigation List Start Tag-->
    <label>Content</label> <!--To be seen on default, like a menu button-->
    <li href="#intro">Introduction</li> <!--hidden on default, first 
navigation list item -->
    <li>
       <nl> <!--Nested Navigation List-->
          <label href="#ch1">Chapter Onew</label> <!--second navigation 
list item, revealed when first the other first children of the root 
navigation list is revealed-->
          <li href="#ch1s1">Section One</li> <!--first navigation list 
item in a nested navigation list item, apparently hidden until it's 
navigation list recieves focus-->
          <li href="#ch1s2">Section Two</li>
       </nl>
    </li>
</nl>
My primary complaint with this structure is that it lacks a dedicated 
containing block for a navigation list's list items. Without a dedicated 
containing block for the navigation list items it becomes impossible to 
address the pop up menu directly to control its visibility or display, 
and its position. Addressing each of the navigation list's list items to 
control their properties becomes a cumbersome exercise at best.

In writiting an XSLT stylesheet to convert XHTML 2.0 into HTML I have 
found it necessary to create a dedicated containing block for the 
navigation list items by either 1: removing the label from the 
navigation list in the output so that it may become the containing 
block, or 2: creating a dedicated containing block in the output. With 
option 1, the pop up menus are addressable by pointing to the navigation 
list, but the positioning of the navigation list becomes problematic. 
With option 2, the pop up menus are not addressable unless you know the 
hack, but the root Navigation List can act as a positioning container so 
that positioning the pop ups is a relatively simple matter. This is 
extremely useful when dealing with nested navigation lists. I feel that 
if the XHTML 2.0 language included a dedicated for the navigation list's 
list items, that it would solve all of these difficulties.

I also feel that the li element is not appropriate for use for the 
navigation list items. The li element has a content model of  (PCDATA | 
Flow)*, and rightly so since its use in other lists would be severely 
hampered if it was limited further. A navigation list item should have a 
much more restricted content model, I would recommend text or nl or hr 
only. Images as customarily seen in such menus could be applied through 
stylesheets as list items, separating content from design quite 
elegantly. I would also specify that this text content not wrap, as a 
navigation list item that spans more than one line is simply ugly. 
Perhaps ni for navigation item would prove a better suited alternative. 
Furthermore, with list item style set to none, the navigation item's 
content should still be indented as though there were a 1em image at the 
beggining of it.

The label element also seems rather ill suited to me on a purely 
aestetic basis. The head of a navigation list is not like the label of a 
form. Which brings me to my preffered paradigm for a navigation lists. A 
navigation list can follow the tried and true head and body structure.

<nl><!--Non-Nested Navigation List, acts as containing block for the 
absolutely positioned navigation body.-->
    <nh>Content</nh><!--Navigation Head, Visible by default-->
    <nb><!--Navigation Body, Hidden by default -->
        <ni href="#intro">Introduction</ni><!--Navigation Item-->
        <ni>
           <nl> <!--Nested Navigation List-->
              <nh href="#ch1">Chapter Onew</nh>
                 <nb><!--Nested Navigation Body==>
                    <ni href="#ch1s1">Section One</ni>
                  <ni href="#ch1s2">Section Two</ni>
                 </nb>
           </nl>
        </ni>
    <nb>
</nl>

If you tried implementing the navigation list in the working draft and 
implementing the navigation list I present, I am extremely confident 
that you would agree that mine is easier to implement. Furthermore, it 
is easier to address that which you want to address in scripts and 
styles. Finally, the more restricted content model will make it easier 
for implementors to anticipate what people may put inside a navigation 
list, and to build thier implementations accordingly.

Furthermore, I feel that conformance requirements should demand that 
conforming user agents have the navigation list act in a certain way by 
default. I personally preffer the behavior of menus according to the 
guidelines set forth by microsoft. However, the power users trick of 
opening a menu on mousedown and activating a menu item on mouseup would 
require that the navigation list and its contents are not selectable as 
any part of a text range. Basically, using the structure I laid out:

1. If a non-nested nl element list's nh element recieves focus or 
onmouseover, it indicates readiness for activation. On mouseout or 
losing focus, it returns to it's default state.
2. When a ni element with an href attribute recieves focus or 
onmouseover it should indicate readiness for activation. On mouseout or 
losing focuse, it returns to it's default state unless it also contain's 
a nested nl element.
3. When a non-nested nl element's nh element is activated or 
onmousedown, that navigation list's nb element is displayed. The page's 
navigationListActiveState is set to true.
4. When a nested nl element's nh element recieves focus, or onmouseover, 
it's nb element is displayed.
5. When a nested nl element loses focus, or an onmouseover event occurs 
for any of the ni element's of it's ancestors (save for it's parent ni), 
its nb element and all of it's nb element's contents are hidden 
(including nested nb elements that may have been revealed), and it's 
containing ni element is returned to its default state.
6. When a non-nested nh element recieves focus and 
navigationListActiveState is true, any revealed nb element's and their 
contents are hidden. The nb element that is the sibling of the nh 
element that received focus or an onmouseover event is then revealed.
7. When an ni element with an href element is activated or receives an 
onmouseup event, navigationListActiveState is set to false and any 
instructions from the ni's href attribute are executed. (nb elements 
must stop the propagation of onmouseup, onmousedown, and onmouseclick 
events).
8. When the document body receives an onmousedown event or an element 
that is not an nl receives focus, navigationListActiveState is set to false.
9. Whenever navigationListActiveState is set to false all nb elements 
are hidden.

This format allows navigation lists robust features. It is possible to 
switch from one nl element to another without extra activations or mouse 
button use, allowing for menubars composed of many nl that function the 
same as menus in most environments. Also notice that an nl element's 
revealed nb element's stays open even if the user strays its mouse 
outside of the element. You should be able to click on an ni element 
that has no href attribute to your heart's content without closing the 
navigation list. Power users can perform a mousedown to open the menu, 
move to their selection, then perform a mouseup to activate an item. A 
user can mousedown an ni with an href, move the mouse away from the ni 
element, do a mouseup, and have no action taken.

I also feel that it should be required that nh elements can have focus. 
nh elements with attributes dealing with focus should be required to 
have these attributes work like any other item that can recieve focus, 
even if they do not have an href attribute (I would ban any nh from 
having an href attribute).

A way to navigate navigation lists without using a mouse should also be 
required.

An attribute for determining how a navigation list pops out would also 
be nice, eliminate the need for on this tricky positioning issue CSS, or 
add it to CSS and have this tricky positioning issue resolved with much 
simpler CSS. <nb pop-out="down, right"> or nb{navigation-pop-out:down, 
right;} could make the nb body drop down and align it's left edge with 
the left edge of its sibling nh. I imagine values of "(up | down | left 
| right | auto(default)), (up | down | left | right | center | 
auto(default)).

A mode attribute or css attribute could provide a way to determine 
behavior of navigation lists. For instance, <nl mode="hover"> or 
nl{nl-mode:hover;} could change the application environment behavior I 
outlined to the more common hover behavior as done on the netscape 
devedge site.

Only with this sort of simplicity and flexibility will navigation lists 
become a killer feater for web sites.

Well, I have probably talked your ear off about my thoughts on 
navigation lists. I'll leave you with my favorite quote from the current 
zip file version of the working draft:

"If the nl <mod-list.html#edef_list_nl> element is de-selected, it's 
contents are removed from the display." (That would include the label of 
the nl element... think about it.)
Received on Tuesday, 27 July 2004 11:05:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC