I know this is not really what this group is for, but trying to get any 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 ... ?
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
Menu item Menu item Menu item Menu item Submenu item Submenu item Submenu item
(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 element generates a :hover, but keyboard generates an :active on the tag which can't influence the display (or not) of the encompassing submenu.
So I decided to base mine on simple nested 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.
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.
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.
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.
It is not possible to consturct drop down menus without javascript.
The moment you type in 'onmouseover' or 'onclick' you are using javascript.
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.
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.
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, ...).
This package does not appear to be arbitrarily limited to a particular depth of submenus, either.
To my mind, that's what JS is for - clever, but simple and clean logic at the client.
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 and . Go to town on the CSS options...
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.