Re: Navigation Lists

Anne van Kesteren wrote:

>> After all, a validating XHTML 2.0 document could contain the entire
>> contents of the w3c.org within a single li element.
>
>
> What is specifically wrong with that? I know a site for example[1] 
> that has a FORM element embedded in a LI element. Some people may say 
> it is not very useful, but it is inventive and there is no other way 
> of doing this if the contetns of the LI element were restricted in any 
> way.
>
There is nothing wrong with that in the case of ol and li list items. In 
the case of a nl element, which would probably be implemented by visual 
user agents as a special widget like input and select elements, it will 
be easier to implement support for a more limited content model. 
Furthermore, a more limited content model for navigational list items 
would encourage authors to build more usable and accessible navigation 
lists.

>> 2. Do you know of any work for specialized css selectors and rules
>> for the nl element? There needs to be a way for designers to specify
>> the direction and alignment of a nl element's pop-up menu on visual
>> user agents, or the element will surely die. If they only drop down
>> and to the left, designers will have no other option than to use
>> scripting to modify this behavior, and all we will have gained are a
>> few new elements with which to apply the standard DHTML menu creation
>> techniques already in use.
>
>
> I don't see the point you are trying to make here. Why are special CSS 
> selectors needed? A List Apart has for example tutorials on 
> vertical[2] and horizontal[3] dropdown menus. Perfectly structured 
> using some JS and CSS workarounds to work around limitations of 
> certain browsers.
>
> Since XHTML 2.0 was never meant to be backwards compatible you 
> probably won't need scripting at all in newer browsers.

>
>
>> 3. Will the w3c actually place sufficient requirements on the
>> behavior and other implementation details to help assure that
>> navigation lists can be navigated with mice, keyboards, and other
>> means? I dread that navigation lists will become anathema due to lack
>> of adequate conformance requirements.
>
>
> Why exactly? I think that the web author is responsible for this by 
> making sure his lists are using both ':hover' and ':focus' for example.
>
>
>> 4. Will the w3c actually place sufficient requirements on the
>> behavior and other implementation details to help assure that
>> navigation lists do not become ugly and inflexible widgets? I dread
>> that navigation lists will become anathema due to lack of adequate
>> conformance requirements.
>
>
> There are multiple sites that have implemented the solutions A List 
> Apart provided[2][3] successfully, the only thing XHTML 2.0 does is to 
> create a specific element for navigation menus instead of the UL 
> element everybody (who is aware of standards and such) is using now.
>
> This will make it much easier for browsers to skip the navigation and 
> head straight for the content. Search engines can distinquish between 
> a normal list of links and the site navigation. Et cetera.
>
>
> [1]<http://mezzoblue.com/>
> [2]<http://www.alistapart.com/articles/dropdowns/>
> [3]<http://www.alistapart.com/articles/horizdropdowns/>
>
If navigation lists merely provide elements to make navigation in a page 
more semantic, that's fine. If navigation lists are also supposed to 
replace complex DHTML pop-up menus, then they require mechanisms that 
would provide at least some of the control over their behavior that 
authors now exert using DHTML. If navigation lists do not provide 
authors with a simpler and nearly as robust alternative to DHTML menus, 
I fail to see why an author would use them at all.

I noticed you did not object to my main concern that the list items in 
navigation lists need a dedicated containing block equivalent to the 
actual drop-down-menu or sub-menu. Does that mean you think that 
navigation lists need this structure?

Received on Thursday, 5 August 2004 10:34:17 UTC