Primary menu loses padding on "Management" page [#723256]

The primary menu has a padding definition at style.css:342:

ul.primary li a,
[...]
{
padding: 7px 20px 5px 20px; 
[...]
}

But on admin/structure/menu/manage/management/list&destination=node (that's the only place I found the bug, but there could be more)
reset.css:10 overrides it to 0.
But only if it's not hovered, if I hover it looks like it should be.

I saw it on Chromium 5.0.308.0 (37385) and Firefox 3.6 on linux.

Maybe later I have time to debug this, but take a look, it's an interesting theming problem.

Comment	File	Size	Author
#2	723256-active-trail-tabs-padding-2.patch	301 bytes	seutje
#2
#1	primary-broken.png	6.21 KB	Coornail

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Coornail CreditAttribution: Coornail commented 23 February 2010 at 16:02

Issue tags:

+padding, +admin theme

File	Size
primary-broken.png	6.21 KB

Forgot the screenshot after the preview.

Comment #2

seutje CreditAttribution: seutje commented 23 February 2010 at 18:31

File	Size
723256-active-trail-tabs-padding-2.patch	301 bytes

once again, screwed by the overpowering reset :/

since the active-trail classes don't persist to the <a> but only to the <li> and de reset resets the padding on ul.primary li.active a (023 specificity) to 0, the later defined padding on ul.primary li a (013 specificity) in style.css doesn't override it. If the active class would persist to the <a> like it does on a link to the currently active page, then the padding on ul.primary li a.active(specificity 023) in style.css would override it

I see 3 options,

Nerf this berserker reset.css or or at least remove the comment that it's based on Meyer's -> #723392: Tame seven's reset.css
Have active trail persist to the <a>, this would make it rather hard for themes that have a separate styling on active trails compared to the active page
Add ul.primary li a.active to the selector list for the padding in style.css (see patch)