John Faulds wrote:
I had that there because the top link in the sidebar seems to get
partially obscured by the transparent PNG of the ball. I'm sure it
was working at some point, but doesn't seem to be now. :/
You can keep the...
#sidebar {
position: relative;
z-index: 200;
}
..._if_ it solves the "obscuring-problem". It doesn't at my end.
However, then you must also stabilize #sidebar's relation to #content,
and fix a few IE/win bugs while you're at it, by adding...
* html body #content {
overflow: visible;
zoom:1;
position: relative;
}
I won't start listing all potential IE/win bugs involved, but they are
the reason I never go anywhere near any of the latest "holy grail"
solutions.
I've tried moving the font-size to the wrapper and using the revised
expression for px/em-based min/max-width from your example but it
doesn't stop the page shift and also the max-width doesn't get
applied either.
The pixel-based min/max version is a much easier solution then, but
yours needs adjustments. The 4% missing with a fluid state of 96% width,
is not identical to the 18px you have between "attack" and "max-width"
values, and same goes for the 'min-width' part. It is percentage of the
body-width you're dealing with, and that naturally varies with window-width.
Calculate new values or tune them by testing, until there's no jumping
at either end and no appearing horizontal scrollbar when in the fluid
state. Will work well enough for most, I think.
I see maybe a 1px horizontal jump when hovering any link now - in my
corrected copy and your present page, and that's hardly enough to "hunt
and kill IE/win bugs" for.
regards
Georg
--
http://www.gunlaug.no
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
