Outfox the Firefox?

[expat]

Why are the smileys over to the right in 3 columns with the rightmost over the CUK Navigation links?

Is it CUK that is wrong, Firefox that is wrong, or is it just an administrative oversight, nothing to see here, just leave it to us?

[TheFaQQer]

Depends on your screen resolution.

[expat]

Depends on your screen resolution.

Ta, but I thought that the whole point of the Markup/Browser model was that I got to decide that?

It's 1024 x 768 on this machine.

[BrowneIssue]

In IE there is a horizontal scroll bar at up to about 1100 pixels width, in Firefox up to about 950 pixels.

In IE the grey bit the smileys are on is unobscured. The white "contractor alliance" and other advert boxes are to the right.

In Firefox, they float further in and float under the smileys but over their grey box.

[expat]

In IE there is a horizontal scroll bar at up to about 1100 pixels width, in Firefox up to about 950 pixels.

In IE the grey bit the smileys are on is unobscured. The white "contractor alliance" and other advert boxes are to the right.

In Firefox, they float further in and float under the smileys but over their grey box.

Well, that's pretty well what I noticed. But it does not seem tome to be "correct" in termes of what I would expect a browser to do.

Still, I learned on Script/VS so what do I know?

[realityhack]

Mods - if you make the class '.vBulletin_editor' fluid it should fix this problem. Try experimenting with a % width inside the 'panel' class.

[realityhack]

Actually, looking into this in more detail you've got a tableset with this div and td.controlbar in there as well. '.vBulletin_editor' is 100% width and the whole cell is keeping its width when you reduce the size of the browser window, leading to this overlap. You could take away the tables and use relative positioning, giving the right-hand boxes a lower z-index so if they do overlap, they go under the editor box.

[DiscoStu]

Actually, looking into this in more detail you've got a tableset with this div and td.controlbar in there as well. '.vBulletin_editor' is 100% width and the whole cell is keeping its width when you reduce the size of the browser window, leading to this overlap. You could take away the tables and use relative positioning, giving the right-hand boxes a lower z-index so if they do overlap, they go under the editor box.

Is this your entry in the nerd of the week competition?

[realityhack]

Is this your entry in the nerd of the week competition?

I think it's the iframe that's called in the td class 'controlbar'. this code here:<iframe style="border: 2px inset ; width: 540px; height: 250px;" tabindex="1" id="vB_Editor_001_iframe"></iframe> that may be causing the problem.
It's not something I can correct using CSS alone - a change has to be made to the template. Sorry.

[NickFitz]

Actually, looking into this in more detail you've got a tableset with this div and td.controlbar in there as well. '.vBulletin_editor' is 100% width and the whole cell is keeping its width when you reduce the size of the browser window, leading to this overlap. You could take away the tables and use relative positioning, giving the right-hand boxes a lower z-index so if they do overlap, they go under the editor box.

I think it's the iframe that's called in the td class 'controlbar'. this code here:<iframe style="border: 2px inset ; width: 540px; height: 250px;" tabindex="1" id="vB_Editor_001_iframe"></iframe> that may be causing the problem.
It's not something I can correct using CSS alone - a change has to be made to the template. Sorry.

What he said

FWIW it does the same in Safari and Opera - can't be bothered to check the crock of tulip that is IE.

If it is coping in IE 6 and 7, then it's a good demonstration of the first rule of page layout: if it looks right first time in IE then you have done it wrong. Get it looking right in the browsers that work properly (Firefox, Opera, Safari, Konqueror et. al.) and then see what IE bugs have been triggered and apply the necessary fixes in such a way as not to affect the real browsers.

(Hint: applying "zoom: 1;" to the relevant block-level containers is usually all that's necessary, unless you start running into things like the Three Pixel Text Jog, the Magik Creeping Text or the phenomenally stupid IE7-crasher I identified over the last few days, and haven't yet reduced to the absolute minimum test case - when I say "crasher", I mean "The task is not responding" style crash.)