Default CSS should match default trac design

Great idea, lot of us don't need a special css just a standard fittable with original trac theme. That's what i tried to do before having a flat bad looking list menu.

Go see #4274 for a new CSS more suitable to the default trac theme and http://users.tpg.com.au/j_birch/plugins/superfish/#download for the current design.

(In [5014]) MenusPlugin: - Added z-index. refs #4274 #4264

Thanx - fits much better with the standard trac layout now - though it looks not like the original one (I can attach you what I made up to know, maybe you want to take something of it).

Some idea: Splitting up the CSS into 2 files (essential.css and the personal style, i.e. trac.css and bluefish.css), together with two options for the trac.ini would ease customization:

[tracmenu]
menu_stylesheet = trac # trac|bluefish|external
#external_css   = <URL>

The essential.css would always be included. The second CSS then is included depending on the settings given here: "trac" => the trac.css from the egg, "bluefish" => the bluefish.css from the egg. If set to "external", the URL specified by external_css is used. This way, when customizing the styles, there is no need to neutralize conflicting style definitions. Plus you can contribute alternative stylesheets easily. What do you think?

I just attached a more trac-like CSS. I'm not 100% satisfied with this yet, but maybe someone more firm with CSS is faster than I am - so I thought I attach what I already figured out... Still, there is a problem due to the missing "class=active" setting for menus defined by trac itself (see #4267), so you will still miss the activated menu item. But that has to be fixed somewhere in the Python code...

Trac-Style CSS (to be used in addition to the "essential" settings)

(In [5021]) MenusPlugin: - More trac-alike look thanks to Izzy. refs #4290 #4264 #4274

Thanks for adapting! But I just found out there's (at least) one thing to be added:

.sf-menu li > a {
  border-left: none !important;
}

This is due to the fact that the menu is shifted to float:left (instead of the original float:right), which is also the reason we needed to add the right border (which is already done in .sf-menu li). Without the above code, the border between two items appears doubled.

There are still some issues left, and I'm not sure whether they are to be solved in CSS or Python code: If you e.g. define a brand new item like this:

new_item.parent = top
new_item.label  = MyLabel
new_item.hide_if_no_children = 1

Just to assign (move) some items below this, it is parsed into the mainnav like

<li><a>MyLabel</a></li>

i.e. an empty a tag. I don't know why, but at least in my installation it then misses the padding and right-hand border - unless I add new_item.href= to above entries (it does not matter whether an URL is put here or not - the main thing seems to be the a tag has an (href) attribute, whether it is empty (href="") or not seems not to matter.

Besides: With your changes to my CSS, the "sub-indicator" is invisible for the not-current-selected menu item - unless the item is hovered. That is since the color of the image is too close to the background color of the item. In my original trac.css I skipped part of yours, so the image was not displayed at all (but the ">>" instead) - so I didn't notice. Maybe the image (arrows-ffffff.png) has to be replaced?

Solution for comment:8 is in fact an updated PNG (I attached it), plus some changes to the CSS:

.sf-sub-indicator {
  background-position: 0 -69px !important;
}

a > .sf-sub-indicator {  /* give all except IE6 the correct values */
        top:                    .8em !important;
        background-position: 0 -69px !important; /* use translucent arrow for modern browsers*/
}
/* apply hovers to modern browsers */
a:focus > .sf-sub-indicator,
a:hover > .sf-sub-indicator,
li:hover > a > .sf-sub-indicator,
li.sfHover > a > .sf-sub-indicator {
        background-position: -10px -69px !important; /* arrow hovers for modern browsers*/
}

/* point right for anchors in subs */
.sf-menu ul .sf-sub-indicator { background-position:  -10px -33px !important; }
.sf-menu ul a > .sf-sub-indicator { background-position:  0 -33px !important; }
/* apply hovers to modern browsers */
.sf-menu ul a:focus > .sf-sub-indicator,
.sf-menu ul a:hover > .sf-sub-indicator,
.sf-menu ul li:hover > a > .sf-sub-indicator,
.sf-menu ul li.sfHover > a > .sf-sub-indicator {
        background-position: -10px -33px !important; /* arrow hovers for modern browsers*/
}

