It’s a hover menu enhanced with js to make it a click menu and keyboard accessible 
It will work in desktop with js disabled but obviously won’t work in mobile with js disabled as it only revealed on click.
I’m sure brothercake has much better examples that don’t use libraries but that’s beyond my skills.
Okay then, I will watch as I am still making alignment changes. I however want to ask. Have you had any feed back from people that you make sites for where you have placed a click menu on a desktop? If so what kind of reactions did you get from that?
My target audience is mostly retirees but since they are snowbirds they mostly all have mobile devices and desktops. I want to make sure I don’t something that would be strange to that group.
Thanks
As long as you have an arrow (or some other indicator) indicating that the choice is there then it is pretty obvious that there is more below just like the default select elements have an arrow. Users are used to this experience and of course on mobile there is no hover as such so users are even more used to clicking/touching things.
I get no complaints from click menus but users seem to have a problem with hover menus (even when they have fuzzy edges). Some users just cannot move their mouse in a straight enough line to activate the dropdown. It does depend on the menu but I much prefer to the menu to be stable while I decide on which option I want to choose.
So then do you have any suggestions on where I should research these kinds of menus? I would really like to knock this part of the template out tonight.
Thanks
The superfishmenu I used in my demo is here.
http://users.tpg.com.au/j_birch/plugins/superfish/
You will need to wrap it up into a hamburger menu for mobile which you can see in my demo above or in this better version below.
Alright then, will give it a look see. I have been learning all night about alignments and think I have my site in good alignment now. Found a site which I shared in my general post for that.
I wanted this new thread as a menu thread instead of a general question and answer like the first post.
The program I downloaded I managed to get things working but the code does not pass W3C standards. So will give yours a try for now. Its got to work as you were refered to as the css guru.
So here’s the thing – I should have known better than to think that giving over-simplistic answers would cut the mustard I know that it is possible to make menus without JS, but these menus still have poor usability.
@TechnoBear’s example is just weird. No client I work for would accept that, and I’d be considered about its impact on users with low vision or cognitive disabilities.
@PaulOB’s solution isn’t keyboard accessible. You can open the submenus, but you can’t navigate into them.
@Erik_J’s solution doesn’t solve the whole problem. The layout of those menus is, again, quite strange, and not something I would consider acceptable. And the transparent shim trick to handle mouse sloppiness only solves part of the problem. Consider: if you’re hovering over the word “more” in “features > more featured products” and then you move your mouse in a straight line to “more plans”, the menu you’re moving to will close before you get to it.
And in all these solutions – tabbing is not enough – the menu should support arrow-key navigation. It should have ARIA attributes to convey its meaning to screenreaders. It shouldn’t open unless you hover with intent (so it doesn’t open if your mouse moves across it on the way to something else). None of this is possible with CSS, and this isn’t what CSS was designed to do.
It all comes back to Eric Meyer’s original pure CSS menu: it was an interesting proof of concept, but that’s all it was.
Just because CSS can do a thing, doesn’t mean it can do it well, or that it should do it at all. Like the saying goes – to a man with a hammer, everything looks like a nail. You have to use the right tools for the job
Huh?
That one?
I can…Tab until you’re over a dropdown. Enter. Tab more. Enter when you’re on the link you want. You can even go to a sub-sub menu (Menu 3) using that.
What issues does this have now?
I have yet to see how proper CSS can’t give a perfect dropdown. So far, no issues have been identified with proper menus (Pauls).
To sum up my feelings…
That’s not the example I was looking at, I was looking at http://www.pmob.co.uk/mobile-nav-example/index.htm# which didn’t provide keyboard access to the menus.
Lemme look at this other one then, and see I can be proven wrong
I can still keyboard to the items…
Oh okay, it just looks like you can’t because there’s no focus indication on the submenu items.
I mean yeah, that’s the best I’ve seen so far (the second one) 
But, I would still have issues with it – click activation is not a good idea IMHO. It makes sense for application menus, but not for normal web menus. And arrow keys and ARIA are still not implementable this way.
And unless I’m missing something, you appear to be using JS to trigger the menu opening – they don’t open if JS is disabled – so it’s not pure CSS.
It’s a common method, for those who do CSS properly. Many people who do CSS menus aren’t aware of these issues, which then leads me back to say that they don’t properly code.
You can, but hover menus suffer from more usability. Clicks are preferable.
Wouldn’t be hard to add that in.
You can do pure CSS menus for click. Paul said he based his off superfish which does JS. That’s why it is in JS.
Javascript disabled will fall back to hover.
My point is, doing anything more than adding functionality to menus (JS) is unnecessary. I think we can agree to that, yes? CSS menus doing 90% of the work is ideal, then some cherry on top with Javascript.
A whole menu in Javascript is just plain silly. RELYING on Javscript, is plain SILLY.
What are you basing that on? What usability issues do they suffer from that JS can’t solve?
Including keyboard triggers, with a sensible layout … how?
Without using JS?
The whole thing we’re discussing here is whether menus can’t be made usable and accessible without using any JS. But if you’re going to retrofit a CSS menu with JS triggers, how is that not just proving my point?
You can google more.
Please see below.
Okay, but all that article is doing is dismissing the whole concept on the basis of its worst examples, highlighting a whole bunch of problems which are already solved. Yes, accidental triggering and hover tunnels are a real problem, but they’re easily solvable with timers and event filtering.
Just because there are lots of bad JS menus, doesn’t mean JS menus are bad.
Well yeah, you build the menu in HTML, you define its appearance and states in CSS, and you trigger them with JS. But you also need JS to make it usable.
Nobody said you should build the whole menu in JS. You use JS for the behaviour layer, which is what JS is for.
But if JS is not available, the submenus should not open at all. That’s the most important point as far as I’m concerned.
I’m going off of this.
They are keyboard accessible, but if you want toadd in arrow usage, then sure add that in with Javascript.
They ARE tolerant to impreciase navigation if you do click, which you say is an issue.
Besides, in CSS, you can increase the area which allows a menu to stay open, thus negating the whole “wobbly hand” situation yo urefer to.
Again, you don’t see any of this because you don’t visit sites which do CSS properly 
.Or rather, they don’t care.
They’re accessible if you see accessibility as ticking a box that meets a guideline. But that’s not enough. It has to be usable as well.
It only negates part of it – the part where menus close prematurely. But it doesn’t solve the hover tunnel problem, or the hover intent problem. Now it’s true that click menus solve that problem, but I don’t personally accept that as a viable solution. This is not how web menus typically behave – and convention is important, because convention feeds into user expectation.
It’s happened to me many times, that I’ve hovered a menu and nothing happens, and so I assume that there is no menu. It never occurs to me to click it, because clicking should follow the top-level link.
Which is why I say, if you want to add in arrow navigation, feel free.
Many users are fine with click menus. Just because you don’t accept it doesn’t make it a bad solution. Many users PREFER click menus, due to all the issues you admit they have. I’m not sure why you seem to be advocating force feeding hover menus if you admit they have all these issues associated with them.
Click menus are pretty abundant.
That’s a poor UI on their end then.
It’s not about what I want, it’s about what provides good usability for keyboard users. Arrow keys are not an optional niche feature, they’re a core requirement that no menu should be without.
Because hover menus are more common, and hence more expected, and they don’t have any such issues if they’re done properly.
I don’t doubt that many users prefer click menus to bad hover menus, but it comes down to the same thing – all these issues are long-solved.
But I’ve never seen any user research one way or the other though, so it really just comes down to our own viewpoints, and clearly we’re not going to agree on this