7 layer deep pure CSS vertical menu without lists

On fedora core 6 linux, http://jinotega.com/menutestie.htm is rendered
correctly by Firefox 2.0.0.6, Opera 9.24, but not Wine IE6. See you,

As a theoretical problem, ok, but still slightly begs the question why?

We would never want to give anyone the impression that this is a sensible approach to styling a list of links, it's not overly hot from a semantic point of view, doesn't look great with styles disabled, and would fail on WCAG guidelines for anchors.

Above remarks not intended to be disparaging oh alright just a little bit!

I'm with Hugo. Why?

The condition not to use UL or OL is odd. From a CSS point of view, its just stylable elements. CSS doesn't care if you choose DIV+A or UL+LI+A or BLOCKQUOTE+Q

Also, DOM doesn't care what the hovered element is. So once you can do the flyout once, you can repeat it ad infinitum - PC and screen limitations permitting. I.e. what is the big deal with 7 when you could have done 30?

Chris ...
I kept changing the colors, got to 7 and then it was lunch time. You can have 30 levels but levels 7 through 30 will be the same color.

Each flyout MUST overlap whatever was hovered to cause the flyout. More or less limits me to the stairstep appearance and ultimately to the number of levels.

There is a BIG technical difference in implementation between UL and DIV/A. In a UL structure, the submenus are inside an LI wrapper. In a DIV/A structure, each submenu is a stand-alone div and doesn't care where it is placed in the list. Rebuilding a DIV/A menu is a cake walk, a lot more care is needed with a UL structure as one is always concerned about the LI wrapper.

I suppose you took my comment as a challenge (here). All I can say is no matter how you do it non-semantic is still non-semantic. I suppose it's up to you to define semantics in your own world though.

Ever know a kid that brings a football to a baseball game and wonders where the goal posts are. You can kick the ball to center field and tackle the pitcher but you still get no points.

I am not insulting you its just that there are reasons that we do things the way we do them. My point is and always has been to use the proper tool for the proper job. If you are doing these things for a purpose other than "because I can" then that's fine by me. You're not going to convince me to drop semantic code but you can do what you want.

Triumph, I want a semantic web; not completely sure what I'd do with it though. I seriously thought XHTML was heading in the right direction at one point but it got lost in the weeds. Indeed XSLT and XHTML would conceptually get us there. For me, <UL> isn't particularly semantic but an XHTML tag <navigationlist> that gets transformed into <UL> would be a long way closer to semantics than where we are.

We are discussing a brick (UL) vs a concrete block (DIV) but need to be thinking "cellar wall block waterproof" "chimney lining fire cured".

Just 3 questions:
1) how do I write pages using truly semantic xml tags?
2) what would I do if they did?
3) would anyone care?

...and finally, since people didn't like my 7 level (sob, wipe eyes, grin) where's a really good multi level vertical menu?

Depends.

What would you do if who did what? :?

Hoi polloi? No.

How about Son of Suckerfish

There are none. Personally, I think one flyout is too many.

(1) You are constrained by your medium. DIV offers no semantic assistance to the browser. LI, P, BLOCKQUOTE, STRONG, etc, offer some. The rest of the semantic information you need to convey with your content.

e.g.

XML:

Homer Simpson
M
38
Power Station Tech

HTML
User List

• 
  

  Homer Simpson

  
  

  Sex: Male

  
  

  Age: 38

  
  

  Job: Power Station Tech

  
  


• ...

Note: This example is illustrative, there will be other HTML structures that can also convey the information semantically - possibly better.

A hunt around these forums will dig up many posts arguing the best semantic structures and the shortcomings of HTML in that regard.

That's a good point.

I prefer and suggest horizontal menus when possible (because they occupy less space). Only horizontal menus get dropdowns. I only suggest vertical menus when there are too many items in the constantly visible part of a horizontal menu. Vertical menus never get flyouts because there is really no point since top to bottom page real estate is virtually infinite and vertical height of a vertical menu list item is only about 1 to 1.5em (IOW you can fit a whole lot on a page). However, if you are dropping below the viewport with a menu it's time to drop the menu altogether and install a search engine.

I used to think taxes should be filed under T for taxes but now I use P for paper or G for government. Given just about anything, there are 25 ways to file it and a hierarchical menu is all about categorization - and mis-categorization. I had horizontal menus and drop downs on my 3270 in 1982; gmail is a leading light in this area. Took me a while to let go of the Outlook folders and rely on gMail search but wouldn't go back for anything now.

I have Google search on my web site with 3 option buttons - my site, a bag of 50 Nicaraguan sites, the rest of the www.

peace.

Git tha shotgun, Pa. This one's gone feral. :ohdear:

Early on in html, there was a <menu> element. It was dropped for two reasons:

1. A menu, by definition, is a list.
2. The menu element was structurally identical to the ul/ol elements.

<menu>, or for that matter <navigationlist>, is redundant. Were you to extend your xhtml DTD with a navigationlist element, the definition would look like this, would it not?

And, that's identical to this:

from the html4.01 DTD.

I have no trouble with the list elements being used to tag a menu, because that's what a menu is. Further refinement can be gained by assigning it to a class, or making it unique with an ID. Chris's use of extensible html to create a machine parseable address is where xhtml could excel. Unfortunately, MSFT's IE …. Which is why we have to screw around with microformats as a work-around.

cheers,

gary

And have I screwed around with MicroFormats *sigh*
However it's not so much that Microformats are a workaround but the method employed to write them that is.

I want a page that has <navigationlist> but ALSO has <breadcrumbtrail> <teensyweenytextacrossthefooter>
<aircraftbodystyles> <boeingstyles> <airbusstyles>

Agreed, they are all lists and end up as UL or OL. But they all, in the xml format, carry far more semantic content than 'UL' ever will. Guess I could use <UL class="boeingstyles" id="boeingstyles"> but that hides the semantics in the attributes so its not 'nice' from my programmers perspective.

If doing all this forces me into the clutches of the XHTML DTD when I am fairly happy with 4.0.1 strict then I'll probably take a pass. Not much to gain and a lot of hard work. The semantic web, whatever that means, is not yet cooked - needs to simmer a while yet.

... shame they dropped the menu tag. lists of menu items and aircraft styles could have been partially differentiated.

Menu is back on the agenda for HTML5 or XHTML2 or SOMETML48.

Application specific XML tags only convey information if the UA has knowledge of what the tag actually means. A plethora of odd tags, e.g. <breadcrumbtrail>, <breadcrumbs>, <kilroywoshere> all attempting to convey the same meaning would be bad too.

Iirc, all current browsers can handle XML + XSLT. If you really wish to keep the maximum semantic information with the data, send it as XML and let the browser process it into the DOM.

Hi Chris,
Could you direct me toward a resource on how to do this? This sounds very interesting to me.
Regards

First, I am no expert in XML or XSLT, so if anyone has better advice or resources please jump in.

I have O'Reilly's XSLT book. This sitepoint article should get you started.