Cannot make <div> object appear ontop of everything

It looks like we still have a little residue from my z-index tests to clean up.
(line 233)

#art-main {
    overflow: hidden;  /* DELETE Me */
    top: 0;  /* comment out */
    left: 0;  /* comment out */
    width: 100%;  /* comment out */
    min-height: 100%;  /* comment out */
    z-index: -1;  /* DELETE Me */

(line 3191)

.art-content {
    z-index: -1;  /* DELETE Me. */

After making these changes, the page should be back to the same state that it was when you first posted.

Please test the behavior of the page and let me know how it behaves for you. Except for a px or two of JS activated by a media query(?) it seems to be pretty close to where I started to me, but I may be missing something.

You can also temporarily comment out the #art-main background color, it you wish.

You may want to create a pseudo-screen shot that illustrates what you expect the window to show at the narrower widths.

Most of those properties in #art-main can probably be safely deleted, but I would rather wait until you can test them before doing so. However you definitely should be able to delete overflow:hidden. That is one property that is almost never used in an outermost box because doing so can prevent the page from responding to changes in the window width.


Ok, i made these changes. If you visit now from mobile, the content goes in front of the menu header.

Is this what you see? (content in front of menu header?)

This is helpful. Thank you.

Have you tried validating the HTML? If not, please do. You will likely have to disable the login procedure to allow the validator to access the code. (I get a 401 error.)

The HTML that you are using looks like part of it might have been taken from older pages. Please verify whether or not your editor is adding the og:, fb:, and XML links to the <html... element. I don’t see a reason why the XMLNS links should be there, and don’t know if the fb and og refs are needed either. That’s something you should verify.

Hello, yes this is exactly what i see. You probably guessed right that i’m trying to make menus stay in place (sticky). Which is not easy, because the expand/collapse “button” is made by a plugin (and is sticky anyways), but the green block in which it sits is made by CSS. So basically the contents of the page scroll in front of that block, instead of going behind it. Something similar is happening with the menu for the desktop version.

I never tried validating. I’m not so experienced, sadly. I’m trying to fix things which were made by another person, who built my site to a point and then just walked away.

So i just did it and i get like 47 warnings.

I havn’t read the entire thread so I may not know what is going on, nor do I want to butt in with what ronpat has been doing.

Looking at your code though I see z-index: auto !important; causing problems on the .art-header

What you need is z-index:1 on the .responsive .art-header but that previous important rule overrides it.

Try removing the z-index: auto !important; and then using z-index:1 for responsive.

.art-header {
    margin: 0 auto;
    height: 70px;
    width: 100%;
    background-image: url('images/header.jpg');
    background-position: left;
    background-repeat: no-repeat;
    position: relative;
    /*z-index: auto !important;  remove this*/
.responsive .art-header {
    background: #336601;
    background-image: none;
    background-repeat: repeat;
    background-origin: padding-box;
    background-position-x: 0%;
    background-position-y: 0%;
    background-size: auto auto;
    background-image: url('');
    background-position: left;
    position: fixed;
    z-index: 1;  /*add this*/

That lets the page content scroll behind the green header block

1 Like

Well, it works great. So silly that couldnt see it so many days… ronpat suggested a similar solution couple of days ago, which also solves the problem but makes links unclickable.

Thank you both, guys, you are so helpful


Part of the problem was that z-index: auto !important; was also set on your content. You should probably remove that too.

What that does is stack elements lower in the page source above previous elements, auto stacking. Which is the default behavior for positioned items anyway.

The !important rule is what had you backed in a corner.


Thank you very much for pitching in, @Ray.H.

I was trying to determine how the boxes are stacked (the layout). I didn’t test adequately before posting that suggestion. :blush: Embarrassing but informative.

@pavlosthes, I hope your patience is still holding out because there is more work to do (not all of which will improve this situation right away but still worthwhile.)

Since the site is being “refurbished”, it is a good time to evaluate the usefulness of some of the coding conventions that were used when it was written to see if they are correctly written or outdated. For example, the use of so many !important modifiers is usually not a sign of good coding.

It looks like you’ve added some text above the watermelon image.

validation warnings and errors

If you don’t mind, I would like to work with you to clean up most of the validation errors and warnings. That is an important step in any development process to assure that the finished product will perform as intended across the greatest number of devices. (In the meanwhile, I’m still thinking about how the boxes are stacked.)

It is useful to realize that the validator is a tool that recognizes variations from expected patterns. Most “container” tags, such as <head>, <body>, <div>, <span>, <header>, <main>, <footer>, <script>, <style>, etc, require closing tags. So-called “empty” tags, such as <img>, <meta>, <link>, <br>, etc, are not containers and do not require a closing tag.

HTML does not require empty tags to be terminated with a trailing slash before the “gt” symbol. That is an XHTML convention that some have carried into HTML, but it is definitely not required. The validator doesn’t flag it as an error or warning.

One can write perfectly valid code that does not render properly in a browser. The validator cannot tell how the author intends the page to look. It can only flag deviations from expected patterns.

One of the earliest warnings shows a “type” attribute problem. (It is no longer required as of HTML5).
The validator gives the location of the code in question and quotes the string:

The type attribute is unnecessary for JavaScript resources.

From line 12, column 9; to line 12, column 41

>↩        <script type = "text/javascript">↩↩  

Usually, one can copy the string to find and correct all occurrences of the same problem. However, notice the spaces around the equals symbol (spaces should not be there).
And notice that the very next warning describes another “type” problem involving JS that looks like this:

<script type="text/javascript">↩	

It’s the same warning message, but this time the code has no spaces around the equals symbol.

So, however your editor works, the solution to this warning is to delete the strings
type="text/javascript" and type = "text/javascript"

Changing this:

<script type = "text/javascript">
and this:
<script type="text/javascript">

to this


After completing that process, you should have cleared up about 18 warnings.

Further down the list is another warning:

The type attribute for the style element is not needed and should be omitted.

From line 41, column 3; to line 41, column 25

script>↩		<style type="text/css">↩img.w

Again the solution here is to delete the string type="text/css"
Changing this:

<style type="text/css">

to this:



Will continue with more later. I do hope that you take advantage of this information. :slight_smile:


May as well add a challenge!

It appears that <div class="art-shapes"> does not have a closing tag. Where should the closing tag be located?

There is also a stray closing </p> tag but no open <p> tag. What to do?

(These are listed as validation errors.)


Thank you very much, ronpat.

To me, it is embarrassing that you spend so much time advising me and correcting things. I dont know what to say… Really appreciate it.

To the point, a lot of the things you say i don’t get but many others, i do. So i will try to fix these issues now and come back.

In the meanwhile, here is what i have realized so far about the way the menu was constracted:

#art-header-bg is the full-width light green background, on which the whole menu “sits”. However, it does not CONTAIN everything.

.art-shapes is the dark green background, on which the social media icons, the search box and three yellow links sit. It seems like it contains everything, but switching on and off various elements in Firefox Inspector disproves me.

.art-nav is the container of the main menu (white text), which is painted a light green backgound to match the #art-header-bg color.

So, it is a lot harder than putting a position:fixed line there because many different things are placed there which don’t seem to belong in a common DIV. For example, changing position in .art-shapes from absolute to fixed, causes a catastropihic chaos, flooding green color in the whole page.

1 Like

Exactly tup!   That is why I am trying to dream up a better way to stack the boxes. tongue

Thank you for the added information :wink:

Another thing that i just noticed is that it’s quite difficult to access and modify all those attributes in the head section. Wordpress gives access to the header, but only things that belong to the main theme are there. A whole bunch of extra code is added by pluings, which i can’t view or edit.

1 Like

I discovered something that seems to work, can you confirm?

   background: #336601;
    position: absolute;
    top: 0;
    right: 20px;
    bottom: 0;
    left: 0;

Changed to:

   background: #336601;
    position: fixed;
    min-width: 80%
    z-index: 200;

Of course it leaves the light green background out, but i guess this can be easily tweaked.

That works for me in Firefox as you described.

Great! Do you think it’s a stable and working solution?

No, not really.

What I think needs to happen is the green stripe, the search box, the green menu and the white menu all need to be in the same parent box, so they can be positioned above the content. Perhaps .art-header should be the parent box and #art-header-bg should lose the ID. Dunno. I don’t really know how to move things around in Wordpress so I’m just speculating right now. Trial and error.

1 Like

This is so true

Any idea about this? (need to make dark green stripe same width as page’s content)


   background: #336601; /*dark green*/
    position: fixed;
    z-index: 200;
    width: 65%;
    height: 70px;

% width happens to suck, because you can never know visitor’s resolution. Looks different as i resize the window. Using pixels is also bad because it’s not responsive either. I also tried “inherit”, to get the width of the parent element, again didn’t work.

Not yet. Probably a percent width or a max-width (the same as the content portion of the page) or a combination thereof.

Try this:

.art-shapes {
    background: #336601 none repeat scroll 0 0;
    height: 70px;
    width: 75%;
    min-width: 690px;
    position: fixed;
    z-index: 200;

Not ideal, but works with your present arrangement.

Smart approach! How did you calculate the % / px ratio?