Re: Navigation Lists

>>> 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.

Why would NL provide a special widget? Every element (and attribute) can
be described in terms of CSS. That is the goal, at least. I believe that
the COLSPAN and ROWSPAN attributes still need to be addressed in some
draft and that FRAME and FRAMESET elements can't be described completely
either, because of the "special" COLS en ROWS attributes from the
FRAMESET element.

(Forms are also a major issue.)

But those are edge cases. Most things from HTML 4.01 can be described
using CSS which means that predifined presentation should only be done
using CSS and not beyond that.


> 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.

Behavior can probably be done using XBL[1], a language currently in 
development and of which no public W3C Working Draft is available as of yet.

XHTML 2.0 works also together with XML Events[2] and another language 
(XML Handlers) is currently in development[3].


> 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.

Not everyone will use them, but those who care about semantics will. As 
I mentioned, they do have benefits over using (nested) UL elements for 
navigation.


> 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?

Not really. I think the examples shown on the MSDN site can already be 
accomplished using CSS and HTML. Perhaps some behavior, since you may 
not only want ':hover' and ':focus', but let them react on other events 
as well, such as mouse clicks.

I believe I have actually seen such menus before, created using UL 
elements, a bit of styling and some JavaScript, but I can't find the 
link at the moment.


[1]<http://www.w3.org/TR/2001/NOTE-xbl-20010223/>
    <http://hixie.ch/specs/xbl/>
    (This will be submitted to the W3C IIRC.)
    <http://www.mozilla.org/projects/xbl/xbl.html>
[2]<http://www.w3.org/TR/2003/REC-xml-events-20031014/>
[3]<http://lists.w3.org/Archives/Public/www-html-editor/2004JulSep/0062.html>


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

Received on Thursday, 5 August 2004 01:07:14 UTC