Wrap output in a submenu class
ksenzee - August 12, 2008 - 06:47
| Project: | Submenu Tree |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | by design |
Description
What a lovely, lovely module. Would you accept a patch that adds a <div class="submenutree"> tag around the output of the theme functions? That way I could add some CSS love to my submenus without having to override all four theme functions.

#1
Hmmm ..., most probably not, unless there was a really good reason for doing so. Perhaps if you can enlighten me why it's absolutely necessary to add an extra div?
#2
Aha... a perfectionist. :) The div certainly doesn't need to be hard-coded into the theme functions. However, I do need to be able to override all submenutree output at once. In my particular case, I'm surrounding the whole submenu with a div for styling (see attached screenshot). Some of my submenus are teasers, some are just title lists, some might include full text. Ideally, I should be able to theme them all with one line of CSS or one overridden function. As it is, I'm having to override four functions.
If you don't like the div idea, how about a theme_submenu_tree function that in turn calls the other four theme functions? That would let people theme the <h3> tags as well.
#3
At this point, I'm still pretty loathe to do it. For all I know, adding this extra div may break someone's site the next time they upgrade submenutree.
What about this as a workaround?
Show all your submenutrees in a block. Most themes will wrap the block with a #block-submenutree-1 (or something similar). You can then use this selector to do all your css styling.
#4
That's exactly what I would do, if I wanted them in a block. I'm using them as part of the node content, and with the theme functions as written, there's nothing to set them off from the rest of my node. I don't actually need a workaround -- I'm already overriding all four theme functions, and I have exactly what I need. So if you're happy with it, by all means leave it as is. It's your module. :)
#5
Presently, yes, I would prefer to leave it as is. Thanks your feedback though.