Re: Navigation Lists Lack Adequate Structure and Other Thoughts on Navigation Lists

(originally posted to www-html-editor.  Seems to me, it really belongs 
here instead.)

R. Douglas Ezell wrote:
> In my opinion, Navigation Lists in the current XHTML 2.0 Working Draft 
> lack adequate structure for the real world.

I think they have more than enough.  The only problem with them that I 
can see is the introduction of a required label element.

The common implementation for navigational lists in html4 look 
something like this:
{{{
	<ul class="menu">
	 <li>regular item</li>
	 <li class="hasSublist">
	  item with sub-list
	  <ul>
	    <li>sub-list item</li>
	    <li>sub-list item</li>
	  </ul>
	 </li>
	</ul>
}}}

This is a lot less markup than your suggestion, but gives the same 
functionality.  The top-level list items are presented in flow when the 
page loads, and those items with class "hasSublist" show their embedded 
lists when clicked or hovered.

I think it would be best to base the new nl structure on this common 
approach; authors would then be encouraged to use the new element 
because of it's familiarity, rather than being discouraged by the extra 
markup required by your model.

The xhtml 2.0 markup would look like this:
{{{
	<nl>
	 <li>regular item</li>
	 <li class="hasSublist">
	  item with sub-list
	  <nl>
	    <li>sub-list item</li>
	    <li>sub-list item</li>
	  </nl>
	 </li>
	</nl>
}}}
Alternately, <li class="hasSublist"> could be replaced by a new <li-x> 
element, with the same properties as li (but this is probably 
overkill).

Notice that this model does not include the label element.  It's not 
needed, and thus _should not be required_ by the minimum content model.
Making it required is a bad idea for two reasons.  Firstly, it 
deteriorates the similarity between nl and the old ol and ul models.  
Secondly, the purpose of the label element becomes unclear.  In the dl, 
ol, and ul models, the obvious use of the label element would be 
similar to the caption element for tables -- as an extra (optional) bit 
of description of the rest of the content.  Making it required in the 
nl model suggests that it's meant to be something more important in 
this context.  The use suggested by the example in the specification 
seems to be to hold the "item with sub-list" string -- taking the role 
as both a descriptor of a sub-list _and_ as an item in the parent list. 
  However, most navigational list implementations require the ability to 
show and hide the sub-list without effecting the main document flow 
(using absolute positioning), while keeping the entry in the parent 
list in the normal flow.  This is very difficult to accomplish using 
the current proposed structure using labels (since the label is 
_inside_ the nl block, unlike the text in the example).  Because of 
this, if author's are forced to use the current model, they will likely 
either end up with duplicate information (putting the same string 
inside the label, and outside of the nested nl) or with empty label 
elements

That being said, I don't think the label element is completely useless. 
  In fact, I would like to see it made available in more contexts, and 
perhaps with an added for="IDREF" attribute like that from the old 
forms markup.  Just don't make it /required/ in any context.


> My primary complaint with this structure is that it lacks a dedicated
> containing block for a navigation list's list items.

Once the label element is removed, the "dedicated containing block" 
you're looking for is already available -- nl.


> I also feel that the li element is not appropriate for use for the 
> navigation list items.

There aren't enough good reasons to make a new element, considering the 
benefits of using li.  Keeping li keeps the nl list parallel to the 
other list-types, making it easier for both authors and agents to use.  
Furthermore, it allows developers more leeway to use nl for purposes we 
may not have thought of yet (as they did with the original ul).


> Furthermore, I feel that conformance requirements should demand that 
> conforming user agents have the navigation list act in a certain way 
> by default.

How an element "acts" is out of the scope of xhtml.  Of course, the nl 
should have sensible CSS rules attached to it by default (li items 
within an nl would have list-type:none, and might show some response if 
hovered or focussed for example), but you can't require a conforming UA 
to be able to provide pop-up menus in order to use the list module...  
The nl element should render nearly identically to other list types, 
with all of it's content visible immediately, unless the author 
specifies otherwise with XML Events and CSS.


--Maxwell Terpstra

Received on Saturday, 21 May 2005 06:56:47 UTC