Sent by Arlen Walker on 26 May 2003 17:05
OK, let's use Ryan's problem to go over some basic CSS debugging
techniques. I'm doing this in the open, so to speak, because I'm
personally getting tired of general, blanket "fix my design" requests
(OK, so I'm a nasty old curmudgeon who doesn't belong out in polite
society; I really don't care if anyone thinks that it's rude of me).
It's broken in (at least!) two browsers so we'll start with one and move
on to the other, and perhaps we'll uncover what's going on along the
way. I'll start with IE5/Mac, which has only a minor break.
First, since the divs aren't going where we'd like, let's look at what's
actually happening. First, set all the divs to different background
colors. This will show you where they are (if the div has an entire
background image, then add a border, decreasing the width of the div by
twice the border, to make sure it fits in the same hole).
Doing this we note that #content is floated right, and overlaps #left by
a few pixels (experimentation shows it's four pixels, so decreasing the
width from 467px to 463px fixes that part of the display). Now, where
did those four pixels go? I'll be honest and say I don't know. Further,
I don't care. Pixel-perfect designs aren't possible; they are
*guaranteed* to break in one device or another, so why waste time
worrying about it? Only worry about it when it breaks the design, and
having an extra 4 pixels or so of whitespace between the nav buttons and
the content in some browsers isn't even going to be noticeable, so
that's one detail I'm not going to sweat in this design. Were it
important, I'd start doing the math on every element, checking each and
every one against what width I think it should be using, until I found
the culprit.
What else do we see? That the footer is way down, and there's no right
border below the content. Why? Because #bodyblock is given an explicit
height, which extends far below both of the content boxes. #bodyblock
carries with it a left background but not a right one, hence the gap on
the right. So we kill the explicit height, and what happens? Not only
does *all* of #bodyblock disappear, but also the footer.
Why? Because both container blocks inside of #bodyblock are floated,
which takes them out of the normal document flow, rendering #bodyblock
effectively at zero height. So it and #footer are actually hidden behind
#left and #content. We prove this by narrowing #content by 20px and we
can see the bar of #footer peeking out between the two floated divs.
How do we fix this? One way is to add a div to #bodyblock which waits
for the two other containers to end. So we create an id #endbody that is
styled with "clear:both;" to make it wait. Then we put the right bar in
the div background and theleft bar in the div itself. It's not the
cleanest fix, but it works. A cleaner fix is to make the background of
#endbody transparent, but that causes problems for NN4. Leaving off the
background color completely is an exercise I leave to the reader.
In either case, now we have a design that works in IE5/Mac. Along the
way we cleared up a couple of issues, so let's just test this design now
in Gecko. Better, but no cigar. Now there's a break in the background
bars above and below #content and some suspicious stuff going on the the
left of #left.
In #left, there's a padding-top statement, and the problem could be
related there. So we change padding-top to padding and explicitly set
the rest of the padding to zero. Almost fixed. Then we expand the width
of .menu to 153px (175px -- width of containing block -- minus 22px --
width of background graphic). Voila. Or almost.
The text in #left still doesn't appear. That's because it's underneath
the floated nav list. So we add "clear:right;" to the class description
of little and make it two paragraphs instead of one with two breaks in
it (what's up with that, anyway?) and *now* it's OK.
Now the breaks in the right border. To the definition for #content we
add top: -1em; which compensates for the positioning of the float down
one line. Adding that factor to the two divs at the end closes the gaps
as well.
I should note that this is just one way of fixing the design in Gecko.
I'm sure a perusal of some of the articles at devedge.netscape.com could
turn up a more elegant way of fixing it. (That's a hint. Anytime you
have trouble with Gecko, DevEdge is the first place to turn.)
Anyway, I've walked through a debugging session with two of the problem
browsers. I've not done all the work (my time is not infinite) but I've
done enough that the method should be clear. The design works in the two
target browsers, now. I will leave the rest as an exercise for the
interested. Rinse. Lather. Repeat.
How would someone else have tackled that problem?
Have fun,
Arlen
-----
In God We Trust, all others must supply data
______________________________________________________________________
css-discuss [EMAIL-REMOVED]]
http://www.css-discuss.org/mailman/listinfo/css-d
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
