Welcome to WebmasterWorld Guest from

Forum Moderators: not2easy

Message Too Old, No Replies

problem with z-index and list

block and inline elements

2:18 pm on Feb 18, 2011 (gmt 0)

I never used z-index before, but since I use it now I read about it and came across two important items to take care of: position of the element should be defined and working with tables can cause problems. I'm still somewhere in the middle of using tables and div for lay out of my pages and this problem is one of the reasons I still fall back on using tables most of the time. I have trouble with positioning elements. For the test file I removed tables and since I want both items next to each other I put them in a separate span. They do however show up above and not next to each other. Might be caused by the menu as it says at a certain point display: block. The menu itself has caused me a lot of headache before I got it working and with help from this forum it now works as desired, with submenus. I'm not eager changing things in the menu css as I fear I will run into new trouble. I suspect the menu to be the problem though, for when I change the z-index of the frame to -1 it hides behind other elements of my page.
Is what I want possible at all and if so what causes the mal-functioning?

This is the html code:
<span id= "siteNavigation">
<ul> <!-- begin menu -->
<li><a href="index.html" class="active"><img src="images/button_home.png" alt="home"></a></li> <!-- hoofdmenu button 1 -->

<li><a href="#"><img src="images/button_bezoekers.png" alt="bezoekers"></a> <!-- hoofdmenu button 3 -->
<ul> <!-- submenu button 3 -->
<li><a href="#"><img src="images/button_informatie.png" alt="informatie"></a> <!-- submenu button 3.1 -->
<ul> <!-- subsubmenu button 3.1 -->
<li><a href="openingstijd.html"><img src="images/button_opening.png" alt="openingstijd"></a> <!-- subsubmenu button 3.1.1 -->
</ul> <!-- einde subsubmenu button 3.1 -->
</li> <!-- einde submenu button 3.1 -->
<li><a href="kinderen.html"><img src="images/button_kinderen.png" alt="kinderen"></a></li> <!-- submenu button 3.2 -->
</ul> <!-- end submenu button 3 -->
</li> <!-- end mainmenu button 3 -->

<li><a href="arrangementen.html"><img src="images/button_arrangementen.png" alt="arrangementen"></a></li><!-- hoofdmenu button 4 -->
</ul><!-- end menu -->
</span> <!-- //siteNavigation -->

<span id="frame">
<iframe title="YouTube video player" width="600" height="368" src="http://www.youtube.com/embed/dBaCI-pxxOo?rel=0" frameborder="20px" allowfullscreen></iframe>

and here is the css code for it:
#frame {

/* navigatie */
/* 1st level */

#siteNavigation ul {
width:150px; /* of image */
list-style-type:none; /* verwijdert opsommingstekens */
position: relative;

#siteNavigation ul a img {
position: relative;

#siteNavigation ul li {
position:relative; /* so the second level takes position from it */

#siteNavigation ul li a {
position: relative;

/* 2nd level */

#siteNavigation ul li:hover ul { /* reveals second level when hovering on the first */
position: relative;

#siteNavigation ul ul {
visibility:hidden; /* to initially hide the drop down menu */
left:150px; /*positie submenu t.o.v. hoofdmenu */
width:150px; /* breedte afbeelding */

#siteNavigation ul ul a img { /* image dimensions */
position: relative;

#siteNavigation ul ul li {
height:29px; /* height of second level list element matched to image height */
position:relative; /* IH_added for 3rd level */

#siteNavigation ul ul li a {
position: relative;

/* 3rd level */
#siteNavigation ul li:hover ul li ul { /* to initially hide the drop down menu_IH */
left:150px; /* position subsubmenu */
width:150px; /* width image */

#siteNavigation ul ul ul a img { /* image dimensions */
position: relative;

#siteNavigation ul li ul li:hover ul {
visibility:visible; /* reveals 3rd level when hovered */
position: relative;

#siteNavigation ul ul ul li {
height:29px; /* height of third level list element matched to image height */
position: relative;

