Manic Hedgepig

You can create pure CSS dropdown menus. If you want to add some js enhancements, fair enough – as long as it degrades gracefully without js.

Yes I know you can create pure css drop menus. I can code those easily and have done so many times. I also agree that it should function without js, given the possible reasons why it might have to.

However, you were talking about giving users the ability to choose whether or not to access a drop menu when using keyboard navigation. If you want to do that without js, then the drop menu content has to be in the tabindex, and if it’s in the tabindex then keyboard nav will cycle through it automatically.

The only ways I can see of preventing it doing this are to assign it to the tabindex if and only if the user chooses to access the drop menu, or by using a click to open system. That’s not something you can do just with css. You could do it with js, and you could do it with php, but not with css alone (unless I am missing something).

Is this generally or in relation to the 3.2 admin menu.

Generally. Applies to any platform that uses drop menus.

That didn’t answer my question. ??

I mean if you want to get optionally accessible drop menus without js that’s great, but offhand I cannot see how you could do that without using js.

Anyway the other thing, for mouse users, is the lack of mouseout delay. Having the menus close instantly if you go slightly off track is a real problem for some people. I’ve had them grumble at me quite a bit about it.

So how do you plan to get optionally-accessible drop menus without js?

Ok, I can see your point. It makes sense. So, if you want the drop menus to be optionally accessible then you’ll need a js-based solution rather than a pure css one. That makes sense for other reasons too (mouseout delay, for one).

So are you thinking of something similar to the vB system, with a click-to-open functionality? I’m interested in this discussion generally, not just specifically for WP.

Also, if this is going to be better for a11y then ultimately it should be default functionality rather than a plugin. Plugin is always a good start for new features, of course.

You misunderstand. I’m not suggesting that the menus be permanently visible, if that’s what you’re thinking. Try the demonstration I linked to. It works like a “normal” drop menu except that it will also call links on focus, not just on hover.

If using “standard” drop menus, like the ones on this site, you cannot see the drop menu content at all if you are using keyboard navigation. It is inaccessible (visually) even if your eyesight is perfect. I think we could agree that this is not exactly what is needed.

Try it here. The links to Plugins, Themes and Mobile under the Extend tab cannot be seen if you are using keyboard navigation. The only way you could get to those pages would be to take a wild guess and click to see what happens, which is not the ideal way to navigate a site you may be unfamiliar with.

Sure, you want the menus hidden when you are not using them, but you do want to be able to see the link that is currently in focus. It’s like to wanting the drop menus to open on hover if using a mouse. You want to be able to see the content.

Ok Simon, forget all of that. I found out what the problem was.

The theme’s stylesheet came with this declaration:

.sidebar ul li {
	border-bottom: 1px solid #e3e3e3;
	line-height: 15px;
	padding: 6px 0;
}

I’m running the player in a bottom block for testing, which still has the class sidebar attached to it (markup shows as #sidebar_bottom .sidebar).

That was overriding the stylesheet for your plugin, resulting in the padding and border for the .sidebar list elements being applied on top of the styles in the plugin stylesheet. Instant 6px top and bottom padding and 1px bottom borders. Bleh.

I assume from this that the plugin stylesheet must be parsed by the software before the theme’s main stylesheet is parsed, otherwise the css I was using would have done the job.

Anyway, commenting out that declaration in the theme’s stylesheet does the trick, and suddenly the menu behaves like it ought to. Of course, that will bork the theme too, but now that I know exactly what the problem is I can come up with a workaround for it

Thanks for your time anyway.

The plugin’s functionality is great btw, which is why I chose it.

Cheers.

ETA: Got the workaround, for anyone who gets a similar problem.

After the offending declaration (may the fleas of a thousand camels infest its armpits) throw another declaration into the theme’s main stylesheet to make it shut up and behave itself. This works very nicely:

.sidebar ul li {
	border-bottom: 1px solid #e3e3e3;
	line-height: 15px;
	padding: 6px 0;
}
.sidebar .mp3jplayerwidget ul li {
	border-bottom: none;
	line-height: 34px;
	padding: 0;
}

Just found something odd. Dividers are disabled in admin now, but it makes no difference. The colour of the dividers that are showing is #e3e3e3, but I haven’t used that colour anywhere in the css, nor is it set anywhere in admin. Setting admin to “bypass colour settings” makes no difference either.

So, somehow the li tags are inheriting a bottom border or background image, plus top and bottom padding, despite padding specifically being set to zero, with border: none; and background: none;

The only things that I can think of are that it may be being forced in the php somewhere, or perhaps in the js.

Ok, thanks for the response.

I would like to dump the dividers code completely, if you don’t mind. I can easily set dividers myself in the css if I ever decide I want them (background image, border, whatever). I realise you have put a lot of time and effort into coding this plugin with a lot of options so that non-coders can use it, but I’m customising it for a specific purpose and prefer to run with the minimum of code. I makes things easier for me. ??

Regarding line-height: no, that is not the problem. I have tried setting various line-height, max-height, hidden overflow, negative margins, and umpteen other things. That padding refuses to go away unless I delete the code for ‘id=\”UL_mp3j_” . $pID . “\”‘ in the ul tag. Of course if I delete that, the js no longer has a handle to generate content.

This is why I would like to dump the divider code completely. I can code a pure css drop menu out of my head in about ten minutes, so I know how these things work. This one is behaving very strangely and it definitely seems to be tied in with the code for the dividers.

Regarding ugliness if song titles break to a new line, my suggested fix for that would be to use text-overflow: ellipsis;* on the anchors in the playlist. This is well supported and will do the job nicely. I often use it myself in these sorts of situations. I don’t care about IE6 or IE7 though. Not sure if you do.

Cheers.

*ETA: Actually, what I use is a combination of white-space: pre; overflow: hidden; text-overflow: ellipsis;

Note that this doesn’t seem to work on floated elements, but assuming your list is wide enough to give a good indication of titles, it is a great way of keeping things neat.

Just a note for anyone else who has problems with Superfish/HoverIntent: from my testing on another platform, it seems these jQuery plugins need updating. They are quite old and seem to lose some functionality at jQuery 1.4.3. They work perfectly with 1.4.2 but not with later versions.