The problem occurs when resizing the browser window; cutting off background images and potentially making text illegible. Worse still, the bug also seems to affect mobile browsers with a zoom function, such as opera mobile.

After some dabbling I found a solution, which I shall explain in this post.

The sites that are most affected are those that use ‘content strips’ as I like to call them; that is a full width background with content centered down the middle. I tend to code a ‘strip’ like this:

1
2
3
4
5

<div id="header">
     <div class="inner">
          ...Content goes here...
     </div>
</div>

In this example #header is a block level element making it full width with a background image (usually tiled). .inner is my content div; it has a width set and auto-margins to make it centered on the page. The diagram below shows the structure of the layout on blue anvil:

If you make the window smaller and then use the horizontal scrollbar in the browser window you will notice the background gets ‘cut-off’. This seems to affect all modern browsers. From what I can gather, it seems the divs with the background image resize with the browser window, meaning any fixed width content will spill out and be shown on the page background; this demo page has the bug for you to see.

The problem itself is not major for most people, since (I assume) resizing the window and scrolling is quite rare. However I have noticed it happening before on the Nintendo Wii browser, and some mobile browsers (opera mobile for instance) where the problem can be more severe; its more of a problem on these devices because It can prevent the user from being able to read content. For example, when opera mobile cut the background off of the footer on Blue Anvil the white text was not legible, as this screenshot shows (taken from my HTC Diamond using Opera Mobile before I fixed the layout):

I experimented with all sorts of attempted fixes; wrappers, 100% widths, clearing…nothing seemed to work at first. In the end I found a workable solution which was actually quite simple: min-width. Using min-width on the div with the background prevented the browser from shrinking it too much hence eliminating the problem.

This fix is quite simple and does not seem to affect anything else on the page or cause any issues of its own, so it is something which can be added easily to any layout suffering from this problem.

Enjoy.

This article teaches the basics of using conditional comments, and shows some examples of their uses.

A conditional comment is a method of talking directly to a version of internet explorer above version 5, allowing you to pass
IE specific rules without affecting other browsers such as firefox.

By utilizing conditional comments you can effectively reduce the usage of css hacks to make your web pages compatible with
Internet explorer.

Common uses

With conditional comments you can:

• Target IE specifically
• Make IE 5+ ignore a block of code

A great usage, for example, would be using conditional comments with CSS style sheets so you can have certain IE specific css rules that you want other browsers to ignore.

The code

You may be aware that, in html, the syntax of a normal comment is:

1

<!--comment goes here-->

Comments can be placed anywhere in the document.

Now, a conditional comment looks like this:

1

<![if ]><![endif]>

Conditional comments can also be placed anywhere in your HTML document.

Types of conditional comment

downlevel-hidden

A downlevel-hidden comment is a comment that is visible only to the IE version you are targeting.

Example:

1
2
3

<!--[if IE]>
     <em>your code</em>
<![endif]-->

The above code will only be seen by IE versions 5 and up.

Other, older, versions of IE, and also other browsers, will not see the code enclosed by the tags, and will therefore ignore anything you put inside, hence the name, downlevel-hidden.

The other browsers just see the <– and –&rt parts, so it looks like a regular comment to them.

Just to show you, for reference, if you used the code,

1
2
3

<!--[if !IE]>
     <em>your code</em>
<![endif]-->

NO browser would see the code. This is because the rule is !IE, which means NOT IE. Therefore IE 5+ wont see the code, and since it is downlevel hidden, no other browsers will either.

Visibility conclusion:

Firefox/non-ie browsers – code hidden

Targeted IE – code visible

downlevel-revealed

A downlevel-revealed comment is a comment that is visible to the IE version you are targetting, and also non-IE browsers and old versions of IE. It is useful when you wish to make code invisible to a version of internet explorer, but you want non-IE browsers to still see it.

Example:

1
2
3

<![if !IE]>
     <em>your code</em>
<![endif]>

The above example would be visible to all browsers except IE versions 5+.

Validity

You may notice that the downlevel-revealed code provided by Microsoft does not validate correctly, the correct code is outlined on this page, or is shown below:

1
2
3

<!--[if !IE]>-->
     <em>your code</em>
<!--<![endif]-->

The difference between this downlevel-revealed code and the downlevel-hidden code is that the comment is closed after each line, so non-IE browsers will not ignore it.

Visibility conclusion:

Firefox/non-ie browsers – code visible

Targeted IE – code visible

