Forum Moderators: not2easy
.. address line 1
.... address line 2
..... address line 3
...... address line 4
...... contact us line
(Sorta like that.) Works beautifully in FF, IE7, 8, of course IE zapped me with the double margin bug, pushing the whole thing to the right; I fixed this with display: inline on the containing div.
Closer. Still a bit off to the right, I added display: inline to the ul. Closer still ...
Which breaks it in IE 7. This now adds padding/and or margins back into the li's. Although it's "closer" in IE6, I can see it's also re-padding the li's in spite of zero margins/padding on the li's.
Note the bolded line in the CSS. If I remove this line, all is well with IE7. but it gets pushed farther off to the right in IE6.
Ideas? Without hacks, hopefully? :-)
Borders left on to demonstrate problem, has no effect on the workings of the mess.
CSS:
body,html {
background: #F0F9FF;
font-size: 90%;
font-family: Verdana,Arial,Helvetica,Sans-Serif;
margin: 0 auto 18px auto;
padding:0;
color: #000000;
}
#header {
width: 935px;
height:276px;
margin: 0 auto 0 auto;
padding:0; background:
url(../images/image-with-oval-on-left.jpg) top left no-repeat;
}
#head-info {
border:1px solid #000000; /* for bug test only */
float:left;
width: 400px;
height: 150px;
margin: 0 0 0 150px;
display:inline; /* double-margin bug for ie 6 */
padding:0;
}
#head-info ul,
#head-info h3 {
margin: 24px 0 0 0;
padding:0;
text-align:left;
}
#head-info h3 { color:#ff0000; }
#head-info ul {
border:1px solid #ff0000; /* for bug test only */
float: left;
width:300px;
margin: 24px 0 0 38px;
padding:0;
font-size: 11px;
font-weight: 700;
display:inline; /* double-margin bug for ie 6, kills ie7 */
}
#head-info ul li {
border: 1px solid #00ff00; /* for bug test only */
margin:0;
padding:0;
list-style: none;
}
#head-info ul #address2 { margin-left: 10px; }
#head-info ul #address3 { margin-left: 14px; }
#head-info ul #address4 { margin-left: 16px; }
#head-info ul #address5 { margin-left: 18px; }
.clear { clear:both; }
HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!-- doctype on one line -->
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Title</title>
<meta name="Description" content="desc">
<meta name="keywords" content="kw">
<link rel="stylesheet" type="text/css" href="css/test.css">
</head>
<body>
<div id="header">
<div id="head-info">
<h3>1-800-PHONE NUMBER</h3>
<ul>
<li id="address1">Address 1 Phone 1</li>
<li id="address2">Address 2 Phone 2</li>
<li id="address3">Address 3 Phone 3</li>
<li id="address4">Address 4 Phone 4</li>
<li id="address5"><a href="#">CONTACT</a></li>
</ul>
</div>
<div class="clear"></div>
</div>
</body>
</html>
I haven't tried the old technique of wrapping the margin'ed div in another wrapper, trying to avoid div-itis . . .
Double margin bug can also be fixed by halving the value you give if you use conditional comments ;) , all you do with conditional comments is to fix the effects of the bugs, if IE were a decent browser it would be an empty file (for the record: so far I've not yet needed an IE8 specific file using this approach).
edit: typos
[edited by: swa66 at 10:34 pm (utc) on May 19, 2009]
According to what I've read, a float element takes on block properties no matter what type of display it had before, so applying display:inline to a floated element has no effect on any sensible browser. (Yes, I know this *is* a hack . . . but anyway . . . )
But why - err, stupid question - does anyone know - why adding display:inline to the UL re-adds padding back to the li's? If it weren't for that it would be fixed.
ie is drawing list-style-position:inside rather than the default list-style-position: outside. Allowing space to accommodate the marker box creates the appearance of padding/margin on the left of the text. Specifying list-style-position: outside on the li removes the unwanted gap, and this worked regardless of the display on the ul so I doubt that's the sole source of the issue.
However setting the list-style-position is really another "fix". Is it possible to re-think the code - perhaps relative positioning rather than floats to avoid the float issues, or use of the address element to avoid the list issues?
Also, the reason for using floats is not clear - on the provided code the ul doesn't seem to be pushed to the right if the float is removed. If the real-world code has something to the right, is it possible to use display:inline-block instead? Replacing the floats with display:inline-block on div#header-info and the ul displays consistently cross-browser (tested in Op9.6, winSafari3,ff3, ie6&7) and standardises the rendering, plus avoids the double margin bug and so the need for the display:inline "fix" for ie, plus avoids the additional left "gap" on the list-item, plus the clearing div.
That said, this is a neat combination of ie list oddities, float issues, a transitional doctype and display and float being modified between css 2 and 2.1. Inspection produced interesting results about the rendering of floats given the default "block" display has been explicitly changed, as well as lists given the margin/padding:0 on the li are having no effect(even when explicitly setting display:list-item to trigger ie out of "block"). Am sure the answer is obvious, so maybe this will prompt some further reasoning. On your existing code, using firebug, winSafari webinspector and ie inspector:
div#header-info
provided css: display:inline
ff: display:block
ie: display:inline
saf display:inline
ul
provided css: display:inline
ff: display:block
ie: display:inline
saf display:inline
li
provided css: display:-not specified-
ff: display:list-item
ie: display:block
saf display:list-item
provided css: list-style-position:-not specified-
ff: list-style-position: outside
ie: list-style-position:inside
saf display:list-style-position: outside
Despite the differences both winSaf and ff produced the same visual layout.
Is it possible to re-think the code - perhaps relative positioning rather than floats to avoid the float issues, or use of the address element to avoid the list issues?
Absolutely, I'd rather rebuild it than hack it and will investigate (was wondering if the address rec. would come up. :-) )
Also, the reason for using floats is not clear
I did try #head-info without floats, all those are added to try and get IE 6 to play nicely. There are other elements contained within #header that follow this simple top div that needed to float to have #header shrink wrap the entire chunk.
All very enlightening and will return to this one shortly, thank you.
Always have concerns about employing floats to achieve "shrink-wrapping" - but maybe that was shorthand for your full reasoning as this was just a quick update.
"floats", "ie6" and "play nicely" ... commendable optimism!
I appreciate this has a real-world deadline, but if you have time, would be keen to see the complete #header + contained elements - I sense even more interesting issues lurking within. ;)
how about removing the margins and using padding instead, this removes the need to use any IE hacks I think (well the few I tested in..
padding: 24px 0 0 38px;
margin:0;
Not sure I would go adding positioning in as we already know that position relative can bring many other IE problems, will have a play around though, did you try with the address element instead?
Flowing text around an image is a rather common layout, yet it's quite difficult to do allowing for all variables in the game.
First we cannot (nor should we be able to) fix the size of the font used, nor know if the font of choice is even available. Hence positioning text remains quite tricky. E.g. what if the first line was 6 times as tall as we expected ... oops.
Now few people will have such "extreme" browser preferences, but they do exist (and quite more extreme as well) and are mostly used for a very good reason don't tel them to use a screen reader instead, that's plainly offensive.
So that leaves us to look for a way to have irregular shapes that can push inline content to a side.
There's no clean solution.
On way is to only use a rectangle, and well then it's easy enough, but that hardly fulfill the wishes.
Another would be to add a number of rectangles to together protect the image from getting text over it.
In part this can be achieved but it adds superfluous elements to the html.
(float and clear set on all of them and they'll push your text away).
But there are a few browser issues when doing this: some browsers do let bits of text stick into the protected areas ... (it seems the don't anticipate a second float to push the same text aside too), which becomes more apparent with taller letters.
A third alternative is to use fixed sized fonts and hope those in need of taller fonts have a browser that can zoom everything and not resort to a minimum font size begin set.
While for continuous text this isn't a workable solution, for the OP it means you can use positioning at will, just be aware you don't really have control of the size of the letters (in either direction), so leave some room.
The logical solution to me would be to have a container gain position (using e.g. position: relative) and then position the text blocks I want where I want them using absolute positioning of the individual elements in relation to that parent that has position.
A better alternative: sure let's hear it , but I'm afraid this is one for the wish-lists over at w3.org