There is one more thing about the iframe: using border results in a small border, but it takes no notice of the value, i.e. increasing the value doesn't influence the result. I have also trouble using firebugs inspect element, as once on the frame it shows other options, no firebug options.
5:26 pm on Feb 18, 2011 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

can you post the CSS for your siteNavigation div too please

you shouldn't really be using spans as they are inline elements, so nesting a ul (block level element) inside a span will throw an HTML validator error - however once positioning and floats is involved the span acts like a div - CSS/display wise - so it shouldn't be causing any display problems for now and is a minor change

I think floats will be the tool for the job rather than poisitioning or perhaps even display inline-block; however a reminder of the #siteNavigation CSS would be helpful.. along with the widths you would like the two side by side areas to be, and then if there is an overall "wrapper" container controlling the total page width please..

5:50 pm on Feb 18, 2011 (gmt 0)

Hi SuzyUK,

The css for siteNavigation is posted, below the id "frame".
In my "normal" files the navigation is in a div, but I was afraid that it was causing problem as div is for block and span for inline elements. The site is online recently, but I thought I am not supposed to post the URL on this forum. I could send it to you in a message if that would make things easier, as you have a complete picture of the page then and see the lay-out the way it should be.
Just let me know what is best to do.
8:36 pm on Feb 18, 2011 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Hi webprutser, btw I too looked up what user name meant and hehe - pls do call me Suzy, the UK part is only there because plain Suzy wasn't available at the time

I think it's now OK to post the link if you want to, as long as it's not spam ;) An admin will scurry in and fix if there's a problem - if you'd rather not give away the site identity then sure it's OK to send me a Sticky and I'll summarize

I'm looking for any CSS concerned with the actual
#siteNavigation {}
div not the nested ul -
#siteNavigation ul {}
, which is the bit below the #frame in your CSS.. it's OK if there isn't any. in fact it's good

but I was afraid that it was causing problem as div is for block and span for inline elements

In HTML that is indeed the role of those elements, i.e. block and inline LEVEL, however CSS can override the way these elements display (the display properties) - So as I alluded to in previous post while technically you think you need an inline element as you want to display the elements side by side, or inline with each other - you don't, indeed you shouldn't even be thinking about site display when you're writing the HTML - that is what separation of presentation from content really means! - write the document as if you didn't even know what CSS meant, make sure it "reads" ok.. as if you only had access to a text browser and couldn't care less about display. Then validate it through the HTML validator

If in plain HTML, no CSS, you put a block level element, like a UL inside a span it will display only by virtue of the browsers error recovery mechanism, but it won't validate, and it will look like it's acting like a block.. try putting another span beside it, it will appear below the ul

You actually want to use these HTML elements without thinking about how they will eventually display, then validate the HTML first - CSS is only a suggestion to browsers about they should display the content it should not influence what HTML you actually use..

So using a div to contain a UL is the right thing to do, i.e. a generic block level element to contain another block level (now called flow elements in the spec) element - once the correct HTML is written, then from there CSS can take over a way to prettify.. it cannot change the inherent nature of an HTML element

perhaps another way to think of it is that if we have two divs (block level HTML elements) that are correct because they both contain further block level elements .. say two unordered lists, UL's, and then we want them to display side by side (as if in table cells ;)) we suggest, via CSS, just that .. div {display: inline;} this only changes the way these divs display on our screen, or whatever other media you happen to be targeting, it does not change their function.. which is a generic block level container

now in saying all that to try and explain another thing that you've mention in your posts above - say you are legitimately using a span in your HTML and then in your CSS you position or float these spans, they automatically takes on the characteristics of "display: block;" even if that property is not explicitly specified.. this makes sense.. you visually expect a positioned block or a floated block to be a block ;)
10:07 pm on Feb 18, 2011 (gmt 0)

A lot of information ... the name webprutser prooves to be right once again. :-) At times you think you know a bit of CSS, but there is still a lot to learn. The most challenging thing for me at the moment is to get a better understanding of positioning elements without using tables.
This part is very clarifying to me:
div {display: inline;} this only changes the way these divs display on our screen, or whatever other media you happen to be targeting, it does not change their function.. which is a generic block level container

