Andrew,
But again this is a different "label". It has no this fancy "for".
So it has no mentioned problem of matching indirect IDs in CSS.
Exactly! Sounds like a good design to me ;)
Regards,
Mark
Mark Birbeck
CE
x-port.net Ltd.
e: Mark.Birbeck (AT) x-port (DOT) net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b:
Download our XForms processor from
http://www.formsPlayer.com/

Mark Birbeck wrote:
>>But again this is a different "label". It has no this fancy "for".
>>So it has no mentioned problem of matching indirect IDs in CSS.

Exactly! Sounds like a good design to me ;)

Actually, it's awful. Look at the example of <nlfrom the specification:

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

Now remember that <nlis essentially for navigational menus. In a
menu, you see the label for a submenu first, then you see the submenu
when you click on the label. Therefore, you'd expect the label to have
the same style as the grandparent <lielement, with the exception that
there may be an arrow to indicate the submenu or something similar.
Therefore, from a user perspective, styling should look like this:

nl -li -label

However, the actual styling is more like this:

nl -li -nl -label

So, for instance, if you want the nested <nlelement to have a red
background color, the label background would also be read, even though
this would not be the background color of the other items at that the
level of the label in the list. It also means that if a style for the
nested <nldiffers from the style of the parent <li>, <labelcan no
longer inherit from the <lielement with regards to that property.

Consider this. If you want the submenu hidden and use "display: none"
for when the <nlelement isn't focused, how will the user see the
<label>?

Ideally, you'd want the <labelto be outside the list, but
associated with the navigational list:

| <nl>
| <label>Contents </label>
| <li href="#introduction">Introduction</li>
| <li>
| <label>Terms</label>
| <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>

Above, I'm using what I've referred to in the past as "sibling
association" to associate the label with the navigational list.
Unfortunately, this can't be used in situations where a submenu can be
called from multiple locations. For example, right here in my trusty
email program, I have both and "attach" menu option and an "attach"
toolbar button that can both bring up the same attachment submenu. How
exactly do you do that without some kind of |for|-like attribute?

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.

In fact collapsible tree behavior (TreeView) needs something more - ability
to navigate through items by arrow keys - like in select
this is why I've choosen <selectas a base for implementation
of collapsible trees. In fact I have only one behaivor: "select" which
covers all <selectcases - collapsible and plain.

See "master style sheet" internally used in htmlayout component:

And screenshot at

Andrew Fedoniouk.
http://terrainformatica.com

Message
From: "Matthew Raymond" <mattraymond (AT) earthlink (DOT) net>
To: "Mark Birbeck" <mark.birbeck (AT) x-port (DOT) net>
Cc: "'Andrew Fedoniouk'" <news (AT) terrainformatica (DOT) com>; "'W3C CSS'"
<www-style (AT) w3 (DOT) org>
Sent: Thursday, 27, 2005 12:51 AM
Subject: Re: Styling by attribute-based association?

|
| Mark Birbeck wrote:
| >>But again this is a different "label". It has no this fancy "for".
| >>So it has no mentioned problem of matching indirect IDs in CSS.
| >
| Exactly! Sounds like a good design to me ;)
|
| Actually, it's awful. Look at the example of <nlfrom the specification:
|
|| <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>
|
| Now remember that <nlis essentially for navigational menus. In a
| menu, you see the label for a submenu first, then you see the submenu
| when you click on the label. Therefore, you'd expect the label to have
| the same style as the grandparent <lielement, with the exception that
| there may be an arrow to indicate the submenu or something similar.
| Therefore, from a user perspective, styling should look like this:
|
| nl -li -label
|
| However, the actual styling is more like this:
|
| nl -li -nl -label
|
| So, for instance, if you want the nested <nlelement to have a red
| background color, the label background would also be read, even though
| this would not be the background color of the other items at that the
| level of the label in the list. It also means that if a style for the
| nested <nldiffers from the style of the parent <li>, <labelcan no
| longer inherit from the <lielement with regards to that property.
|
| Consider this. If you want the submenu hidden and use "display: none"
| for when the <nlelement isn't focused, how will the user see the
| <label>?
|
| Ideally, you'd want the <labelto be outside the list, but
| associated with the navigational list:
|
|| <nl>
|| <label>Contents </label>
|| <li href="#introduction">Introduction</li>
|| <li>
|| <label>Terms</label>
|| <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>
|
| Above, I'm using what I've referred to in the past as "sibling
| association" to associate the label with the navigational list.
| Unfortunately, this can't be used in situations where a submenu can be
| called from multiple locations. For example, right here in my trusty
| email program, I have both and "attach" menu option and an "attach"
| toolbar button that can both bring up the same attachment submenu. How
| exactly do you do that without some kind of |for|-like attribute?
|

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

In fact[,] collapsible tree behavior (TreeView) needs something more - ability
to navigate through items by arrow keys - like in select[.]
[This] is why I've choosen <selectas a base for implementation
of collapsible trees. In fact[,] I have only one [behavior,] "select"[,] which
covers all <selectcases - collapsible and plain.

Web Forms 2.0 allows for nested <optgroupelements, so for a
<selectelement with the attribute |multiple|, a compliant user agent
may use a treeview-style widget anyways. I'm not really sure what you're
getting at

Message
From: "Matthew Raymond" <mattraymond (AT) earthlink (DOT) net>
To: "Andrew Fedoniouk" <news (AT) terrainformatica (DOT) com>
Cc: "Mark Birbeck" <mark.birbeck (AT) x-port (DOT) net>; "'W3C CSS'" <www-style (AT) w3 (DOT) org>
Sent: Thursday, 27, 2005 1:01 PM
Subject: Re: Styling by attribute-based association?

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

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?

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?

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?
Does <nlhas some special UI behavior like collapsible nodes?
If yes, how to style states then?

|
| In fact[,] collapsible tree behavior (TreeView) needs something more -
ability
| to navigate through items by arrow keys - like in select[.]
| [This] is why I've choosen <selectas a base for implementation
| of collapsible trees. In fact[,] I have only one [behavior,] "select"[,]
which
| covers all <selectcases - collapsible and plain.
|
| Web Forms 2.0 allows for nested <optgroupelements, so for a
| <selectelement with the attribute |multiple|, a compliant user agent
| may use a treeview-style widget anyways. I'm not really sure what you're
| getting at

I was trying to answer on
"Consider this. If you want the submenu hidden and use "display: none"
for when the <nlelement 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.

If you will interpret "submenu hidden" as "submenu items hidden, but its label
not"
everything will be fine. Can you describe this in terms of current CSS? Yes, you
can.

This is what I was trying to express in the <styleabove.

Andrew Fedoniouk.
http://terrainformatica.com

Andrew Fedoniouk wrote:
From: "Matthew Raymond" <mattraymond (AT) earthlink (DOT) 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 <liparent element can be considered the label for
an <nlsubmenu, 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 <nlhas 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 <nlelement 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 <labeland <lielements 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.

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: <nlby 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 Ses.
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.

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

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

Andrew Fedoniouk wrote:
>From: "Matthew Raymond" <mattraymond (AT) earthlink (DOT) 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 <liparent element can be considered the label for
an <nlsubmenu, 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 <nlhas 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 <nlelement 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 <labeland <lielements 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.