Moo if you know CSS

2011-03-18T11:14:00.002-04:00

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.

2010-08-26T09:57:00.000-04:00

Forcing Breaks In Long Words/URLs/Email

Problem:
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.

Solution:
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.

2010-02-08T16:52:00.003-05:00

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.

2010-02-04T16:14:00.003-05:00

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!

2010-01-29T19:31:00.012-05:00

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.

PROBLEM:
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.

SOLUTION:
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.

Happiness.

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.

2009-07-16T10:30:00.005-04:00

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.

Problem:
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.

Solution:
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.

2009-07-16T09:58:00.005-04:00

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.

Problem:
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.

Solution:
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.

2009-07-10T10:32:00.003-04:00

Solution for double margin bug in IE6

Here’s another one to cross off.

Problem:
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?

Solution:
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.

2009-06-25T14:35:00.015-04:00

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;
   }
 </style>
<![endif]-->

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.

2009-04-01T16:17:00.000-04:00

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.

2009-02-05T14:51:00.001-05:00

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.

Removing all of the comments directly between the floating containers.
Using the IE conditional to wrap the comments, as in:

2009-01-28T13:13:00.000-05:00

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 { -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=70)"; 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…

2009-01-22T19:09:00.000-05:00

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; }
 <![endif]-->

Happiness ensues.

2007-02-20T16:59:00.000-05:00

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.

2007-02-15T10:01:00.000-05:00

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:

Works in IE5-6, IE7, Safari, Mozilla/Firefox
Flyout sub-submenus
Drops over select menus in IE5-6
Includes hover margin of error (mouse forgiveness when moving from menu to sub-menu)
Simplest HTML = easiest maintenance

I’m looking at the combined ADxMenu with the WCH script from aplus.co.yu. Haven’t finished testing yet, so I’ll update this entry when it’s all working.

2006-10-31T17:07:00.000-05:00

CSS drop-down/fly-out menus and Flash

It boils down to this: divs that drop down or fly out (as in most menus) over a Flash object look wonky.

This is better summed up in another post I found. The reply there is simply that the problem lies with Safari’s Flash Player implementation so the ball is in Adobe’s court. Adobe is aware of the problem and either can’t or won’t fix it.

Happy Hallowe’en!

UPDATE: Fixing Flash for other browsers

To help get the Flash window to behave under a flyout menu, this parametre should be added to the <param> lines in the Flash HTML:

<param name="wmode" value="transparent">

And this should be added within the <embed> tag:

wmode="transparent"

Great. This helps Firefox, etc. But still does nothing for Safari.

After seraching a number of forums, I’m convinced this can’t be solved for Safari.

Our Solution

The solution we’re going with is to test for the Safari browser and replace the Flash content with a link that says, “View in a pop-up window.” There. No uglies for Safari users to gripe about.

2006-10-30T16:39:00.000-05:00

Form submit button pops into place after focusing in a field (IE 5-6)

I was having trouble with the double-margin bug in IE5-6 with this same form. I don’t know if my fix is what’s now causing this blip, but here goes.

These are the conditions:
+ This is a simple login form: username , password, and submit inputs
+ All the fields of my form are contained in a <fieldset>
+ Each text input is wrapped in a <label>; each label is floated inside the fieldset
+ The submit button is wrapped in a div with style
{ text-align: right; clear: both; padding-top: .5em; position: relative; }

This is what happens:
+ When the page loads in IE5-6, the submit button starts off overlapping the text input above it (in this case the password field)
+ When the user focuses on a text input, the submit button magically slides into place

My easy solution:
I fixed the javascript that selects the first text input field when the page loads. The submit button is seen to pop into place, but it does this rather quickly, and since many pages look glitchy before things slide into place, I think this is an okay quick fix.

However, I do plan to explore what is going on here. Could be that I’m missing a hasLayout trigger. Will report back when I fix it.

2006-10-26T16:24:00.002-04:00

IE’s whitespace between list elements, part 2

So you’re creating a drop-down menu using unordered lists within unordered lists, and you’re using display: block for the li elements, along with a background colour that changes on hover. Looks great in Mozilla, but in IE there’s a mysterious extra space below the list item. It’s not padding and it’s not margin, because both of these have been set to 0!important. But there it is still.

Problem: IE, inexplicably, doesn’t recognise the closing tags for lists (</ul>) and list items (</li>). So any space between your closing tag and the next opening tag is treated as a whitespace. You can close these up, but it makes looking at or editing the markup later a real pain. And even if you do that, if you nest another list inside a list item, the whitespace reappears in IE7 — again, despite closing the gaps and declaring margin: 0.

Solution: Just found this most excellent solution from another blogger: declare float: left; clear: left on the li and the gap closes up! Marvelous!

2006-09-26T16:01:00.000-04:00

Firefox (OS X) Tip-Of-The-Day: Hacking the tab focus on form elements

