Opened 16 years ago
Last modified 8 years ago
#4264 new defect
Default CSS should match default trac design
Reported by: | izzy | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | MenusPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
The plugin is great - but the default design shipped for sure breaks the design for 99% of all trac installations. Wouldn't it be more suitable to ship it with a design matching the trac defaults (the current design could be shipped optionally in addition)? Not everybody is firm enough to "port it back".
Besides of that, I love the plugin. I installed it into a test environment - but because of the CSS stuff cannot roll it out to the production server (which would have been no problem if it used default trac style)... Not that easy to figure out.
Attachments (3)
Change History (17)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
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.
comment:4 Changed 16 years ago by
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?
comment:5 Changed 16 years ago by
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...
Changed 16 years ago by
Trac-Style CSS (to be used in addition to the "essential" settings)
comment:6 Changed 16 years ago by
(In [5021]) MenusPlugin: - More trac-alike look thanks to Izzy. refs #4290 #4264 #4274
comment:7 Changed 16 years ago by
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.
comment:8 Changed 16 years ago by
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?
comment:9 Changed 16 years ago by
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 ;)
comment:10 Changed 16 years ago by
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.
comment:11 Changed 16 years ago by
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.
comment:12 Changed 16 years ago by
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.
Changed 16 years ago by
Attachment: | tracmenus.css.diff added |
---|
Patch for the latest CSS: Arrows and borders
comment:13 Changed 16 years ago by
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 ;)
comment:14 Changed 8 years ago by
Owner: | Catalin BALAN deleted |
---|
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.