Targeting specific IE versions and extra commands

The [if ] portion of the conditional comment code has extra functionality so you can target certain versions of IE, or exclude versions. These are outlined below.

Targeting an IE version

To target a specific version of IE you just add the version number in the if statement, for example, to target IE 6 only you could use:

1
2
3

<!--[if IE 6]>
     <em>your code</em>
<![endif]-->

You must leave a space between ‘IE’ and the version number.

Targeting multiple IE versions

If, for example, you wanted to target versions of IE older than IE 6, rather than writing individual statements for each version you could use the ‘less than’ comparison :

1
2
3

<!--[if lt IE 6]>
     <em>your code for versions less than IE 6, but not including IE 6</em>
<![endif]-->

If you wanted to target versions older than, and equal to IE6 you would use:

1
2
3

<!--[if lte IE 6]>
     <em>your code</em>
<![endif]-->

The commands for comparing versions are as follows:

lt – less than

lte – less than or equal too

gt – greater than

gte – greater than or equal too

Excluding an IE version/versions

To exclude a version you can make use of the ! (NOT) operator, for example, to target all IE versions except IE 6 you could use:

1
2
3

<!--[if !IE 6]>
     <em>your code</em>
<![endif]-->

This would mean if not ie 6.

You could also mix the not operator with multiple IE versions, for example to target all versions of IE except IE 6 and above you could use the code:

1
2
3

<!--[if gte !IE 6]>
     <em>your code</em>
<![endif]-->

This would mean if not greater than or equal to ie 6.

Version Vectors

Version vectors allow you to target minor versions of IE, for example you could target IE 5.5 instead of IE 5 as a whole. This is particularly useful, as some bugs are fixed in higher versions. The format of a version vector is x.xxxx, but you do not have to make the decimal 4 digits long, e.g 5.0 is valid, as is 5.0000, however the 5.0000 targets the 0000 build of the browser specifically.

Usage examples

Some of the best example of usage would be using conditional comments in conjunction with CSS. Say for instance you wanted to fix a box model error in IE 5, rather than use hacks you could just make a separate style sheet for IE 5 with modified width values of an element which wasn’t rendering correctly. You would then add the following to the header of the html page:

1
2
3
4
5

<!--[if IE 5]>
  <style type="text/css">
    @import url(ie5.css);
  </style>
<![endif]-->

And hey presto, IE 5 will use the fixed styling, no box model hacks needed. Of course with this method you would have to ensure the conditional comment was after the style sheet include, if not the style would be overwritten by the default style sheet. Of course another method that would not be affected by the order would be to just add the styling directly to the conditional comment :

1
2
3
4
5

<!--[if IE 5]>
  <style type="text/css">
    #element{width:200px;}
  </style>
<![endif]-->

Since styles in the document have a higher priority than those in the style sheets, it would take priority.

So there you have it, a simple guide to using conditional comments in your web pages to avoid hacks, I hope this was useful and don’t forget to post a comment. Thanks for reading!

Further reading

Microsofts conditional comments page

The main thing on my agenda was the blue anvil redesign I’ve been working on. It all went pretty smoothly, excluding the few set-backs I encountered (see my last blog entry), but all in all it went well and the website was looking fairly nice…in firefox.

Yes, I left the cross browser stuff until last, it would only take an hour or two, right? How wrong was I. This was my day from hell and I have the coffee breath and bad temperament to prove it. With any luck the problems and solutions I used may be
helpful, and save others from a hellish day that I experienced.

Bug #1 – Negative margins

Negative margins have a variety of uses, I love them to bits. Great for overlapping content or escaping a div. This bug wasn’t bad at all, Id experienced it before, and it does make sense why it goes wrong really.

In my case I have a div with padding which my content was being put into. Above the content I wanted to have a strip for the date that was wider then the content itself.

Rather than fiddle with padding, or adding more divs, I went down the negative margin route.

The code

The strip was in a box with a padding of 32px.

1
2
3
4
5
6
7

.date_strip {
display:block;  
padding-left:32px;  
margin-left:-32px;  
margin-right:-32px; 
background-color:#000;
}

The problem

The code works as it should in firefox, but IE cuts off the edges of the strip.

The solution

Simply add the rule:

1

position:relative;

Later on in the day (just before I had the urge to put the laptop in the oven and watch it die) I found a second error, this one with Opera 9. Opera 9 would render the left negative margin fine, but cut off the right hand side. To fix this I just added padding to right, as I already did to the left.

