display:table and padding??

[dresden_phoenix]

I have a 960px fix width page that is segmented horizontally. One of the segments is a navigation, which contains a UL which contains a BG image. For that reason, I want the UL to have 240px of padding on the left and 30px of padding on the right.

Because I MAY have a drop down menu in this navigation, I used display:table instead of overflow:hidden for it to clear its child floats.

Here is the weirdness :

I used the regular box model to calculate the width. 960-(240+30)=690px.
in FF this works great, but Safari is treating it like the old IE box model bug.. that is the width of the table is 690px INCLUDING the height. GRRR. Is this a bug in Safari (or a bug in FF)? Is there a way around it?

    #navW ul.nav{ background:url(images/design/klaas_nav.jpg) no-repeat left top #000; margin:0 auto; width:960px; display:table; table-layout:fixed; list-style:none; padding:.5em 30px .5em 240px;}

[Paul O'B]

Hi,

I have noticed before that Firefox, Opera and Ie8 seems to add the padding to the width of the table whereas chrome and Safari do not.

If you try the same thing with an actual table then all behave the same and keep the width as set and place the padding on the inside thus reducing the available cell-width.

As display:table should mimic table behaviour then I would guess that Firefox is wrong but I could not find it defined in the specs so it may be one of those things left to UAs to determine.

As a solution you can specify border-box and then all will behave the same and contain the padding.

.nav{
    -webkit-box-sizing: border-box;
    -moz-box-sizing: border-box;
    box-sizing: border-box;
}

Of course you would now need to extend the width to cater for the internal padding.

[dresden_phoenix]

I was thinking that that might be the way, thanks Paul!!!

[deathshadow60]

Or you could just use another float clearing method or fake it with height -- I fake it using height a good deal since I don't trust display:table or it's kin as yet for the reasons outlined. I'd be looking at doing whatever it is you are trying to do a different way, rather than waste time throwing browser specific code at it as the answer.

Though as I often say CSS without the markup it's applied to is gibberish, and without seeing the entire layout or at least just the section in question we're guessing in the dark... Though the 'lets shove everything on one illegible line of CSS" routine isn't helping matters much either on figuring out what's going on.

Oh, and being a menu inside a fixed width, the use of EM padding (and probably EM fonts?) is likely going to break your layout on large font/120dpi setups... and probably give you different heights between FF and RoW. (Rest of World)

Also... is #NAVW an unnecessary DIV around it, if so why not set the total width there and then just pad separately (since declaring padding/borders same time as width is something I usually try to avoid in my code), and is there something wrong with the parent of #navW that you can't pick up your width off of that instead?

Basically, I suspect you're over-thinking your solution.

[Paul O'B]

As Jason said you could also clear with something else and avoid the problem.

Display:inline-block will also clear floats and is less of a change to the element than display:table but you would need to center it with text-align:center on the parent.

Remember that min-height won't work on elements with display:table either.

[dresden_phoenix]

I used min-height???? For some reason I was afraid to use inline block because i thought it was LESS cross browser friendly.

Also... is #NAVW an unnecessary DIV around it, if so why not set the total width there and then just pad separately (since declaring padding/borders same time as width is something I usually try to avoid in my code), and is there something wrong with the parent of #navW that you can't pick up your width off of that instead?

Well the wrapper is necessary for the layout, but the layout itself its difficult to explain. it is composed of VERTICALLY FLUID horizontal sections (log in/ logo)/(branding) /(main navigation) /(content) /(footer). the background of the wrappers and the background of the actual content are different colors and images. so for a(modified to show my point) example:

#navW has a bg of #ccc, also it has a border-top of 2px as a color transition between itself and the previous section, which need to stretch across the viewport.
#navW ul.nav has a bg of #000 AND an image.

so overall I have achieved this effect with only a DIV and a UL ... I'd say that's pretty efficient.

[Paul O'B]

I used min-height????

I was just mentioning that there would be a problem if you had used it

For some reason I was afraid to use inline block because i thought it was LESS cross browser friendly.

On a block element it will have no effect in IE6 and 7 except to add haslayout which solves the float clearing problem anyway.

In other browsers it will make the element an inline-block element and you would need to center it with text-align:center on a parent as auto margins won't work.

There would be white-space issues if you had a number of blocks but as a page-wrapper this isn't really an issue but I wouldn't use it as a general clearing method on all elements though - just for main wrappers.