/* for the active ones, use a different arrow color */
li.active > a > .sf-sub-indicator {
  background-position: 0 -100px !important;
}
li.active a:hover > .sf-sub-indicator {
        background-position: -10px -100px !important; /* arrow hovers for modern browsers*/
}

Maybe you want to fine-tune a bit - but basically, this way it works again as expected: Lightgrey/White arrow for active/hover, and darkgrey/black for inactive/hover (yepp, this contrast is needed ;)

Arrows PNG for comment:9

So here comes the missing CSS for the right-pointing arrows:

/* Point right */
li.active ul li .sf-sub-indicator {
  background-position: 0 0 !important;
}
li.active ul li a:hover > .sf-sub-indicator,
li.active ul li a:focus > .sf-sub-indicator,
li.active ul li:hover > a > .sf-sub-indicator,
li.active ul li.sfHover > a > .sf-sub-indicator {
  background-position: -10px 0 !important;
}

But what I may have "messed up" is the special handling of MSIE. Here you may need to re-adjust - sorry, but here it is MS free zone ;)

If you want me to attach the complete resulting CSS file (so you don't have to mess around with all the patches), just let me know.

I just investigated the issue with HREF mentioned in comment:7, and I'm pretty sure this can be tracked down to a CSS issue. The reason for this to happen is: Most of the CSS references rely on pseudo-attributes as :link and :visited - which are only available if an URL is referenced. If it is not, those styles do not apply - so one must count that as WAD (Works As Designed - even if that's not WAI, As Intended).

This means: For self-defined menu items (aka tree_nodes) with no href defined we need to imply either an empty string or '#' (excluding menu_orig items here of course). I already played with the code concerning this - but obviously it is exceeding my knowledge :( I only got as far as filtering out the original items, and select the self-defined without href set:

def _get_menu(self, req, menu_name, nav_orig):
  ...
  menu_result = []
  menu_orig_names = []
  for item in menu_orig:
    menu_orig_names.append(item['name'])
  ...
  for option in sorted(...):
    ...
    if not 'href' in option and not 'href' in config_menu.get(name, []) and not name in menu_orig_names:

But what to update now? I tried tree_node.update(config_menu.get(name, {'href':'#'})), but it had no effect. I tried setting config_menu[name]['href'] = '' and tree_node['href'] = '', also nothing...

Besides: setting

my_item.href =

in trac.ini gets removed the next time trac.ini is updated e.g. via the web interface (or trac_admin when upgrading the environment), so this is not really a solution.

my_item.href = #

could work (not verified thoroughly) until we fixed that issue.

I've got a better idea for a solution, but can test it not before Monday (if you are faster, go ahead). The idea is close to my last comment. The last code line should go where you assign the class=active based on whether the URL matches. Without an URL, there will be no match - so that line catches the ones, and applies not a "fake href", but a class=noref. With that class assigned, we can fix the CSS where it should be fixed: In the stylesheet.

This way has several advantages over the "fake href": While the latter would cause the page to be reloaded when accidentally clicked on, this way nothing happens. And it does not even look like it is a link - which it in fact is not. So I guess that would be a clean way.

If you want me to do that, simply assign the ticket to me. I then will do it, and attach necessary patches here so you can verify, apply, and check them in.

Patch for the latest CSS: Arrows and borders

Just added a patch against the latest tracmenus.css (to be used with the also attached attachment:arrows-ffffff.png, which might need to be updated for the 8-bit indexed alpha png for MSIE). Please check and apply to the repository.

What it does:

• fixing the left border of the menu "boxes" (without this they are doubled)
• using black arrows for the white "tabs", incl. hover effect
• moving the right-arrow in submenus to a more convenient position

Of course I already tested it here in my environment ;)