This is not CSS, but it does drive me batty when I’m creating forms.

Does this bother you, too? When you tab a form in Firefox (on a Mac) it skips the radio buttons, checkboxes, and select drop-down fields. Hate that!

I recently found the hack to fix this:

Type about:config in the URL bar.
In the Filter field, type tabfocus.
Double-click on the accessibility.tabfocus preference.
Change the value to 7.
Restart your browser and tab away.

If accessibility.tabfocus isn’t in the list (it wasn’t in mine):

Right-click on Firefox.app and select Show Package Contents
Open /Contents/MacOS/greprefs/all.js
Insert pref("accessibility.tabfocus", 7); (I put it where all the other accessibility prefs were declared)
Restart your browser and tab away.

~

BREAKING NEWS:
It turns out this tabbing thing is handicapped by default in Mac OS X. However, changing it is simple through System Preferences > Keyboard & Mouse > Keyboard Shortcuts. At the bottom of that window, it says:

Full keyboard access
In windows and dialogs, press Tab to move the keyboard focus between:

[ ] Text boxes and lists only
[ ] All controls

So there. Just check and you’re done. So my question is, why is it handicapped in the first place??

2006-09-25T10:17:00.000-04:00

Margin Inheritance Bug in IE 5/6

This is documented in a number of blogs, including Quirksmode, but I wanted to repeat it here as a memo to me.

Some people refer to this as the Margin Doubling Bug, but I think inheritance is what’s really happening so it depends whether you prefer to name by cause or by effect.

The Problem

Some form elements (esp inputs) inherit the margin of their parent container when you float them. Especially if one uses a fieldset container with margins set.
This also happens with some non-form elements in particular circumstances (I haven’t made an exhaustive study to determine precisely when this occurs, but if I run across examples, I’ll post them here).
Trying to set margin:0 on the inheriting element does nothing.

The Solutions
Try one of these solutions, in this order, until the problem goes away:

Set overflow: hidden on the child element
Set display: inline on the child element
Wrap the child element in a div and set the float, padding, margin on the div

In my struggles with a floated submit button inheriting a right margin, I had to use the last solution, which is the least preferred since it adds more markup than is really necessary. But even trying to use IE conditional CSS wouldn’t work.

2006-09-21T10:57:00.000-04:00

IE disregards </li> (list closing tags)

I’ve been making modified Suckerfish (and Son of Suckerfish) Drop-Down Menus with background colours and border separated. The trouble is IE ignores closing list tags, meaning the carriage return in the HTML gets rendered as a space between the list items (below the bottom border of my list element). This tiny gap makes me nuts. The only way to get rid of it is to close the gaps in the HTML between </li> and the next <li> or </ul>.

So instead of this easy-to-read markup:
<ul>
<li>item 1</li>
<li>item 2</li>
<li>item 3</li>
</ul>

… you need to make it:
<ul><li>item 1</li><li>item 2</li><li>item 3</li></ul>

This person has a JavaScript for removing the white space, but it didn’t work for me. I’ll have to crack open the JavaScript text to figure out why not.

2006-09-20T15:34:00.001-04:00

Negative margins/indents bug in IE 5/6

I read someone else’s post about this bug last week, but I ignored it because it had never come up for me. Well, guess what? It’s a new week.

So here it is: if you try to apply a negative margin (and others report it happens with negative indents as well) to an element whose parent hasLayout, the element’s outer bits get cropped by the parent’s borders.

Eg.

1. The parent grey box has width:300 and float: left declared.

2. This paragraph has a left and right margin of -10px. You should be able to see the red border extend outside the grey box and read all of the text.

3. I include this to point out the importance of retaining the order of these three paragraphs.

In IE, the parts of the red-bordered paragraph beyond the grey box are cropped off.

1. This time, the parent grey background div has no width or float applied to it.

2. This paragraph has a left and right margin of -10px. You should be able to see the red border extend outside the grey box and read all of the text.

3. I include this to point out the importance of retaining the order of these three paragraphs.

This time, IE renders the red-bordered paragraph entirely (or would, if the grandparent column didn’t have layout, which it does, meaning the right edge of the paragraph gets cropped).

Peter-Paul Koch at Quirksmode.com noted:

IE 7 crops the right margin of the first example, but not the left. IE Mac ignores the margin-right: -10px in the first example.

Solutions, AFAIK:

Remove the hasLayout trigger for the parent (width, height, float, plus others). Not much of a solution when the reason you needed the negative margin in the first place probably had something to do with the parent’s dimensions and positioning.
*UPDATE*: If you don’t mind adding another div layer, you can use a grandparent element (between the great-grandparent and parent) and declare padding to give enough room around the negative margined child. However, this won’t work when there is another (aunt) element floated beside the parent. I’m still looking into all the possible rearrangements…

If anyone knows of a work around that preserves the element order, please shoot.

******UPDATE (2009.06.24):
Solution is here.