1

padding-right:32px

Bug conclusion

Difficulty rating: 1/10 Annoyance factor: 1/10

Bug #2 – Form heights

If you look in the sidebar you will see the search form, I had some problems regarding the height of the input box and the height of the submit button.

The code

1
2
3
4
5
6

#searchbox input {
border:1px solid #73B531;  
background:#fff;  
display:inline;  
width:125px
}

1
2
3
4
5
6
7
8
9
10

#searchbox input.button {
text-align:center;  
padding:0;  
margin:0;  
background:#8C4;  
color:#fff;  
border:1px solid #692;  
width:75px !important;  
margin-left:4px
}

The problem

Firefox renders the button with more height than the input box. This was happening when my input button had a border.

I thought that simply adding one pixel of padding to the input box would solve the problem, and it did, but this made IE render the boxes at different heights. To solve this I needed to add
2 padding to the input box, which broke firefox.

The solution

Conditional comments were the key to solving this bug. By setting the padding to 1px in the css stylesheet (fixing firefox) i could add a conditional comment to make IE render the same box with 2px padding, solving the problem.

In the header of the document:

1
2
3
4
5
6

<!--[if IE]>
      <style>
      #searchbox input{padding:2px;}
      #searchbox input.button{padding:0;}
      </style>
<![endif]-->

(check back in a few weeks, I will be covering conditional comments in more detail in a future post).

Despite this there is still a problem, as the boxes are not equal height in opera, as of yet I have not been able to solve this as I cannot find a hack for opera that works well. If you know one, please leave a comment.

Bug conclusion

Difficulty rating: 3/10 Annoyance factor: 7/10

Bug #3 – accessible forms

I was quite disappointed when I found this bug, as I thought my forms were perfect. Well it seems IE has a nasty quirk concerning field set backgrounds.

In firefox and other standard compliant browsers, the field set background goes up to the border, as it should.

In internet explorer the field set background breaks out of the border to fill the legend (the label for the field set) too, making it very difficult to make the forms look the same between browsers.

The code

CSS:

1
2

#commonform fieldset {margin-top:16px;  background-color:#fff;  border:1px solid #8FA7C2;  padding:16px;}
#commonform legend {margin:0;  font-weight:bold;  border-bottom:1px solid #dbdbdb;  color:#7191B0;   font-size:1.2em;  background:#efefef url(images/bits2.png) repeat-x}

HTML

1
2

<fieldset>
<legend>Your Contact Details</legend>...etc

The solution

To fix the problem in IE, I found that the only way was to position the legend absolutely to the relatively positioned field set, essentially breaking it from the flow so the background wouldn’t fill the legends area. The code is quite fiddly to get right, and only works in IE, therefore conditional comments come in handy once again.

1
2
3
4
5
6

<!--[if IE]>
      <style>
      #commonform fieldset {margin:0;  margin-bottom:16px;  <strong>position:relative ;</strong>  background-color:#fff;  border:1px solid #8FA7C2;  padding:16px;}
      #commonform legend {<strong>position:absolute;</strong>  margin-top:-26px;  font-weight:bold;  border-bottom:1px solid #dbdbdb;  color:#7191B0;  font-size:1.2em;  background:#efefef url(images/bits2.png) repeat-x}
      </style>
<![endif]-->

Bug conclusion

Difficulty rating: 8/10 Annoyance factor: 8/10

Bug #4 – Safari wrap bug

This was a quick bug I found with my navbar. My navbar is essentially just an inline list with padding above and below. Its width is set with display:block;.

The problem

Safari would break the list, causing the last item to wrap, breaking the layout.

The solution

Simply adding white-space:nowrap; to the navigation container solved the issue.

Bug conclusion

Difficulty rating: 1/10 Annoyance factor: 1/10

Bug #5 – Internet explorer making content disappear a.k.a peek-a-boo bug

I’m not sure if this was the peek-a-boo bug for sure, but strangely it also happened in IE7, which is a bit of a downer considering they were supposed to fix it!

Anyway what happened is that sometimes when scrolling content would randomly vanish, also background images would disappear revealing the background colour of the page.

This bug probably took the longest to fix, simply because I hadn’t encountered it before.

The fix

I found a fix by searching, and it seemed rather odd to me, but somehow it worked. It was called the holly hack, and applied a height of 1% to the box with the problem in IE, causing the background to fill the box correctly. Hoorah.