That changes my way of thinking, pointing me in the right direction.
It also makes me wonder what the essential difference - in function - is between block and inline elements. The way I looked at it, the only difference was the way they were displayed. Want something inline with each other: use inline, if not use block. Knowing more about this might help me get on the way to using the box model.

I will validate my test-file. The URL for the website is www.stoommachines.nl (homepage). The z-index is not included, I made a temporarily solution by adding some <br> so the youtube frame doesn't hide the submenu.
2:49 pm on Feb 19, 2011 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Morning webprutser, will check out the link

glad some of my ramblings are helping clarify some things,

It also makes me wonder what the essential difference - in function - is between block and inline elements. The way I looked at it, the only difference was the way they were displayed.

Now that's a wonder and a half, but if you can get the difference you'll be laughing :)

You have to get to grips with understanding what HTML is first, so forget about CSS display for a minute or 10, in simple terms a block LEVEL element is an element which can logically contain other BLOCK elements. The new wording/description in the HTML specs describes a lot of these elements as FLOW elements, so it's a lot more confusing to explain than it used to be, but I'll try

First you need this bit [w3.org] or you'll be going round in circles all day
<!--================== HTML content models ===============================--> 

HTML has two basic content models:

%inline; character level elements and text strings
%block; block-like elements e.g. paragraphs and lists

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |

<!ENTITY % flow "%block; | %inline;">

it looks complicated but it's not really

  • block and inline level - is is as per their descriptions.
  • "<!ENTITY % block" actually spells out which elements or groups of element belong in the block content model
  • "<!ENTITY % flow" is saying that Flow elements include both block and inline level elements
  • anything not falling into the Block or Flow Entities will be an inline level element

Take the <p> element, it is a block level element, it belongs to the block content model, the <!ENTITY % block.. list tells us this, P is the first element listed in the group

That's a logical assumption anyway even if you didn't see this before, look at the description at the top of that section.. a <p> is not a "character level text string" it's a block of sentences, now looking at the <p>'s definition in the specs [w3.org]:

<!ELEMENT P - O (%inline;)* -- paragraph --> 
%attrs; -- %coreattrs, %i18n, %events --

we see (top line, after the O) that particular block level element can only contain inline elements... indeed in that same link a bit later it says quite clearly:
The P element represents a paragraph. It cannot contain block-level elements (including P itself).

this again is quite logical, if you're typing a paragraph in a WORD document you would not break it e.g. to put in a list.. you would end the paragraph (press enter, </p>) input a list then press enter (open <p>) again to begin a new paragraph. The act of pressing "Enter" tells the WORD document to insert some whitespace.. it would be the equivalent of closing a </p> tag in HTML. In a written paragraph the only thing you likely want to insert without breaking lines is some highlighting or text, underlining or a reference (ref: this might equal a reference link in web terms). As expected all the previous things when translated to HTML elements are inline elements, span for the highlight, span or <u> for the underline and <a> for the reference/link

HTML is a markup language so it's best to think about as just that, not how it will eventually display.. you are expressing to the machine (browser) the context of the parts of your Document in a language it will understand

INLINE LEVEL elements are somewhat easier to understand they really can only contain other inline level elements you wouldn't think about nesting a <p> in an <em> element for instance would you?

A couple of elements that might help clarify how browsers interpret Markup..

<ul> [w3.org] is defined as UL - we can see from the content model quote above it belongs to the block level content model and it's defintion we are told it can only contain <li> elements.. that's HTML101 but you do still see people getting confused over this and trying to put <h3>'s for example directly into a <ul> element without nesting it in an <li>

the <li> element (same link as the ul above) is defined as a LI - and it is a block too, it belongs in the %lists part of the HTML content model (again very top quote and link) according to it's definition it can contain FLOW Elements, this means it can contain both "block and inline level" elements, i.e. any element in the normal flow - the fact that an <li> can contain other block level elements confirms that it belongs to the block level document model.

i.e. it's quite OK to have <li> elements contain <h>eadings and <p>aragraphs which again if you were writing a list makes perfect sense.

