Friday, March 18, 2011

IE7 and the mixing of left and right floats

Now that I’ve completely cut out support for IE5 and IE6 from the template (no backup stylesheets—only a message that says “update already!”), I imagined my IE debugging would go much faster. But I still come across a head scratcher once in a while, even now, after years and years of this. Very strange that I’ve never seen this come up before…

The Issue:
I have a left floated element with a set width followed immediately by a right floated element whose width is allowed to vary. Because the width of the right element might not fit in the remaining space allowed by the left element, I’d normally put a clear: both on the right element.

This won’t work in IE7, as demonstrated here.

The Solution:
Unfloating the right element makes the width 100%, and all the containing bits align to the left, which is not what I want.

Instead, I unfloat the left element, apply a the clear: both to the right element and happiness ensues.

Thursday, August 26, 2010

Forcing Breaks In Long Words/URLs/Email

I have a table with two columns that will have email addresses in them. I tried to set the width and max-width of all the columns, but if the email addresses are excessively long, the column inevitably stretches, resizing all the columns, and worse, stretching the table out of its width/max-width.

I came across a comprehensive fix for forcing all browsers to break up long words, thereby maintaining box borders, and without overflow: hidden.

pre {
    white-space: pre;           /* CSS 2.0 */
    white-space: pre-wrap;      /* CSS 2.1 */
    white-space: pre-line;      /* CSS 3.0 */
    white-space: -pre-wrap;     /* Opera 4-6 */
    white-space: -o-pre-wrap;   /* Opera 7 */
    white-space: -moz-pre-wrap; /* Mozilla */
    white-space: -hp-pre-wrap;  /* HP Printers */
    word-wrap: break-word;      /* IE 5+ */ 

Of course, it doesn’t have to be set to a pre tag.

The only problem I’m having is with IE8 which is not breaking, except when I switch the browser to Compatibility View. From everything I’ve read, the last line should work in IE8, but I’ve had no joy so far.

If anyone knows what I’m missing, please enlighten.

Monday, February 08, 2010

IE7, The Script

I was having dinner with friends last week, and one of them, another HTML monkey, told me about a fantastic JavaScript you could conditionally attach to IE6 to make it behave like IE7 (and well, now IE8). After the previous week’s headaches with the absolutely positioned elements next to floating ones, I said if this script works as advertised, why the hell hasn’t anyone told me about it before now?

So I’ve been giving it a shot with my new BlueTrip framework installed, and, well, it’s not manna from heaven. In fact, all the main problems I have with IE6 aren’t fixed with the IE8.js or IE7.js. One of the subsidiary scripts (to recalculate the box model) made IE6 and IE7 crash. On top of not fixing the major problems in IE6, it also breaks what I’ve already fixed, and I don’t want to hack fix a hacked fix.

In all, I put the conditional for IE7 to use the IE8.js script — even though the effect is fairly minor and causes a redraw burp — but I left IE6 the way it is. Honestly, at this point, knowing the hacks already, and having to use a conditional stylesheet anyway (for Peekaboo bug, 3-pixel job, etc. that don’t get handled by the script), it’s just easier to do it manually. Makes sense now why I’ve never heard anyone else hawk this “solution.”

On second thought, considering the redraw burp, I may as well take it off for IE7, too.

I knew it sounded too good to be true.

What the script does fix:
  • Fixed positioning
  • Maximum and minimum width and height
  • Many selectors previously unsupported are now supported 
  • IE6 will support alpha transparency for png images both as background and foreground images – but see next
And my brief testing concluded that the max-/min-height support didn’t really work either. I’m not sure about the rest since I try not to use those.

Labels: ,

Thursday, February 04, 2010

Grids and CSS Frameworks

Last year, I finally decided it was time to start designing on a grid. Imagine that! Using a design grid for websites. In the old days of two- or three-column layouts, you didn’t really have to worry about that.

But today, it’s all about Web 2.0 (whatever that means to you), and static grids are so ’00s-y. To take advantage of everyone’s bigger LCD monitors, you have to explore different column layouts, often within the same page.

So, with the latest project, I’ve designed the site on a 16-column grid (using Nathan Smith’s 960 template).

The big trick, though, is to make the markup and CSS not a complete pain in the ass.

My strengths don’t exactly include planning or coding; I’m too fly-by-the-seat-of-the-pants to carefully think all the way through something really complex. So I’d started laying out the templates for the site with my gonzo more-or-less best practice styling (there are many opinions on what constitutes “best practice,” and I find compromise is usually required to get the job done — never mind that it already takes 10-20% more time to debug for IE6).

A couple weeks ago, I discovered the Blueprint CSS Framework, and from there, the BlueTrip Framework. Thank Zeus for clever style monkeys.

I’ve adapted their 24-column grid for my 16-column grid, and added a few other customised layout options. I’m still scratching my head over padded columns inside boxed divs, as well as equal-height column borders, but those are stories for another day.

Today, I just wanted to thank the Blueprint and BlueTrip folks. Cheers!

Labels: , , ,

Friday, January 29, 2010

Absolutely Positioned element disappears in IE6

This bug is not unlike the Duplicate Rendered Characters in IE 6 that I documented earlier, having to do with IE6 bugginess around floated elements near absolutely positioned elements.

I’ve got an absolutely positioned list item at the end of a bunch of floated list items.1 In between the first floated items and the absolutely positioned items, I have another block.

  • The blue blocks were floated into place.
  • The red blocks are nested inside blue_block_2.
  • Red blocks 1 to 4 are floated into place.
  • red_block_5 has to be positioned absolutely, otherwise it mucks up the elements in blue_block_3.

Everything looks good in Firefox, Safari, Opera, Chrome, IE7, and IE8.

But wait! That’s right. IE6 needs to suck up more precious minutes in my dwindling life supply; it hides red_block_5.

Using the IE Developer Toolbar, I can make the block reappear by typing…well, anything into the style attribute: zoom, display, etc.

But when I try any of these in the IE6 stylesheet, nothing changes.

Craig Buckler at SitePoint explains that IE6 hides absolutely positioned items if they’re coded right before or right after floated sibling elements. He suggested that adding an empty, static element (such as <div></div>) would make IE6 pop the missing element back in.

Sadly, this did not work for me. But thanks to one of his readers, Paul O’B, I found a solution that worked in my case. In the IE6 stylesheet, I added clear: both to the red_block_5 element. I also had to change the left positioning value, but that did the trick.


1. Many snarky commentators love to ask things like “why would you need to use absolute positioning anyway? Why not change the markup so the elements fall into place inside the appropriate containing element?

My response is that my page is marked up the way it is because in the absence of stylesheets and JavaScripts, the content still flows logically, and all the elements that should be grouped together are grouped together.

So why don’t you change the design to keep the elements together if they’re supposed to be together?

Because visually, there are other elements that are more important, and my red_block_5 element can be shunted in favour of other visual hierarchies. Basically, there’s another element at the bottom of blue_block_3 that logically belongs within blue_block_3 (vertically), but also flows naturally after red_block_4 (horizontally).

So my case may be very particular, but I don’t think so. Besides, I don’t think I should have to give up either markup logic or visual logic just to make IE6 happy. That’s asinine. IMHO, IE6 just needs to go away.

Labels: , , ,

Thursday, July 16, 2009

Floating div disappears when background-color added to parent div in IE7

Strangely, this happens with IE7 and not IE6.

Set Up:
Inside of the mother div is a floating div (with graphics and a Flash audio player—but the content is unimportant since I’ve tried it without the Flash). The child floating div has a border all the way around.

When I add a background-color to the mother div, the child below the top border disappears. It’s still “visible” to the cursor (hovers still work), but no visual.

Add position: relative on the child element. Happiness ensues.

From now on, any IE6 and IE7 visual glitches will be attacked with position: relative and zoom: 1. It seems that either one or the other works in 80% of cases.

Labels: , ,

Select tag z-index glitch in IE

I thought this was fixed for IE7, but not so.

Set Up:
We have a page with 3 tabbed divs; only one is displayed at a time, while the others are display: none. The default div that displays on load contains a select tag which changes the content in a table inside that div based on date. The second div displays a dynamically generated table in standard HTML. The third and last div contains a Flash movie.

In IE 6 & 7, when the second tab is clicked to hide the first div and display the second div, there is a mystery horizontal rule (at the same height as the top of the table in the first div). This line seems to be on the top layer, and causes anything below the line to be unclickable.

Quickie: remove the <select> tag and use something else (custom slider or create the select menu as a DHTML drop-down instead).

This sounds like it could be fixed with the jQuery iframe method, but we haven’t tried it yet.

But what I want to know is why the select still creates the bug when it’s containing element has display: none. Does display: none mean that all the included elements are still lurking underneath? This makes no sense since normally, display: none causes the page to change size.

Labels: , , ,

Friday, July 10, 2009

Solution for double margin bug in IE6

Here’s another one to cross off.

Float a child block and add a margin on the same side as the float (so, margin-left if float: left, margin-right if float: right), and IE5-6 doubles the margin value.

Insane, right?

For a long time, I simply halved the margin value in an IE conditional. Which is unacceptable when the margin value is odd.

But now, there’s a better solution. In the IE5-6 conditional:

.fix_doublemargin { display: inline; }

Happiness ensues!

Credit: P.I.E.

Labels: ,

Thursday, June 25, 2009

Solution for negative margins/indents bug in IE 6

Over two and a half years ago, I wrote about this bug for which I didn’t know a fix. This week, I’ve had the problem resurrect, and after more Googling, found the solution from another blogger. Here it is:

Give the child that is getting cut off, haslayout like so:

<!--[if lte IE 7]>
<style type="text/css">
#child {
zoom: 1;
position: relative;

In my situation, I’ve used just position: relative; to fix both IE 6 & 7 because using zoom: 1; wrecked the auto width of the child element. [Don’t know if this fixes IE 5.x, and don’t care.]

I’ve read from others that the reverse sometimes cures, too, so I suggest trying both, then trying one or the other to see which gets the result you need. Buffet-style IE hacks!

Woohoo! I can finally cross this one off.

Labels: , , ,

Wednesday, April 01, 2009

Background images in table rows: update

For a change, this isn’t about IE5-6 alone. In trying to put a table form together, using a background image in the table row would be the easiest solution for me. Sadly, this is not a supported function in:
  • Safari (including version 4 Beta)
  • OmniWeb (up to 5.9.1)
  • iCab (up to 4.1.1)
Which makes the form problematic.

Ah well. Back to the drawing board.

Labels: , ,

Thursday, February 05, 2009

Duplicate Rendered Characters in IE6

The Issue: I’ve got an absolutely positioned link inside a floated container. The link is being partially duplicated outside of and below the container.

According to P.I.E., the problem is that I have comments between all the floated siblings of the container, and IE has a problem figuring out what to do with comments between floats (WTF?!). This bug also pops up if there are hidden inputs and any item with display: none amongst the floating siblings, though I have yet to experience this delight for myself.

The Solution: I tried all of the suggestions on the P.I.E. site, but only two things worked for me.

  1. Removing all of the comments directly between the floating containers.
  2. Using the IE conditional to wrap the comments, as in:
<!--[if !IE]><!-- MY COMMENT --><!--[endif]-->

Labels: ,

Wednesday, January 28, 2009

Opacity in IE6

The Issue: First problem is that text set with opacity looks like crap. It’s to do with the anti-aliasing (yes, even with ClearType enabled).

Second problem is that even when you use

.opaque {
filter: alpha(opacity=70);

The opacity doesn’t kick in.

The Solution: For problem 2, add zoom: 1; to the IE-only rule above.

Happiness ensues.

As for IE6 anti-aliasing ugliness, I just wipe out the filter: filter: none;. So you don’t get opacity in IE6. Not the end of my world.

According to stats for the website, at least a quarter of the IE traffic is still using version 6. UPGRADE, PEOPLE! DO IT! DO IT NOW!

The bane of my existence…

Labels: , , ,

Thursday, January 22, 2009

Italics in IE6

The Issue: Italics force their container slightly wider in order to show the overflowing slanting edge of the letter when the container (such as an <em>) does not have a set width.

This happens to break my P.I.E. (Positioning Is Everything) layout.

Happily, this is a well-documented bug at P.I.E.

The Solution: Because I no longer care about IE5, let alone IE5.5, I use this:

<!--[if lte IE 6]>
em, .italics { overflow: hidden; zoom: 1; }

Happiness ensues.

Labels: , , ,

Tuesday, February 20, 2007

Vertical scroll bar hide-’n-seek in IE6

The Issue: Some visitors have called to complain that the scroll bar is missing on a page that requires them to click an “I Agree” button at the very bottom. This seems to be a sporadic problem because we’ve only fielded a couple of these calls, and my own testing machine doesn’t exhibit this problem.

Googling resulted in similar complaints from others — until I changed a few things in their stylesheet and fixed their problem. One person set top and left as well as position: relative on a containing div. Changing these to margin-top and margin-left and removing the position fixed his problem. The reason IE6 wasn’t displaying the scroll bar had to do with the positioned element overflowing the base container; that is, the positioned container was treated as a layer because of the top and left settings, so it was “outside” the content flow. Am I making sense? It makes sense in my head, but I’m not using the proper vocabulary.

Anyway, that isn’t what’s happening on my page because the containing elements are all stretching to match the length of the copy (which doesn’t happen with positioned layers). Which means that the scroll bar should be triggered. [I am using the One True Layout so I have a feeling this may be an issue with overflow: hidden on the containing row. I’ve set overflow: visible in the IE fix stylesheet, but I have no idea how to tell if it works or not.]

The other qualification is that not all IE6/Windows XP users are getting this bug.

The Predicament: How do you fix a problem that you can’t reproduce?

Also, we don’t know that this is the only page that is exhibiting the bug, only that it’s the most obvious, since if the visitor can’t click the button at the bottom, she can’t continue to the rest of the site. There haven’t been reports of the bug on other pages. Or perhaps because the visitor with the bug can’t get past this page, she can’t report further bugs on the rest of the site. Either way, I am not incredibly motivated to find a solution. I understand it’s a real problem, but unless I can see it in action, I can’t even begin to think where to start fixing it. I can’t mess with the stylesheet because I can’t tell if it’s making a difference or not.

Anyone ever had a problem like this, please help.

Labels: ,

Thursday, February 15, 2007

CSS drop-down/fly-out menus and IE select elements

IE5-6 renders select menus on the top-most layer, no matter how you set up the HTML or how you declare the z-index.

The last time this issue came up for me, I included a javascript that would make the select element disappear when the overlapping drop-downs were triggered. This worked fine because the select menu was the same width as the drop-down and so it was completely covered. Now with a different site, this is an impractical option, mainly because there’s no telling where the select menus will end up or how wide they’ll be.

I’m trying to meld a bunch of CSS drop-down/flyout solutions into one mass. Here are all the features I need:
  1. Works in IE5-6, IE7, Safari, Mozilla/Firefox
  2. Flyout sub-submenus
  3. Drops over select menus in IE5-6
  4. Includes hover margin of error (mouse forgiveness when moving from menu to sub-menu)
  5. Simplest HTML = easiest maintenance
I’m looking at the combined ADxMenu with the WCH script from Haven’t finished testing yet, so I’ll update this entry when it’s all working.

Labels: , , , , ,