- From: R. Douglas Ezell <rdouglas@iglou.com>
- Date: Tue, 27 Jul 2004 11:02:23 -0400
- 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