Re: Comments about the 2002-08-05 XHTML 2.0 WD

  Henri Sivonen wrote:
 > Another thing that I've noticed is that (X)HTML doesn't provide any
 > semantic markup for indicating which part of the page are main
 > content and which parts are navigation.

Chris Mannall wrote:
 > In the past, maybe; now there is the nl element [4] (navigation list,
 > or "menu" in other words). If this is insufficient for your needs in
 > some way, I suggest you let the working group know.

Gabriele Fava wrote:
 > The new nl element is intended to be a replacement of javascript to
 > make "dynamic" or "pop-down" menus. What Henri was talking about are
 > the "navbar" which are so often found on the left of webpages,
 > especially at the main page.

Chris Mannall wrote:
 >I disagree. If you read the description of the nl element[1], you will
 >find that they are "intended to be used to define collections of
 >selectable items for presentation in a "navigation" menu."
 >
 >To my mind, this description covers both the dynamic pop-down menus you
 >describe and the navigation sidebars common to the web.

Note that the specification speaks about a navigation *menu*; I think 
that they really mean just menus, not bars, but we need a voice from a 
WG member.

The obligation to start with a "name" element makes me yet more tend to 
the hypothesis of an exclusive use of "nl" for top-down navigation 
menus; navigation bars indeed rarely has a name on the top, usually they 
are divided in subsections but does not have a general name; consider 
not only lateral navigation bars, but even that there are found on the 
bottom, or on top of a page (which I would include in the "navigation" 
sections proposed by Henri Sivonen); the function of title for 
navigation bars can, and should be carried by the "title" attribute.
I think that the need of the "name" element in nl is because the "title" 
attribute is usually rendered as a tooltip, and being an attribute 
cannot be controlled by style sheets.

I repeat it: we need the voice of a WG member. Drunk with CSS we run the 
risk to generalize an element which was intended for a precise task, 
ruining this way its semantic meaning.

Chris Mannall wrote:

> There are examples on the web where people have used existing CSS
> mechanisms to create dynamic menus without the use of javascript; one
> such example is Eric Meyer's demonstration [2]. Note that whether this
> works as intended depends on your browser's CSS support. It works with 
> the version of Mozilla I'm using (a recent Mozilla 1.1 release 
> candidate), but your experience may vary. Internet Explorer, for 
> example, doesn't apply the :hover class to anything other than
> anchors, and so doesn't display this correctly; it only displays the 
> top-level menus (which at least proves that this method downgrades 
> gracefully). Indeed, Eric Meyer's site does serve to highlight just 
> how far Internet Explorer lags behind Mozilla in terms of CSS support.
>
> [2] http://www.meyerweb.com/eric/css/edge/menus/demo.html

I saw Eric Meyer's demonstrations, they are very nice and interesting.
This makes me think that top-down menus could be included in the 
proposed "navigation" element as normal lists, as Meyers did, even 
because I can't see any semantic meaning for navigation *lists*, and the 
"a" elements used by Meyers are still better than "name": if a browser 
does not support some needed css there is potentially no loss if the a 
element's target page contains all the links of the sublist.

The "nl" element is to my mind just a presentational element, added just 
to contrast "evil" ECMAScript menus (css ones are not so spread) with 
some "good" equivalent W3C raccomandation.
-Most javascript menus works exactly as Meyer's css demonstrations, 
changing the visibility or the dimensions properties.

Received on Thursday, 22 August 2002 18:57:11 UTC