W3C home > Mailing lists > Public > www-style@w3.org > October 2005

Re: Styling by attribute-based association?

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Fri, 28 Oct 2005 05:02:21 -0400
Message-ID: <4361E91D.1080106@earthlink.net>
To: Andrew Fedoniouk <news@terrainformatica.com>
CC: www-style@w3.org

Andrew Fedoniouk wrote:
> From: "Matthew Raymond" <mattraymond@earthlink.net>
> | Andrew Fedoniouk wrote:
> | > Matthew, apply :
> | > <style>
> | >    li > nl > li { display:none }
> | >    li > nl > li > label { display:block }
> | >    li[open] > nl > li { display:block }
> | >
> | >    li > nl { backround-image: plus.png; background-repeat: no-repeat;
> | > background-position: 3px 3px;}
> | >    li[open] > nl { backround-image: minus.png }
> | > </style>
> | >
> | > To the following:
> | >
> | > <nl>
> | >     <label>Contents </label>
> | >     <li href="#introduction">Introduction</li>
> | >     <li>
> | >        <nl>
> | >            <label>Terms</label>
> | >            <li href="#may">May</li>
> | >            <li href="#must">Must</li>
> | >            <li href="#should">Should</li>
> | >        </nl>
> | >     </li>
> | >     <li href="#conformance">Conformance</li>
> | >     <li href="#references">References</li>
> | >     ...
> | > </nl>
> | >
> | > and you will get something close to collapsible trees.
> |
> |   What does this have to do with menus or the problems with having
> | label as a child element that I mentioned in my previous message? (Also,
> | note that there is no |open| attribute in the current draft of XHTML2.)
> 
> I don't understand your problem with nl's.

   Well, what specific menu markup I support is more a topic for the
WHATWG list. What I'm concerned with here in the www-style list is the
problems with styling a menu label that's a child of a submenu.

> Write it as:
> 
> Contents:
> <nl>
>    <li href="#introduction">Introduction</li>
>    <li>Terms
>       <nl>
>           <li href="#may">May</li>
>           <li href="#must">Must</li>
>           <li href="#should">Should</li>
>       </nl>
>    </li>
>    <li href="#conformance">Conformance</li>
>    <li href="#references">References</li>
>    ...
> </nl>
> 
> And you will have labels out of NLs. Why do you need caption of the group to be
> exaclty <label>?

   You'd end up with an inconsistency of how menus are handled versus
submenus. While an <li> parent element can be considered the label for
an <nl> submenu, the same is not the case when there is no existing <li>
parent. At the top level of the menu system, there'd need to be some
kind of label mechanism to act as a target for the user to click on, and
for consistency sake, the same element should be used for submenu labels.

   Also, as I believe I mentioned before, there are situations where you
might want to call the same submenu from two locations in the menu
structure or UI without duplicating the markup. This is where a label
with some kind of |for| attribute would come in.

> Side note #1:
>   There is a funny note in the XHTML 2.0 (list module, nl's):
>   "Note that a navigation list always starts with a label element that defines
> the label for the list."
>   What this means: "Must start" or "May start" ?  What if it does not?

   Labels should be required, because you might have tear-off menus in
some environments. However, that doesn't mean a label _element_. It
could just mean an attribute. In fact, it may be useful to have a one
label in the parent menu and a slightly different one for the torn-off
submenu.

> Side note #2:
>   True, |open| is not there. I am using it instead of inventing new state flag
>   like :collapsed or so. Interesting question, btw - either attribute either
>   flag should be there. Without it how to style collapsed / open states?

   You're assuming states that have more to do with UI than semantics.
HTML is a semantic language. The user agent can render markup as
virtually anything. It could render a list as 3D models of Playboy
bunnies in a virtual hot tub. Forcing specific UI for a semantic
language suppresses innovation.

> Side note #3:
>    "Navigation lists are intended to be used to define collections
>     of selectable items for presentation in a "navigation" menu"
> 
> And what is wrong with:
> <ul>
>     <li href=url>something #1</li>
>     <li>something #2
>         <ul>
>            <li>something #2.1</li>
>            <li>something #2.2</li>
>        </ul>
>     </li>
> </ul>
> 
> Any ideas why <nl>s were introduced?

   Navigational lists are common in HTML now, even though there aren't
any semantics for them. It makes sense to have a proper list type for them.

> Does <nl> has some special UI behavior like collapsible nodes?

   It could. Depends on the user agent.

> If yes, how to style states then?

   CSS provides hints for styling. In the end, the user agent decides
that actual style.

> I was trying to answer on
> "Consider this. If you want the submenu hidden and use "display: none"
>  for when the <nl> element isn't focused, how will the user see the
> <label>???"
> 
> Instead of [open] you may use :focus in style sheet above.  It answers on your
> question.

   No, it doesn't, because we're talking menus, not treeviews. The
different UI types lend themselves to different styling requirements.

> If you will interpret "submenu hidden" as "submenu items hidden, but its label
> not" everything will be fine.

   No, it's not. The label that brings up the submenu is not actually
presented as part of the submenu in any user interface I've seen. The
submenu items are always part of a submenu container that is separate
from the label itself. Think about it. How can you have a menu that
scrolls when it gets too long, but a label that remains outside the
scrolling area, if <label> and <li> elements are siblings? For that
matter, how do you put a border around all the list items without
putting it around the label if the list items are siblings? It's just
not logical from a styling standpoint.
Received on Friday, 28 October 2005 09:02:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:41 GMT