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

Re: Styling by attribute-based association?

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 28 Oct 2005 09:43:50 -0700
Message-ID: <005d01c5dbde$c6ac7220$3201a8c0@Terra>
To: "Matthew Raymond" <mattraymond@earthlink.net>
Cc: <www-style@w3.org>

Hi, Matthew,

Seems like we are interpretting differently purpose of
NL - "navigational list".
You think that its primary role is a popup menu and
I am thinking that it is a hierarchical list.

And you right here: <nl> by its structure is not designed
to be represented as a popup menu.
For serving as a collapsing tree it is semanticly better but also
not perfect.

Speaking about menus, tooltips and popups in general...
I was experimenting with popups a bit:
( in my case popups are "must have"s )
Initial idea was to use something like position:popup; in CSS.
This is sort of super-absolute positioning -
position:popup element placed in a new top-level window -
like popup menu - window with vertically replaced items on most OSes.
This approach was proven to be easily abused - creation of fake windows, 
etc.
So it was rejected.

For tooltips I am using simple "titleid" (non-standard) element attribute 
for that
It contains ID of element which will appear as a popup window.
http://terrainformatica.com/htmlayout/images/tooltips.jpg
Solution is far not perfect but simple and works.

And beside of standard tooltip behavior (non focusable passive window)
I have two more allowing to show arbitrary elements as 1) a hierarchical 
popup menus
and 2) dropdown windows, example - dropdown portion of <select size=1>.

Andrew Fedoniouk.
http://terrainformatica.com





----- Original Message ----- 
From: "Matthew Raymond" <mattraymond@earthlink.net>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
Sent: Friday, October 28, 2005 2:02 AM
Subject: Re: Styling by attribute-based association?


> 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 16:44:12 GMT

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