1
2
3

/* \*/
* html  .block {height:1%};
/* */

Note that the rule after this hack can be ignored, so it is best to insert a dummy rule afterwards e.g. *{margin:0;}.

Bug conclusion

Difficulty rating: 6/10 Annoyance factor: 10/10

Bug #6 – Image/background image positioning bug

My banner image is actually two images, one background (the sunburst), and the logo. The logo is just inserted inside a div
with padding to make it taller. It also has a background image using the css:

1

background:#557799 url(images/burst.png) repeat left bottom;

In firefox the image lines up perfectly, however IE looks like the background image is not aligned to the bottom left perfectly, and is shifted slightly.

The fix

By adding a conditional comment to add negative margins to my logo, I can line the image up manually so it works in both browsers.

1
2
3
4
5

<!--[if IE]>
    <style>
      #header img{position:relative;margin-bottom:-4px;}
    </style>
<![endif]-->

Bug conclusion

Difficulty rating: 5/10 Annoyance factor: 7/10

Bug #7 – Doubled margins bug

If you are a coder there’s a 99% chance you have encountered this bug before.

For some reason IE doubles the margins of floated elements, this is do to a bug in the engine.

The fix

This ones easy, just add display:inline to the floated element!

Bug conclusion

Difficulty rating: 1/10 Annoyance factor: 2/10

Bug #8 – Box model

Like the above bug, this is probably the most common IE bugs encountered due to the fact IE 5 renders the box model differently to standards based browsers.

To put it simply, standards browsers render the width of a div with the width + the padding, whereas IE 5 renders the width of a div with the set width – the padding.

So for standards browsers, if you wanted a box 200px wide with a 10px padding left and right, you would set:

width: 180px; padding:10px;

But IE would show the box just as 180px wide, not 200px (width + padding).

The solution

There are many solutions to this common problem, such as conditional comments again. However I chose to use a simple box model hack to fix this problem. The code for the hack looks like this:

1
2
3
4
5

* html #box
{
  width: 200px;
  w\idth: 180px;
}

The * html makes this rule visible to only Internet Explorer. However this is not enough since the rules contained would be visible to all versions of IE, including IE 6 which doesn’t have the problem. This is where the backslash comes into play. The code with the backslash rule is not seen by IE 5, but is by IE 6, meaning we can set the value for old versions, then reset for IE6.

1
2
3
4
5

* html #box /*Rules for IE only*/
{
  width: 260px; /*rule for IE 5 and below*/
  w\idth: 228px; /*Rule for IE 6*/
}

Bug conclusion

Difficulty rating: 4/10 Annoyance factor: 8/10

Bug #9 – Inline list of items

This one drove me mad, I found this later on in testing IE 6, when I thought I was done.

It seemed that my list for post options (read more, comments, digg etc) would wrap partly around, leaving behind the background items and half the text.

The icons were done by adding a background image to the span of text, with a padding-left. This was to make the icon centred next to the text correctly.

To fix this I tried white-space:nowrap to the spans, this stopped the text from breaking up, but still left the icon behind. I think this was do to the padding staying where the box wrapped from, and not from its new position.

The fix? I ended up having to surround the spans with the background image icons, with a second span that had position:relative; so that the padding of the contained span would be relative to the new position. I called the outer span ‘wrapper’.

1
2
3

.wrapper{
  display: inline;  white-space:nowrap;  position:relative;
}

Bug conclusion

Difficulty rating: 7/10 Annoyance factor: 9/10

Complications of my fix

It seems that, whilst working in IE 6, this fix made my icons overlap the text in IE 5/5.5, so to rectify this I added a conditional comment that targets IE 5 only, to give the span with the image a large width, making it display without overlap. It doesent look the same, however it makes it useable so is a good solution.

The code below is what i used, note the ‘lte’ before the version of IE, this means ‘less than or equal to’.

1
2
3
4
5

<!--[if lte IE 5.5000]>
      <style>
        .moretext{padding-left:32px;width:200px;}
     </style>
<![endif]-->

Bug conclusion

Difficulty rating: 8/10 Annoyance factor: 10/10

And so you have it, if you took the time to read this you will understand why it was all so frustrating, but in the end it was worth it.

If you have any improved solutions to any of these bugs, or your own bugs and solutions, feel free to post them as a comment,
I’m always willing to learn from others!

If you spot any bugs feel free to tell me, just note it may make my head implode!