Forum Moderators: not2easy
(Note: I was running IE5 standalone, I actually have IE6 installed on this computer; I haven't been able to test it on a real IE5 install, so maybe it's just running it independently that's the problem.)
If you have a width-defined float in a table cell, it won't appear in IE5. If you try selecting the text where the float is supposed to be, however, they appear again.
Here's the example XHTML/CSS file I whipped up:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>Dynamically Generated Floats :: Disappearing Text, IE5/Win</title>
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
.calExample {
width: 120px;
border: 1px solid #f00;
position: relative;
}
.calExample .a, .calExample .b {
float: left;
/* added for emphasis */
margin: 1%;
text-align: center;
font-weight: bold;
background: #66f;
}
.calExample .a {
width: 14%;
}
.calExample .b {
width: 66%;
}
p {
clear: both;
}
/*]]>*/-->
</style>
</head>
<body>
<div id="container">
<table class="calExample">
<tr>
<td class="calCell">
<p>Below are three floats. If they don't appear, highlight the entire page to view them:</p>
<span class="a">1</span>
<span class="b">2</span>
<span class="a">3</span>
<p>Like magic, they appear.</p>
<span class="b">Magic</span>
<p>Happens with any width-defined floats in a table cell, only in IE5/Win! Are there any fixes to be found?</p>
</td>
</tr>
</table>
</div>
</body>
</html>
My page is a good deal more compilcated, but I'm still getting the bug, though it's only when the table is generated via JavaScript. As for alternatives, I've already tried, instead of floats, absolutely positioning the elements-- ironically, though, it triggered bugs in IE5.5 and IE6, while IE5 got it correct... and I feel more comfortable using clearing divs than I am an unnecessary wrapper element, which was necessary just to get Mozilla to position them properly... oy. Floats is just a more viable option for me.
Any fixes or workarounds are appreciated! (CSS ones preferred) Thank you!
I'm not seeing the problem.. hehe.. I mean the floats are not disappearing!
but there are known issues with IE/windows and disappearing text and borders (peekaboo bug).
try specifying the table cell width @ 100% and set table cellpadding and cellspacing to zero, to make sure that the 100% is available
You say it's only happening when the table is generated via JS.. could it be because of a rendering delay? (I know nothing!) as in the CSS is trying to calculate but it doesn't quite know what to be a percentage of because it renders before the table..
one cure for "peekaboo" is to set a dimension on the containing element, which is what a width on the table cell should do, but without a 'working' example this is just guessing..
Suzy
Before I start, let me just clear up something. I have a page with a calendar, and some JavaScript which imports another JS file, dynamically generated, to replace the calendar; that way I can go through several months without having to reload the page.
The elements which disappear are the arrows and month name at the top; I couldn't use cells because the text spacing was uneven, so I contained each in a span element and floated them left. They work fine when I first load the page in JS, but when I change the month, IE5 makes the floats disappear.
I'm not seeing the problem.. hehe.. I mean the floats are not disappearing!
but there are known issues with IE/windows and disappearing text and borders (peekaboo bug).
Yeah... of course, IE is buggy handling anything with CSS, really. :P
Specifically, I realize this has to do with just plain text inside the width-defined float. I tried adding a span element to contain the text, and either by applying a width or height to it will make the text always appear (even though it's not legal on inline elements, but I digress). This actually works in my favor because each arrow or month name that's enabled is inside an anchor element, which I can define as block and cast a width on. Still, it looks a little sloppy when the disabled arrows/month names are missing, so it's worth searching for an answer...
try specifying the table cell width @ 100% and set table cellpadding and cellspacing to zero, to make sure that the 100% is available
Defining a width on the table did not work, unfortunately, but I hadn't thought to remove the padding/spacing. Might come in handy with a future issue...
You say it's only happening when the table is generated via JS.. could it be because of a rendering delay? (I know nothing!) as in the CSS is trying to calculate but it doesn't quite know what to be a percentage of because it renders before the table..
However, I did figure out a somewhat managable solution. Defining a percentage-based padding for the floats causes them to not disappear in IE5. But the padding, for some reason, makes the element several times as wide when you first load the page, though when you select a different month, resorts back to normal behavior. Even worse, IE5.5 makes it about twenty times as wide when you first load the page. IE6, thank goodness, gets it right...
So, though my global style has been hack-free until now, and I shudder to do such a thing, I applied a double dose of hacks:
/* <hack> \*/* html #lastYearArrow,
* html #lastMonthArrow,
* html #monthName,
* html #nextMonthArrow,
* html #nextYearArrow {
padding: 0 0.1%;
padding/**/: 0;
}
/* </hack> */
IE5 reads the faulty padding, IE5.5 doesn't, and the style sheet is imported so IE4 doesn't get anything. I'm not fond of the solution, but until I find a non-hackish fix for the incredible-width of the floats in IE5.5, I'm outta luck.
