Wrong margin for primary active tab in Seven

this patch makes the primary tabs consistent with overlay tabs

This patch seems to be a duplicate of #721308: Active tabs in seven stick to the tab on the right to me. Though your approach seems more straightforward, the patch in the issue I linked solved the separation issue between tabs with less code. Can we discuss the advantages of each approach? If the patch in the issue I linked doesn't completely solve the issue, I'd like to learn why. To me a simple one-liner fix is suspicious.

The patch over in #721308: Active tabs in seven stick to the tab on the right looks a bit odd to me. whitespace shouldn't have an impact on the tab margins, IMHO. It should also be valid and possible to style those tabs with wrapping white-space.

This should go in Seven, not markup.

This issue might have been solved by an earlier patch. I'm not seeing this error in the Chrome for Linux or Windows any longer. Will test other browsers later.

Not able to cause this issue to occur any more. Looks like a recent patch has fixed this. I'm still going to mark it a duplicate of the issue we mentioned above though, (for the sake of archiving)

Sorry gang, I meant to mark the issue I was primarily working in as the duplicate of this one. Sorry for the stepped toes.

OK, found a bit more about this issue. I don't have the margin issues with the active tab with the Seven theme while viewing an admin page with the overlay on. But I do see this issue when viewing a page with overlay off.

I believe this issue can easily be fixed by switching to floats, it will also help fix the wrapping issue

I couldn't apply the patch in #1, but I made the changes in it and that solved the issue.

This patch did apply for me but with "fuzz":

patching file themes/seven/style.css
Hunk #1 succeeded at 287 with fuzz 2 (offset -2 lines).
Hunk #2 succeeded at 299 with fuzz 1 (offset -6 lines).

After applying the patch the menu items looked good for me while in overlay and without overlay.

Does the patch take sun #5: Support and seutjes #11: CVS version Forum posts suggestions into account?

@yoroy: Sun's comment on #5 was not about this patch but the seperate but duplicative issue I created in the patch that he linked in the comment. seutje suggest in #11 that we use floats instead of inline menu items in order to fix this issue, but the patch provided in #1 also fixes this issue. I think the patch here is preferable since it doesn't need to make a lot of changes to the menu items. If it were up to me I'd mark this issue RBTC so that it can move towards its final review before committing.

I'll see if I can create a patch tonight that doesn't have the fuzz that my patch command hilariously reported.

I'm willing to test your new patch, if that will be okay, I second to mark this as RTBC.

firefox - IE7 - webkit
and wrapping

why am I fiddling with element-invisible? these 2 screens should illustrate why: with -> without (this only occurred in webkit, giving any value to left or right seems to fix it)

why did I change the -10px to -5px? with -10px wrapping looks like this, and without wrapping, there is no difference what so ever, -4px or higher starts to cause a difference

discard the patch above, the real root of the problem seems to be the space in front of the element-invisible

attached patch removes this space, screenshots still apply

if fixing the margin is the only thing we want to do in this issue, this is probably the way to do it, I'll make a new issue for the wrapping and I'll add a patch to set it to float there

updated test

Worked for me in Chrome. going to test other browsers now. This issue continues to be my #1 annoyance.

Works in: IE6, IE7, IE8, Firefox 3.5, Safari 4, and Opera 10

Committed to CVS HEAD. Thanks.