IE5/Mac float problem - CSS forum at WebmasterWorld - WebmasterWorld

Forum Moderators: not2easy

Message Too Old, No Replies

IE5/Mac float problem

christripledot

11:58 am on Jun 9, 2011 (gmt 0)

10+ Year Member

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

1:45 pm on Jun 9, 2011 (gmt 0)

10+ Year Member

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

2:07 pm on Jun 9, 2011 (gmt 0)

10+ Year Member

Thanks Paul, but sadly word-wrap makes no difference.

rainborick

3:08 pm on Jun 9, 2011 (gmt 0)

WebmasterWorld Senior Member

10+ Year Member

Top Contributors Of The Month

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

3:13 pm on Jun 9, 2011 (gmt 0)

10+ Year Member

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

3:56 pm on Jun 9, 2011 (gmt 0)

10+ Year Member

@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

6:45 pm on Jun 9, 2011 (gmt 0)

WebmasterWorld Senior Member

10+ Year Member

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

9:43 pm on Jun 9, 2011 (gmt 0)

10+ Year Member

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

1:42 am on Jun 10, 2011 (gmt 0)

WebmasterWorld Senior Member

10+ Year Member

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

11:39 am on Jun 14, 2011 (gmt 0)

10+ Year Member

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]