Allow to configure margin-top setting per theme

Is this a usability issue?

See #214740: Body top margin breaks some layouts for further information about this setting. Actually, it's very useful and totally depends on the theme one is using.

To be more specific on the original issue: The originally hard-coded margin-top breaks a theme if there's at least one element positioned absolute (and it's not contained in another element that is positioned relative). So this issue actually happens a lot of times.

However, wasn't there a new theme settings API in D6 (I'm currently unable to find in the API docs) that would simplify moving this setting to the theme configuration page?

We would keep the settings though, as I'm already working on several other optional enhancements, that need to be configurable on the settings page.

As far as 5.x is concerned, I've committed the change in attached patch to explain this setting better.

For 6.x, we should really turn this into a theme setting.

To make the checkboxes code simple and keep the current behavior of adding the margin-top to any theme, this patch uses some inverse logic (omit rather than apply).

From a usability perspective, negated configuration options should be avoided at all costs. So I've reverted that change in the patch, and fixed some E^ALL issues in the update function.

However, I think that Gábor's original issue is still not properly fixed. I can see the chance of a big question mark in a user's mind when looking at this configuration option.

Given the fact that I needed to disable this setting in my last 2 or 3 projects, I'd simply vote to disable the setting by default IF it would not "break" 95% of all other themes. ;)

Anyway, we should be able to fix this by optimizing the label and description. A try:

Apply margin-top to page body

By default, the output of this site will be shifted for approx. 20 pixels from the top of the viewport to make room for the Administration Menu. This, however, might break the layout in certain themes that use absolute or fixed positioned page elements. If disabled for a given theme, page elements at the top of the viewport may be covered by Administration Menu.

Also, the caption is arguable.

I just had this crazy idea, the goal is to adhere to what I consider admin_menu's unwritten rule since I installed it few weeks ago: Just Works (TM).

*me hopes this is the right place for this suggestion*

Since absolute positioned elements are always relative to the viewport, we can be *sure* that if we want to add admin_menu at the top it means like every other absolute position element to be shifted by admin_menu's height. Anybody up for some jQuery-fu?

We can extend jQuerys selector to add something like :absolute which returns absolute-positioned elements. Then we modify them to add +admin_menu's height to their top attribute.

Just an idea proof, try this in your firebug:

jQuery.extend(jQuery.expr[':'], {absolute: "jQuery(a).css('position')=='absolute'"}); $(":absolute").each(function () { var top = $(this).css("top"); if (top != "auto" && top != "inherit") $(this).css("top", parseInt(top.replace("px", "")) + 20 + "px"); });

I think it wasn't the right place, I've started a new issue: http://drupal.org/node/428844

I know I'll probably just get overruled here, but I think we're better off just avoiding this altogether, and adding a tip like "if you need to adjust the margins when admin menu is active, do so in the CSS using a rule such as '.admin_menu #page { margin-top: 30px; }'" I don't think it's the job of this module to cater to every weird thing that could be going on in a theme. I think themers expect to have to make a couple adjustments when adding stuff like this to the DOM.

Thoughts?

I'm not sure that i'm getting the exact same problem as the rest of users, as absolutely positioned objects provide no issues for me.

I do however build a lot of websites where I will put a background on the body via a class, and then other divs inside this with further background css properties.

When the menu is enabled (when logged in) everything moves down 20px, except for the body background. So the only issue I have noticed is where I actually put a background on the body tag, which I would imagine most users would do.

I have found a check to see if a user is logged in, and then moving the background position on the body tag down 20px fixes this problem.
I should think this would suit more users as it will only be in use if you are in fact using the background css property of the body.

Would this be a suitable option for previous posters?
If so might this be worth putting into the module?

@aeski: Your follow-up is more related to #428844: Use JS to adjust layout (a fix for all margin/absolute/background problems)

This is a really ugly problem because the offset positioning issues are now apart of SOO many presentations.
I've just been at drupalCityBerlin 2011 and so many 'elite' devs have the admin menu covering their web page content. Basically, they all forget about and ignore it... this is a very bad solution.

I have my local dev install working nicely with no more than 5px of the page being covered by the menu but my production site covers at least 20px which hides a whole menu in my case.

What troubles me the most is that the HTML order of elements/divs is different b/w the 2 environments.

Local dev puts the 'admin-menu' div first (before skip) and the live site puts it just before the closing body tag. Any ideas what's causing this? (sorry if this should be a separate issue).

In the end, a box to enter the css margin-top for the page content should do the trick. Then it doesn't matter what theme people are using, they can just enter the number they need. Perhaps even a 'override css' box would be best?

If this setting exists, it should be a pixel value, not a checkbox. In its current form, this is pretty sub-optimal. I've enabled and used admin menu on five separate themes in D7 so far, and not even once did it prevent elements at the top of the page from being obscured by the menu. IOW, 30px is not enough in any case I've seen so far. I need to increase that amount to make the site really usable for authenticated users.

Manually adjusting in CSS is a more complex solution than it sounds like, since you've got to do it in both admin and presentation themes and account for logged-in vs. not-logged-in states (not to mention the fact that it didn't really work when I tried it).

I am sorry for no reply until now.

There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.

We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.

However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.

So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?

Thank you for understanding! :)

This issue has been automatically marked as closed because it has not had recent activity after the last post.

However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.

Again, thank you for your contributions! :)