another element is the <blockquote> [w3.org] it too belongs in the block level object model, per above, it is defined as blockquote, only able to contain BLOCK level elements.. this one throws people at times as it will fail the validator if a one line "quote" is nested inside it without a wrapper block element.. if you think about it a one line quote is a <q> or <cite> both of which are inline level.. so when you are writing a blockquote you are usually separating a block of text and that text could logically contain headings paragraphs and lists, it's name kind of gives a clue too ;) - So again if you were typing that WORD document you would break a paragraph (press enter).. insert the blockquote (press enter) and then reopen a new paragraph to continue

What catches people out with validating a blockquote, because they haven't wrapped the internal text in a relevant block element, is that BLOCKQUOTE is almost a "non-element" it might be thought of, or abused as presentational by some, in order to get the indent (frequently is in wysiwyg/editor entered text - hmm like entering code in this forum ;)).. BUT in real terms <blockquote> serves exactly the same purpose in HTML as the <ul> or <ol> elements, which is to TELL THE BROWSER what that block of text is and to indicate a default presentational hint, the indent, to it.

To explain the validation, a blockquote must have it's internal content wrapped in <p> <div> <ul>, whatever really, as long as it's a block level element, in other words the content inside it should be marked up as if the blockquote element were not there! The blockquote element itself is for browsers only, so they understand that it should be presented slightly differently BY DEFAULT, exactly the same way that it knows to apply bullets to an <ul> element or numbers to an <ol> by default, the li element by default knows it should have a bullet, but it's the parent <ul> or <ol> element that actually tells the browser which type to apply - blockquote is easier for the browsers, that tells them to indent everything inside it by default.

All the above is MARKUP - the communication between your document/page and the web browser, nothing to do with size of indent, paragraph spacing, etc.. i.e. not the styling

Now you're probably wondering what she's rambling on about eh.. ;)

The point of this little deflection exercise here is to try and explain a little about HTML before getting to it's relationship with CSS, - I think what I'm hoping you can see is that INLINE and BLOCK LEVEL elements are NOTHING to do with how the element should be styled, yes not displayed but styled, and that the visual DEFAULT DISPLAY of browsers, of plain HTML, is no more than white space, where you would expect it, to keep a plain Text Document at least in some way legible

Plain HTML will produce a very basic Word processed like document, it knows to have carriage returns and a line feed where the <p> is closed.. If you know how to use a word processor you know you type your Document in plain text then when finished you cango back and reformat headings, paragraph spacing, list indents, colors etc.. that's what CSS is to HTML, formatting beyond the basic output

to carry on the anomaly, in a Word Document if you want text side by side you can draw a text box, move it where you want, and then move a whole section of your existing document inside it, or a single image.. or whatever you're trying to place somewhere different.. that text box is a generic container, in other words in HTML it would be equivalent to a DIV ;)

You could of course format a Word Document using a table too, and if you did it would then be much clearer that you then have a lack of flexibility to move objects around.. this is just a theoretical reference as I'm sure that there's not a lot of seasoned Word Processor users who would choose to format a Word document this way, however the outcome of such a theoretical exercise would show exactly the same reasons why tales for layout are just plain wrong..

as an exercise you could try taking a tabular laid out page and remove any CSS or inline styles (old fashioned deprecated ones too), background images or indeed inline presentational only images.. now try reading that document in a browser.. what do you think?

OK you can start thinking about CSS again now :)

What CSS does is to take the already existing correct, and valid markup and suggest, within the browsers capabilities, an alternative way to display it. CSS has the ability to display an INLINE LEVEL element as a square/rectangular box (display: block;) or indeed a BLOCK LEVEL element as inline text.. e.g. making an <h2> element display as "run-in" to the following <p>

the CSS display property values [w3.org]:
inline | block | list-item | run-in | inline-block | table | inline-table | table-row-group | table-header-group | table-footer-group | table-row | table-column-group | table-column | table-cell | table-caption | none | inherit

are a way to tell the browser to display an element "like" it already knows how to display some other items by default

