IE6 Image Size Causes Float Wrap - Livekick Homepage
Jun0
The Livekick homepage suffers from a common problem in IE6. Floats are getting wrapped incorrectly due to IE not clipping the image to its containers width. IE6 renders the Aerosmith thumbnail as its entire width, even though that causes the containing div, which has width=129px, to expand to fit it. The code looks like this
<div id=’divHotToursTiles’>
<div class=’tile’>SNIP</div>
<div class=’tile’ style=’width: 129px’>
<div>
<a><img></img></a>
</div>
<div class=’tile’>SNIP</div>
<div class=’tile’>SNIP</div>
</div>
The fix for this is relatively simple. Just add “overflow: hidden;” to the tile class to prevent IE6 from forcing the image’s parent div to expand.
Missing Close Tags Cause Undefined Layout Behavior - Techcrunch Advertising
Jun0
It seems that even our friends over at TechCrunch have some serious layout problems, even in IE7. In this situation, the ad sidebar is wrapped way down below where they should be in IE7 (but are in the correct location in IE6). Techcrunch gets 5.5 million visitors a month, and while a lot of their traffic is Firefox and Safari, at least some of those visitors are using IE7. I’d even go farther and hypothesize that among customers who run ads on TechCrunch, IE is a higher percentage.
So, if you were an advertiser considering placing an ad at TechCrunch using IE7 and saw the buggy miserable ad placement on the page, you might think twice about the value of buying that ad. And, all those visitors using IE7 will probably not even see the ads unless they happen to scroll down past the trackbacks.
The fix in this case is simple. The <div> tags arent close properly in <div id=’col1′> and this leads to undefined behavior across browsers, especially when dealing with floats. Close the divs properly and the problem goes away. There are a few other bugs on TechCrunch you can check out, of similar magnitude.
This is the kind of bug that can directly impact revenue, so it’s a good idea to protect yourself by testing your site in Browsera.
Line Wrap Difference Between IE and Firefox - Building43 Blog
Jun0
An interesting difference was detected on the Building 43 Blog between IE and Firefox. I spent some time trying to figure out which of the two was the “correct” rendering based on their CSS. The relevant code looks like this:
<td>
<div class=’js-singleCommentMenu’ style=’float: left;’>[More button]</div>
<div class=’js-singleCommentKarma’ style=’float: left;>
<span>Like this comment?</span>
<span style=’display: none;’>Score: 1 by 1 vote</span>
</div>
</td>
In javascript, the score span is changed to “display: inline” so that it appears. What could be happening is that in Firefox, the script runs before the layout is complete, and firefox tries to float the div with both spans visible, forcing it to the next line. In IE, the script doesnt change the display until after the first span is placed to the right of the More button because it fits, and then the Score text is added. Any other theories on this bug?
Floats Don’t Shrink To Fit in Firefox 2
Jun0
Most web developers are no longer supporting Firefox 2, since its market share has all but eroded away, but just in case someone has this problem in a different browser, I thought I’d mention it. The site wizehive.com uses a very basic float style for their header and back links, however, in Firefox 2, the back link wraps to the next line. Why? After doing some digging, it turns out this is because of a change between the CSS 2 -> CSS 2.1 standards. CSS 2 required an explicit width, while CSS 2.1 automatically shrinks the container to fit it’s contents. So, if you experience this in FF2, or any other browser, set an explicit width on that element to put it back in the right spot.
Layout Testing for Dynamic Content
Jun0
A few days ago, a test against the home page for cookpad.com revealed a float drop error in Firefox 3, in their main promotion of a user recipe. Since then, the recipe featured has changed, and thus the bug does not occur any longer.
But, this demonstrates an important point: if your site features user-generated content, you must be very strict with your presentation layout, because users may contribute content in shapes and sizes you never considered.
We believe this is one of Browsera’s core strengths, its ability to quickly validate hundreds of web pages and automatically detect problems. Performing a test like this manually against a large number of web pages takes too long and is too error prone.
Cannot Upgrade From IE6 to IE8 - Internet Explorer
Jun0
The #fail of the day goes to Microsoft for the inability to upgrade from IE6 to IE8 using the download link on their IE Home page. You would think that Microsoft would test this scenario heavily, but I hit this problem from two different machines running IE6. Clicking on the download link put me on a blank page with a script error, and no amount of refreshing or clearing the cache would fix it.
The only way I could eventually make the script error go away was to clear my cache, then hit back, then hit reload, and finally attempt to download. I’m curious to see what happens next!
Stylesheet Not Loading in IE - Opera KB Support
Jun0
In an apparent oversight, Opera’s Knowledge Base page doesn’t load the stylesheets at all in all versions of Internet Explorer. Browsera automatically detected this bug by noticing the layout was very different. On this page, Opera is using
<link rel=”stylesheet” href=”/css/screen.css” type=”text/css” media=”projection,screen and (min-device-width:950px)” />
and “min-device-width:950px” isn’t supported in IE. We know you want people to switch to Opera, but I think this is just going too far.
DIV drop in IE6 due to expanding DIV - Apple’s “Why Mac” page
Jun1
In running a test against the brand everyone loves or hates, Browsera found a couple of IE6 layout bugs on the Apple “Why You’ll Love Mac?” page. This one is caused by attempting to put two floating div’s into a parent div that is not wide enough. Here is the relevant code:
<div class=”grid2col” style=”width: 100%”> <!– this width was 844px for me –>
<div class=”column first” style=”width: 565px; float: left”>
</div>
<div class=”column last” style=”width: 200px; float: right”>
<img id=”model” height=”382″ width=”288″ alt=”Macbook” src=”http://images.apple.com/getamac/whymac/images /pleasure_model20090106.jpg”/>
</div>
</div>
Even though the parent div width of 844px seems plenty wide enough to fit the two floats with the specified widths (565px + 200px = 765px), Internet Explorer 6 will automatically expand the div containing the image to fit it. Once you add these widths together (565px + 288px = 853px) the elements cannot fit on the same line, and the image gets dropped down. If you set
overflow: hidden
on the “column last”, IE6 will no longer expand the div and the elements will fit together correctly. Note that this will cause the image to be slightly clipped on the right hand side. Alternatively, the containing div can be expanded to fit the image, though this will slightly change the layout of the page.
IE6 100% Width Float Drop - Bing Community
Jun0
On Bing’s Community pages, there are avatar icons next to the users post activity. But, Browsera detected a float drop issue in IE6 where the user’s avatar is not properly aligned with their activity.
Here is the relevant HTML with CSS styles inline
<div class=”list-rockers” style=”width: 100%”>
<div class=”thumb” style=”width: 50px”> [USER AVATAR]</div>
<div class=”user-info” style=”width: 163px”>[USER ACTIVITY]</div>
</div>
I think the problem is that the 100% width is causing IE to calculate this width before it has completed its layout, and thus, the actual width of the containing div is 212px. Setting this width to an explicit value of 220px in IE6 makes the container wide enough to hold both floats and margins.
IE7 Ignores Submit Button Padding - Twitter Homepage
Jun0
In testing Twitter, Browsera detected a problem in IE7 with the “Sign In” button dropping below the line with the “Remember Me” checkbox. Surprisingly, it is on the correct line in IE6. Here is the Twitter input wrap problem as detected by Browsera.
The problem seems to be that Internet Explorer 7 is using its own padding instead of that in the stylesheet. (In this case, it’s using too much padding.) This turns out to be really easy fix, credit to Mr Kirkland for figuring this out. Applying the style
overflow: visible;
to the “Sign In” submit input button forces IE7 to honor the padding as specified in the stylesheet. With that, the homepage will be consistent across browsers. Horray!