OT: Multilevel Drop Down Menus
the_constructor
sense out of the dedicated computer groups is nigh on impossible.
I am in the process of revamping my website after having to change it's name
due to technical difficulties. OK hands up, I forgot my username and
password that I set it up with on the registration company....
However, I wish to put some multilevel drop down menus across the screen,
but because I am, not to put too finer point on it, THICK, I am finding it
hard going without a suitable tutorial.
Is there anyone out there willing to give me some help please ... ?
For those who wish to know the new url it is:
Regards,
Jim
Tim Watts
Ah - just been looking at this very thing...
Try:
http://www.cssmenus.co.uk/dropline.html
http://www.cssplay.co.uk/menus/
http://www.dynamicdrive.com/style/csslibrary/category/C1/
http://meyerweb.com/eric/css/edge/menus/demo.html
First you have to define what you want. Me? I want pure CSS menus with
uncomplicated CSS, non buggerated HTML and no javascript. I also want
menus that look perfectly OK in a text mode browser (or a normal browser
with CSS and images disabled - think mobile device) and keyboard
tabbable. Cross (modern) browser support without lots of silly hacks.
So in my HTML I have something like
<div id="menu">
<ul>
<li>Menu item</li>
<li>Menu item</li>
<li>Menu item</li>
<li>Menu item</li>
<li>
<ul>
<li>Submenu item</li>
<li>Submenu item</li>
<li>Submenu item</li>
</ul>
</li>
</ul>
</div>
(very roughly from memory)
The fanciness is entirely CSS (and optional javascript). Use another CSS
file to control the placement of the #menu div on the screen as a blob
relative to all the other blobs (header,footer, content etc).
I gave up on pop-outs because without javascript it seems diffcult to
get them to play nice ith both the mouse and the keyboard (hint: mouse
over the <LI> element generates a :hover, but keyboard generates an
:active on the <A> tag which can't influence the display (or not) of the
encompassing <UL> submenu.
So I decided to base mine on simple nested <UL>s but to display the lot
at once (let's face it, my little site will never have very deep menus)
nicely, with suitable indentation, down the left side of the screen. A
technique I notice some other sites do.
OTOH if you aren't such a minimalist as me, one or two of those links
above have good cross browser mostly CSS menus and popout submenus with
javascript assist for the keyboard.
You should be able to rip something off and make it your own.
CSS (and browsers - IE excepted unless you have absolutely the latest)
seem to have come a long way.
--
Tim Watts
Hung parliament? Rather have a hanged parliament.
The Natural Philosopher
What language are you programming in?
Its fairly basic javascript...which I load up via server side PHP, if
that's of any use.
I can dump some PHP routines if you like..
> Regards,
>
> Jim
>
>
>
the_constructor
"The Natural Philosopher" <t...@invalid.invalid> wrote in message
news:huh91k$3dk$1...@news.albasani.net...
I am sure that would be very helpful indeed, Thank you
Jim
Dave Liquorice
> First you have to define what you want. Me? I want pure CSS menus with
> uncomplicated CSS, non buggerated HTML and no javascript. I also want
> menus that look perfectly OK in a text mode browser (or a normal browser
> with CSS and images disabled - think mobile device) and keyboard
> tabbable. Cross (modern) browser support without lots of silly hacks.
Aye, javascript ot be avoided if at all possible and not for key
functions. The number of sites that now have "links" that solely
powered by the latest trick in javascript is growing, these sites are
useless unless you have jave.
So stick with CSS that at least is fairly well standardised across
browsers. How you generate the code sent to browsers is up to you. I
use PHP but other server side languages can be used or just hard code
it but then it becomes harder to maintain the simple but nice things
like the current active menu level(s) being highlighted some how.
--
Cheers
Dave.
Tim Watts
> On Sun, 06 Jun 2010 23:30:01 +0100, Tim Watts wrote:
>
>> First you have to define what you want. Me? I want pure CSS menus with
>> uncomplicated CSS, non buggerated HTML and no javascript. I also want
>> menus that look perfectly OK in a text mode browser (or a normal browser
>> with CSS and images disabled - think mobile device) and keyboard
>> tabbable. Cross (modern) browser support without lots of silly hacks.
>
> Aye, javascript ot be avoided if at all possible and not for key
> functions. The number of sites that now have "links" that solely
> powered by the latest trick in javascript is growing, these sites are
> useless unless you have jave.
>
> So stick with CSS that at least is fairly well standardised across
> browsers.
And not only that, but once you get back to the Tim Berners-Lee mindset,
you will write your HTML as a structured document where H1 means the
outermost heading, EM means emphasise - and stop thinking that HTML is a
presentation language - it isn't.
Once the presentation is shoved into CSS then browsers are all
programmed not to whine about styles they don't understand - so you can
mix CSS1,2 and 3 and get a decent result that in the worst case (no CSS)
degrades back to a readable and linkable document.
> How you generate the code sent to browsers is up to you. I
> use PHP but other server side languages can be used or just hard code
> it but then it becomes harder to maintain the simple but nice things
> like the current active menu level(s) being highlighted some how.
>
Technically you don't need any of this - plain static files will work,
with some repetetion.
I *believe* the "you are here" in the menu can be done in CSS with a
clever mention of a class or ID used by the main document - just about
to check that myself.
SSI (Server Side Includes) are enough to piece together a page from a
common menu blob, common headers and footers.
Of course you can use PHP, Perl or some other dynamic generation - but
if you are serving notionally static content, it's worth being careful
about how the various expires and modified headers are presented[1] if
you want google to index and cache your site.
[1] In the SSI scenario, most people would want the resultant document
to have any dates allied with the filesystem modified timestamp on one
particular source file.
The Natural Philosopher
> On Sun, 06 Jun 2010 23:30:01 +0100, Tim Watts wrote:
>
>> First you have to define what you want. Me? I want pure CSS menus with
>> uncomplicated CSS, non buggerated HTML and no javascript. I also want
>> menus that look perfectly OK in a text mode browser (or a normal browser
>> with CSS and images disabled - think mobile device) and keyboard
>> tabbable. Cross (modern) browser support without lots of silly hacks.
>
> Aye, javascript ot be avoided if at all possible and not for key
> functions. The number of sites that now have "links" that solely
> powered by the latest trick in javascript is growing, these sites are
> useless unless you have jave.
It is not possible to consturct drop down menus without javascript.
The moment you type in 'onmouseover' or 'onclick' you are using javascript.
>
> So stick with CSS that at least is fairly well standardised across
> browsers. How you generate the code sent to browsers is up to you. I
> use PHP but other server side languages can be used or just hard code
> it but then it becomes harder to maintain the simple but nice things
> like the current active menu level(s) being highlighted some how.
>
I agree to use CSS to its full, but be aware it is far from standardised
across browsers.
In particular the concept of Z-index, which you need to place menus
above a screen, is handled completely differently in MS rendering
engines to e.g. Mozilla.
And neither is bug free in its implementation.
Likewise when defining containers, font sizes and different
interpretations of margins anf paddings make it extremely hard to
produce conformal code that functions well in both: JavaScript is
actually MORE predictable in many cases.
You have in essence tow choices in producing an active menuing system:
Use someone else's, and hope its been tested thoroughly against all
possible targets, or sit down and roll your won, knowing that at least
you can rework it to cope with yet another browser anomaly, if it turns
out not to work..
I opted for the latter.
Infinitely recursive flyout menus are not simple.
You have to create invisible areas of the screen that will respond to
mouseovers to cancel the menus, and area of menu system that when moused
over (or clicked over) will cause other levels to be switched on. This
requires extensive javqascript to identify the screen changes on a given
mouse event, and quite a lot of computation: Enough with a large menuing
system to cripple IE6 at least, if some method to improve its search
speed in the DOM are not taken.
In my case the problem was compounded by the fact that the menus were
built from arbitray data in a database: I could not rely on fixed
formatting, but had to generate the menus on the fly from the database.
The overall result is large, and a compromise between page size,
execution speed and screen accuracy.
It iuses a lot of CSSS and a little javascript, and will ONLY wiork if
other page constraints are met, in IE6 at least. The problem here being
that nested containers in IE6 are given implicit Z-indices above any
that you may apply explicitly. That is a container with a z-index of 99
will NOT overwrite one with a Z-index of 0, if that happens to be
contained by a subcontainer of the container you are applying the
z-index to.
In other words, you have to keep the DOM model flat with respect to
containers. Which is a bloody PITA.
Adrian C
>
> It is not possible to consturct drop down menus without javascript.
Er, Nope
> The moment you type in 'onmouseover' or 'onclick' you are using javascript.
Those handlers are redundant for pure CSS dropdown implementations.
--
Adrian C
Tim Watts
> Dave Liquorice wrote:
>> On Sun, 06 Jun 2010 23:30:01 +0100, Tim Watts wrote:
>>
>>> First you have to define what you want. Me? I want pure CSS menus
>>> with uncomplicated CSS, non buggerated HTML and no javascript. I also
>>> want menus that look perfectly OK in a text mode browser (or a normal
>>> browser with CSS and images disabled - think mobile device) and
>>> keyboard tabbable. Cross (modern) browser support without lots of
>>> silly hacks.
>>
>> Aye, javascript ot be avoided if at all possible and not for key
>> functions. The number of sites that now have "links" that solely
>> powered by the latest trick in javascript is growing, these sites are
>> useless unless you have jave.
>
> It is not possible to consturct drop down menus without javascript.
>
It is:
http://www.tjkdesign.com/articles/keyboard_friendly_dropdown_menu/default.asp
http://www.tjkdesign.com/articles/new_drop_down/EK.asp
> The moment you type in 'onmouseover' or 'onclick' you are using javascript.
You use :hover and :active instead.
As I mentioned in the my post, javascript can be useful for adding the
last tweak to make such menus behave identically under keyboard tabbing
or mouse use. But in one of the examples above, there is a non JS
workaround for keyboard access (being you "click" on the top level menu
item to expose the submenu.
>
>>
>> So stick with CSS that at least is fairly well standardised across
>> browsers. How you generate the code sent to browsers is up to you. I
>> use PHP but other server side languages can be used or just hard code
>> it but then it becomes harder to maintain the simple but nice things
>> like the current active menu level(s) being highlighted some how.
>>
>
> I agree to use CSS to its full, but be aware it is far from standardised
> across browsers.
The beauty of using nested ULs is that if it all goes tits up, the user
still has a functional page. It depends on if the priority is simplicity
and usability, or something that looks identical in every browser back
to Noah's.
I favour the first approach as the second almost always breaks badly
somewhere because they were using entirely too many hacks...
> In particular the concept of Z-index, which you need to place menus
> above a screen, is handled completely differently in MS rendering
> engines to e.g. Mozilla.
>
> And neither is bug free in its implementation.
>
> Likewise when defining containers, font sizes and different
> interpretations of margins anf paddings make it extremely hard to
> produce conformal code that functions well in both: JavaScript is
> actually MORE predictable in many cases.
>
> You have in essence tow choices in producing an active menuing system:
> Use someone else's, and hope its been tested thoroughly against all
> possible targets, or sit down and roll your won, knowing that at least
> you can rework it to cope with yet another browser anomaly, if it turns
> out not to work..
>
>
> I opted for the latter.
>
> Infinitely recursive flyout menus are not simple.
I agree on that point. I've leaning towards a single visible hierachy
for simplicity - but that breaks if you get more than about 20 odd menu
and submenu items.
> You have to create invisible areas of the screen that will respond to
> mouseovers to cancel the menus, and area of menu system that when moused
> over (or clicked over) will cause other levels to be switched on. This
> requires extensive javqascript to identify the screen changes on a given
> mouse event, and quite a lot of computation: Enough with a large menuing
> system to cripple IE6 at least, if some method to improve its search
> speed in the DOM are not taken.
>
> In my case the problem was compounded by the fact that the menus were
> built from arbitray data in a database: I could not rely on fixed
> formatting, but had to generate the menus on the fly from the database.
>
> The overall result is large, and a compromise between page size,
> execution speed and screen accuracy.
>
> It iuses a lot of CSSS and a little javascript, and will ONLY wiork if
> other page constraints are met, in IE6 at least. The problem here being
> that nested containers in IE6 are given implicit Z-indices above any
> that you may apply explicitly. That is a container with a z-index of 99
> will NOT overwrite one with a Z-index of 0, if that happens to be
> contained by a subcontainer of the container you are applying the
> z-index to.
>
> In other words, you have to keep the DOM model flat with respect to
> containers. Which is a bloody PITA.
>
I feel so lucky that none of my web pages are commercial. I think I'd
kill myself if I had to support IE6.
Sometimes you wonder if it wouldn;t just be easier to prerender the
pages as giant imagemaps ;->
The Natural Philosopher
The Natural Philosopher
> On 07/06/10 10:21, The Natural Philosopher wrote:
>> Dave Liquorice wrote:
>>> On Sun, 06 Jun 2010 23:30:01 +0100, Tim Watts wrote:
>>>
>>>> First you have to define what you want. Me? I want pure CSS menus
>>>> with uncomplicated CSS, non buggerated HTML and no javascript. I also
>>>> want menus that look perfectly OK in a text mode browser (or a normal
>>>> browser with CSS and images disabled - think mobile device) and
>>>> keyboard tabbable. Cross (modern) browser support without lots of
>>>> silly hacks.
>>>
>>> Aye, javascript ot be avoided if at all possible and not for key
>>> functions. The number of sites that now have "links" that solely
>>> powered by the latest trick in javascript is growing, these sites are
>>> useless unless you have jave.
>>
>> It is not possible to consturct drop down menus without javascript.
>>
>
> It is:
>
> http://www.tjkdesign.com/articles/keyboard_friendly_dropdown_menu/default.asp
>
>
> http://www.tjkdesign.com/articles/new_drop_down/EK.asp
>
>> The moment you type in 'onmouseover' or 'onclick' you are using
>> javascript.
>
> You use :hover and :active instead.
mere words. They are also essentially javascript of a sort, and they are
less well supported.
>
> As I mentioned in the my post, javascript can be useful for adding the
> last tweak to make such menus behave identically under keyboard tabbing
> or mouse use. But in one of the examples above, there is a non JS
> workaround for keyboard access (being you "click" on the top level menu
> item to expose the submenu.
>
if you don't reload the entire page as a result, you have to use
'onclick' to trigger the event.
The point I am trying to make is that drp down menus either require
complete page reloads, or some form of active browser. The former is
reliable, but horribly slow, the latter means you have to rely on
either inbuilt 'activity' such as te hover and active you cited, or
JavaScript. JavaScript is more reliable and flexible.
BUT in ALL cases you have to use the limited subset of CSS and
'activity' functions that are reliably supported in similar fashions by
most browsers.
The problem is, most of what you want to do with such a system leads you
instantly into incompatibilities: The issue is not to JavaScript or not
to JavaScript, its what is reliably similar in effect across multiple
platforms.
Its probably best to avoid drop diown menus in public websites
altogether if possible.
>>
>>>
>>> So stick with CSS that at least is fairly well standardised across
>>> browsers. How you generate the code sent to browsers is up to you. I
>>> use PHP but other server side languages can be used or just hard code
>>> it but then it becomes harder to maintain the simple but nice things
>>> like the current active menu level(s) being highlighted some how.
>>>
>>
>> I agree to use CSS to its full, but be aware it is far from standardised
>> across browsers.
>
> The beauty of using nested ULs is that if it all goes tits up, the user
> still has a functional page. It depends on if the priority is simplicity
> and usability, or something that looks identical in every browser back
> to Noah's.
>
Sadly, it was the first thing I tried, but it didn't do what was wanted.
> I favour the first approach as the second almost always breaks badly
> somewhere because they were using entirely too many hacks...
>
Thats where you get to understand teh langauges you are using, in more
detail than you ever wanted to :-(
And get debugging against multiple browsers.
Its why professional web programmers command a lot of money: they know
teh safe routes through the browser swamps.
>> In particular the concept of Z-index, which you need to place menus
>> above a screen, is handled completely differently in MS rendering
>> engines to e.g. Mozilla.
>>
>> And neither is bug free in its implementation.
>>
>> Likewise when defining containers, font sizes and different
>> interpretations of margins anf paddings make it extremely hard to
>> produce conformal code that functions well in both: JavaScript is
>> actually MORE predictable in many cases.
>>
>> You have in essence tow choices in producing an active menuing system:
>> Use someone else's, and hope its been tested thoroughly against all
>> possible targets, or sit down and roll your won, knowing that at least
>> you can rework it to cope with yet another browser anomaly, if it turns
>> out not to work..
>>
>>
>> I opted for the latter.
>>
>> Infinitely recursive flyout menus are not simple.
>
> I agree on that point. I've leaning towards a single visible hierachy
> for simplicity - but that breaks if you get more than about 20 odd menu
> and submenu items.
>
In the end you have to make your choices, and make them work. My
customer wanted menus that behaved like MS Windows. they flew out on
miuseover. BUT going down 6 levels deep. one slip of the mouse and they
all vanished. I suggested cliked on menus that would stay till you
clicked somewhere else. They ultimately found that more usable.
Sadly that's introduce another problem I haven't yet fixed. One click to
cancel and ANOTHER click to now do what the election you just made, was
intended for..sigh..
Not over a 38k modem, no.
In order to get what amounts to a complete 1500 element stock list
available locally at the click of a button, the raw page size is
humongous. About 60K. somewhere around 60Kbytes of data. Fortunately its
ALL similar lines of <div class ="blat" stykle : "position: absolute
..." etc etc..which is highly amenable to compression..so actual
download size is about 15k on that program.
But even 15k bytes takes 4-5 seconds on a 38000 modem...
Its ALL unholy compromises.
Liei IE6 was dog slow killing menus//it triursn out that it doesnt index
te DOM so lokiing for elements of teh DOM with the same class name to
'switch them off' meanst a hugge tarwl through 3000 elemnts more or
less. Including loads I couldnt give a toss about.
It was quicker to create an array of elements that I was interested in,
and search those. 20 times faster! result. Of course creating te array
wasn't that smart if done at page load, so I did it the hard way. If I
turned a menu on, I checked if it was in the array, if not, it got
added. Then to turn it off, just search the limited array of 'menus I
have used'
Probably took over a month to get that lot working.
Going back to te OP, who doesnt want to know all this stuff, its best
iof yiou can provide and example of what you atrer tryng to echieve, and
then it can be firther discussed.
One very crappy website we did a year or two back is here..
http://www.greystone-interiors.co.uk/
you might care to rip off the menu system if you like.
Owain
> Sometimes you wonder if it wouldn;t just be easier to prerender the
> pages as giant imagemaps ;->
Or Flash ;-(
Owain
Adrian C
There are many ...
http://naarvoren.nl/artikel/hover/cssmenu.html
But that one (admittedly) requires a javascript fudge for IE to get out
of a behavior related hole - it not naturally supporting :hover for
things other than links - and I google IE has gathered more bugs
recently in that area.
http://www.xs4all.nl/~peterned/csshover.html is the Fix.
--
Adrian C
The Natural Philosopher
I hate javascript, but I hate trying to do complex things using only
CSS, just to prove it *can* be done, even more.
Tim Watts
> In article<huh7hb$oei$1...@news.eternal-september.org>,
> In my case I use javascript because in some cases I need to construct
> the menus on the fly, as user actions can change what the menus contain
> (i.e., can cause options to be added, submenus to be added, ...).
To my mind, that's what JS is for - clever, but simple and clean logic
at the client.
> This package does not appear to be arbitrarily limited to a particular
> depth of submenus, either.
>
xforms is an improvmnet over htmlforms. I wonder if they will ever do a
single standardised "xmenu" feature? Everyone wants menus. There are
only so many ways they can be really be built onscreen (vertical with
pop outs, horizontal with dropdown or just maybe the 2nd horizontal
submenu). Everything else is styling. Seeing as it is inherently list
structured, nested <ML> and <MI>. Go to town on the CSS options...