While some of the above values don't have full cross browser support, perhaps the easiest one to use as example is
display: list-item;
which simply tells the browser you would like whatever element to display like a <li> element with a bullet! If you have applied that CSS display value to a <p> for instance, it doesn't change the fact that the element is a paragraph it simply gives it a bullet, and if it wasn't already a block level element it would generate a block box around to make it look like a <li> element

as to why you want a bullet on a <p> I don't quite know but this a theoretical example to point out that if you did decide that you wanted a bullet or icon before a <p> because of your design, you wouldn't or shouldn't be thinking about that at the HTML stage, if it's to be a presentational change only .. leave the MARKUP alone and work the magic with CSS after the fact.

any clearer?..possibly not, it's a long time since I tried to explain HTML lol! but until you get the AHA moment, I think the best way to try this table to CSS conversion is to realise that you CAN & SHOULD MARKUP the page without thinking about the final look of it.. in your case, in fact anyone who is trying to wean off tables, you can do it a table CELL or ROW/section (header, footer) at a time as you do bits you will eventually see that the logic is always the same and it always, always hinges on the correct HTML in the first place ;)

OK off to look at your page now to see if we can help make this easier for you.. see you later

9:50 pm on Feb 19, 2011 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

position of the element should be defined and working with tables can cause problems.

just to let you know I'm not ignoring the original question, and that the "tables causing problems" bit is quite true

the z-index will not work to overlap table cells, despite the fact I think that IE may also have a problem with overlapping an iframe, I cannot test it all - for the first time ever the code is crashing my (old trusty) HTML editor :( so I'm trying with the new one

in all I'm pretty sure that there is no z-index in the world that will bring the sub menus "above".. it's the table cell overflow (or lack of) which is the problem here

in other words this is the barrier where most things will work within tables cell, but positioning never has - therefore z-index won't!

but bear with me.. I will keep trying
8:44 am on Feb 20, 2011 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

grrr.. it's a combination, and nothing to with CSS z-index really

I'm not able to get z-index to work with the table and the new youtube iframe code, I was able to get it to work with the older style embed code, which was going to be my advice.. to change back to the old style BUT! then I found this little gem ;)

add "?wmode=opaque" to your iframe source URL

in your case because you already have ?rel=0.. add
after that..


as far as I can tell no extra z-indexing is required :)

as an aside, having now looked at your site.. It's very neatly coded, and I know you are transitioning between Tables and CSS so I note that tables are not nested which is great, it would be easy to start replacing some of them especially that header logo, and the CSS file itself could be optimised by grouping selectors, or learning where you do not need to keep redeclaring things like font-family, because of inheritance.. want to try?
1:41 pm on Feb 20, 2011 (gmt 0)

Hi Suzy,

First of all, thanks for your explanation and the research you did on the z-indexing.
The z-index I will try later today.
As to all other things you have mentioned:
I will print it and read it, that's always the best way for me to learn something new/difficult. I need a bit more time before I have implemented it in my brains. Had to meet yesterday's deadline for the site I talk about here and immediately may continue with a new deadline for an other site. And I don't get even paid for it. :-)
I work as a volunteer and obviously I like webdesign. The learning part is very important to me, I don't want to get stuck at a level where I feel limited of implementing things because of a lack of knowledge and I only want to work on sites where I need to learn new things.
In about 2-3 weeks I have an ocean of time or so I tell myself. That will be spent on making plans for the next thing and that one is definitely going to be without tables, otherwise I will be stuck there forever. Could be I take the above mentioned website to a better level and add new things to it, depends on a few things. I will however be back on this item, surely I run into troubles when trying to abandon table lay-out.
12:16 am on Feb 22, 2011 (gmt 0)

Hi Suzy,

I implemented the &wmode=opaque and it works perfectly. Tried what the influence of z-index was and it turned out that I needed a z-index on this one: #siteNavigation ul ul ul li
Thanks for your help.

Do you happen to know why the border width (for the frame) is not behaving itself as I expect/want it to do. When I specify a border, I get a border, but it doesn't react upon the width: 5px gives the same result as for example 20px.

Featured Threads

Hot Threads This Week

Hot Threads This Month