| IE5/Mac float problem
|
christripledot
msg:4323969 | 11:58 am on Jun 9, 2011 (gmt 0) |
Hello there,
I know we all need to move out of the dark ages, but my client doesn't. I have a problem related to floats in IE5/Mac (sigh).
I have two <div>s floated side by side. The problem is that IE5/Mac doesn't seem to respect the "overflow: hidden" property, and so long unbreakable words cause float drop.
I've searched high and low for a solution, but almost everything I've found to do with IE5/Mac float bugs is to do with 'containing' floats. Does anybody have any ideas how to fix this?
Test case below. Thank you for looking :)
<!DOCTYPE html>
<html lang="en-GB">
<head>
<meta charset="UTF-8" />
<title>IE5/Mac float tester</title>
<style type="text/css">
* { margin: 0; padding: 0; border: 0; }
body { font-size: 100%; }
.col1, .col2 { overflow: hidden; }
.col1 {
float: left;
width: 49%;
background: red;
}
.col2 {
float: right;
width: 49%;
background: green;
}
</style>
</head>
<body>
<div class="col1">Averyverylongunbreakablewordgoesherethetextshouldbeclippe
dorwordwrappedbutnotinie5formacforsomeunfathomablereason</div>
<div class="col2">Foobar</div>
</body>
</html>
Cheers,
Chris [edited by: alt131 at 12:08 pm (utc) on Jun 9, 2011]
[edit reason] Tidy [/edit]
|
Paul_o_b
msg:4324007 | 1:45 pm on Jun 9, 2011 (gmt 0) |
I don't know if ie5mac supports word-wrap but its supported in IE5 so worth a try.
.col1,.col2{word-wrap:break-word}
|
christripledot
msg:4324016 | 2:07 pm on Jun 9, 2011 (gmt 0) |
Thanks Paul, but sadly word-wrap makes no difference.
|
rainborick
msg:4324067 | 3:08 pm on Jun 9, 2011 (gmt 0) |
I'd suggest that you change to an older, complete <!DOCTYPE> that IE5Mac would recognize. Using the HTML5 <!DOCTYPE> is likely to throw IE5 into Quirks Mode, where its CSS support is going to be significantly different than contemporary browsers. If you use a <!DOCTYPE> that it will recognize as requesting Standards Mode, you'll at least have a fighting chance of compatibility.
|
Paul_o_b
msg:4324071 | 3:13 pm on Jun 9, 2011 (gmt 0) |
I used to have an old imac for testing ie5mac but I threw it in the bin about 5 years ago so can't test anymore.
I would try nesting an inner element inside the float and set it to width:100% and try applying the overflow:hidden to that element instead.
I do remember that IE5mac did have a number of problems with overflow but its so long ago I can't remember what I used to do about it I'm afraid :)
|
christripledot
msg:4324110 | 3:56 pm on Jun 9, 2011 (gmt 0) |
@rainborick:
The HTML5 doctype throws IE5/Mac into almost-standards mode, which is the best that browser can offer! I observe exactly the same behaviour with an HTML4.01 Strict doctype...
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
I take your point about choosing a doctype with care, but IMHO the new HTML5 doctype is pretty transparent, and it's a lot cleaner. You might find this page interesting:
[hsivonen.iki.fi...]
@Paul_o_b:
Your solution works, sort of. The overflowing text is now clipped successfully, but now the browser window gets a horizontal scrollbar to accommodate the (invisible) long text. But, this can in turn be solved by wrapping both floats in another container with overflow:hidden. I was hoping I could avoid adding extra markup, but idealism has already left the building and I just want to keep the client from spitting fire.
What an ugly mess. Still, thanks to both of you for all your help! FWIW, here's the working mess:
<!DOCTYPE html>
<html lang="en-GB">
<head>
<meta charset="UTF-8" />
<title>IE5/Mac float tester</title>
<style type="text/css">
* { margin: 0; padding: 0; border: 0; }
body {
font-size: 100%;
overflow: hidden;
}
.colclipper {
overflow: hidden;
}
.col1>div, .col2>div {
width: 100%;
overflow: hidden;
word-wrap: break-word;
}
.col1 {
float: left;
width: 47.5%;
background: red;
}
.col2 {
float: right;
width: 47.5%;
background: green;
}
</style>
</head>
<body>
<div class="colclipper">
<div class="col1"><div>Averyverylongunbreakablewordgoesherethetextshouldbec
lippedorwordwrappedbutnotIE5forsomeunfathomablereason</div></div>
<div class="col2"><div>Foobar</div></div>
</div>
</body>
</html> [edited by: alt131 at 5:17 pm (utc) on Jun 9, 2011]
[edit reason] Tidy [/edit]
|
alt131
msg:4324206 | 6:45 pm on Jun 9, 2011 (gmt 0) |
Hi christripledot [webmasterworld.com], and welcome to WebmasterWorld :)
I realise you are at the end of this, but some thoughts that might prompt something to avoid the additional mark-up.
@Paul, regards overflow:hidden, I too remember it as problematic, but just looked at an old site with expanding float troubles and that's part of the solution - not a helpful discovery ;) I'm really surprised word break didn't work though - can you remember if ie5Mac supported <wbr>? -
ie5Mac with a full doctype should be in standards mode, but in quirks, it defaults to the border box-model, so if the real-world code has padding/margins, that may be accounting for the additional width. Ditto, there were a slew of scroll-bar bugs, and I have a vague recollection of issues with adding an additional 15px, fixed by a negative margin - although I think that was absolute elements.
However, my old code used position:relative in a couple places (not just on :hover to correct the links issues with negative margins). relative is my least favourite technique, so its presence informs, and may be worth trying. Finally, I also recollect old ie disliked %width elements if the parent lacked a specific width.
So overall I wonder if the easiest way to avoid extra mark-up is to give ie5Mac a different width and/or negative margin. That may not prevent the "invisible" text escaping, but it should stop the scrollbar, and could be sent via a conditional comment - which keeps all the ie5Mac css away from other browser/versions as well.
|
Paul_o_b
msg:4324297 | 9:43 pm on Jun 9, 2011 (gmt 0) |
Sadly most of my IE5 mac memories went into the bin with the machine :) I do however remember the extra 15px margin on absolute elements bug but can't remember if <wbr> was supported unfortunately. It's a shame to add code bloat for such an old browser but if it keeps the client happy....
|
SuzyUK
msg:4324376 | 1:42 am on Jun 10, 2011 (gmt 0) |
OMiGosh! this is blast from the past.. unfortunately I too have forgotten.. however I'm thinking the "holly hack" may hold a clue
the original hack used to say (without the fancy after bits..):
.clearfix {display: inline-table;}
/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */ |
|
In other words IE/Mac didn't need the hasLayout (height hack) nor did it need display: inline-table overridden with display: block
what that suggests to me is that display: inline-table just might be magical mac property.. yes I know the Holly Hack is/was used for clearing/containing floats.. but I'm thinking what happens if you make the "floats" inline-tables, does that help?
Or does just containing the floats (as per the old way) in an inline-table help the overflow or word-break? mine is in't bin too, but I think trying this might be the best bet
If replacing the floats with inline-tables works you would need to hide the floats (display block) from Mac but the how to do that,Mac hiding hack, is there too.
.. actually did inline-block work for ie5/mac it was pretty cutting edge in its day and even IE/Win supported inline-block since 5.5
just throwing some thoughts out there
|
christripledot
msg:4325854 | 11:39 am on Jun 14, 2011 (gmt 0) |
Hi Suzy,
I noticed that IE5/Mac doesn't seem to suffer from the hasLayout bug. In my case display: inline-table doesn't improve things, so I think I'm gonna stick with my solution. Although it uses unnecessary markup in the HTML, I prefer my CSS because IMO it is more readable. All the hacks are obviously related to containment. As soon as you start messing with things like inline-whatever, stuff can get ugly real quick.
Slightly OT, but I don't really see the issue with 'unnecessary' <span>s and <div>s in situations where there is no semantic alternative. Aren't these elements supposed to be 'content-neutral' (semantically, at least)? All the screenreaders I've messed with don't give a <snip> about <div>s.
In any case, who's ever tried to get under the bonnet with PDF accessiblity? What a can of worms... So many 'Artifacts' flying around the place; correcting the reading order sometimes messes with the z-index of drawn objects (esp. when clipping masks come into play); it's the stuff of nightmares.
Give me simple CSS and meaningless <div>s and I'm a happy man.
P.S. Thanks to all of your generous replies I now have a happy client :)
Cheers all!
- Chris [edited by: alt131 at 12:00 pm (utc) on Jun 14, 2011]
[edit reason] Tidy [/edit]
|
|
|
