How to Opt-Out of IE8 Standards Mode and Other Useful Internet Explorer Troubleshooting Information

As a web designer/developer, we should strive to make each visitors experience as pleasant as possible. So, whether you like it or not, if you've chosen the web designer/developer career, you have to work with Windows® Internet Explorer® (IE).

I use Microsoft's Virtual PC to test web site display and functionality on various versions of IE (6, 7 and 8 at the moment). Unfortunately, I was experiencing a display issue only in IE8. Now, I realize the number of people currently using IE8 is extremely small. Soon enough though, there will be tens of thousands of people using it right? I might as well try to correct it now rather than pull my hair out later.

Rather than go into the display issue itself, I found a very useful technique to opt-out of IE8 standards mode. Or, in regular terms, how to make IE8 display a web page as if it were IE7.

First, I should explain why I chose this route. For one thing, it quickly fixed the display issue. Is there a better reason?

All I had to do was include a simple meta tag to the page(s) where the problem was occurring.


<meta http-equiv="X-UA-Compatible" content="IE=7" />

Personally, I like to wrap IE specific tags with a bit of ColdFusion:


<cfif cgi.HTTP_USER_AGENT contains "msie">
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
</cfif>

The downside to using this technique is that you will not be able to use the latest rendering features available in IE8. Sniff, sniff (cue smallest violin in the world) … oh well.

According to information I found on the IE8 Readiness Toolkit, you can also address this on a per-site bases by adding a HTTP header:

X-UA-Compatible:IE=EmulateIE7

Alternatively, you could use a slightly different meta tag on a per-page basis while still accessing "all Internet Explorer 8 has to offer."


<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Word of caution here, using the "EmulateIE7" technique did not fix my display issue though. I ended up using the first technique with "IE=7" to "correct" the problem.

Here are some other helpful links relating to working with Internet Explorer, IE8 (Beta 1), etc.:

How to Dynamically Check a Radio Button (and Checkbox) in ColdFusion

Although this may seem to be a simple task, dynamically checking a radio button in ColdFusion is not always as easy as dynamically checking a checkbox in ColdFusion. It's definitely not difficult either. I just thought it might be worth a mention here.

Let's first look at how to dynamically check a checkbox in ColdFusion.

Checkboxes are cool. You see them everywhere in forms throughout the web. And, let's face it, they're extremely easy to use. When used in conjunction with XHTML labels, they're even easier to use for visitors. For example, if you have a label next to a checkbox input, you can wrap the label with a "label tag" which then makes the label itself "clickable." Simply match the label tag with the checkbox input tag name. Here's an example:


<cfform action="javascript:void();"
        method="post"
        name="form1"
        id="form1">


    <div class="formItem">
        <cfinput     type="checkbox"
                    name="ckAgree"
                    id="ckAgree"
                    value="1" />

        <label for="ckAgree">I agree</label>
    </div>

    <div class="formSubmit">
        <cfinput     type="submit"
                    name="submit"
                    label="Submit"
                    value="Submit"
                    validate="submitonce"
                    onkeyup="javascript:alert('Submitted!');"
                    onclick="javascript:alert('Submitted!');" />

    </div>

</cfform>

For me, the most common use of a checkbox input is in back-end admin areas to determine whether or not a particular record is active or not. This only requires me to have an "IsActive" field for the record in the database table with a boolean type (yes or no, true or false, 0 or 1). I usually set the default value to true so that when a record is added to the database, it automatically becomes "active" on the back-end. When a back-end user attempts to update the "active" record, they will (or should) see a "checked" checkbox with an "Is Active" label next to it. Once the back-end user no longer needs the record to be active, they simply un-check the "Is Active" checkbox and click submit.

Now that the item has been archived, when the back-end user attempts to update the record again, the "Is Active" checkbox shouldn't be "checked" now, should it? So, how do I dynamically check the checkbox?

Since I'm updating a database record, I'll need a query to get the current values of the records' fields. So we'll want to make sure the query contains the "IsActive" field. Assuming it does, just call the query and set the checked value to the query's "IsActive" value. Like so:


<!--- get details for the current record --->
<cfinvoke     component="extensions.components.myqueries"
            method="getQueryDetails"
            returnvariable="returnQueryDetails">

<cfif isDefined("URL.id") AND isNumeric(URL.id)>
        <cfinvokeargument name="id" value="#URL.id#" />
</cfif>
</cfinvoke>

<cfif returnQueryDetails.recordcount EQ 1>

    <cfform action="#CGI.script_name#?#CGI.query_string#"
            method="post"
            name="form1"
            id="form1">

    
        <div class="formItem">
            <!--- dynamically check the checkbox --->
            <cfinput     type="checkbox"
                        name="ckIsActive"
                        id="ckIsActive"
                        value="1"
                        checked="#returnQueryDetails.IsActive#" />

            <label for="ckIsActive">Is Active</label>
        </div>
    
        <div class="formSubmit">
            <cfinput     type="submit"
                        name="submit"
                        label="Submit"
                        value="Submit"
                        validate="submitonce"
                        onkeyup="javascript:alert('Submitted!');"
                        onclick="javascript:alert('Submitted!');" />

        </div>
    
    </cfform>

    <cfelse>
    <p>Sorry, the selected record is no longer available.</p>
</cfif>

In the update query, to capture the new value, I use something similar to the following:


<!--- IsActive --->
, IsActive=<cfif IsDefined("FORM.isActive") AND isBoolean(FORM.isActive)>
<cfqueryparam value="#FORM.isActive#" cfsqltype="cf_sql_bit" />
<cfelse><cfqueryparam value="0" cfsqltype="cf_sql_bit" /></cfif>

If you're not using a query, the following code might also be helpful in dynamically checking a checkbox:


<!--- scope var --->
<cfparam name="isActive" default="0" type="boolean" />

<!--- set the current value of the variable --->
<cfset isActive = 1 />

<cfinput     type="checkbox"
            name="IsActive"
            value="1"
            checked="#IsActive#" />

Another reason for showing the code above is because it's similar to how I'll be dynamically checking a radio button. The previous code snippet should be easy enough to follow. We're simply setting the value of the variable "isActive" to equal true. Then, the checkbox input's "checked" state is set to be dependent upon the "isActive" variable. I guess it's easier to read the code than it is to articulate the meaning, eh?

So, as you may already know, radio buttons are used when you want to offer one, and only one, option from a list of options. We keep the list of options tied together with the "name" attribute. The "name" attribute simply groups the options together, so that of all options sharing the same "name," only one is actually selected. There are two differentiating attributes, one of which is obviously the "value" which is needed for passing to the database, etc. The other differentiating attribute is the "id." I use the "id" attribute to tie to the label tag. For usability, you should also use the "label" tag which will also allow the user to simply click the option label to select the desired radio button.

Let's assume you have two queries to work with. One contains the list of possible options for the radio buttons. The other query pulls the existing values for the specified record. The idea here is that we'll output all possible options for the radio button, then check to see if our current record has selected the option being looped over. If so, then "check" it. If not, don't. Simple enough, eh? Let's take a look at the code I've come up:


<!--- get details for the current record --->
<cfinvoke     component="extensions.components.myqueries"
            method="getQueryDetails"
            returnvariable="returnQueryDetails">

<cfif isDefined("URL.id") AND isNumeric(URL.id)>
            <cfinvokeargument name="id" value="#URL.id#" />
</cfif>
</cfinvoke>

<!--- get options for radio buttons --->
<cfinvoke     component="extensions.components.myqueries"
            method="getRadioButtonOptions"
            returnvariable="returnRadioButtonOptions" />


<!--- scope var --->
<cfparam name="IsChecked" default="0" type="boolean" />

<cfif returnQueryDetails.recordcount EQ 1>

    <cfform action="#CGI.script_name#?#CGI.query_string#"
            method="post"
            name="form1"
            id="form1">


        <cfoutput query="returnRadioButtonOptions">

            <!---
                This should be self-explanatory, but just in case, this is where we
                set the current value of the isChecked variable based on whether or
                not the currently outputted query item matches the value of the
                currently selected record.
            --->

            <cfif returnRadioButtonOptions.OptionID EQ returnRadioButtonOptions.OptionID>
                <cfset isChecked = 1 />
                <cfelse>
                <cfset isChecked = 0 />
            </cfif>

            <div class="formItem">
                <cfinput     type="radio"
                            name="OptionID"
                            id="Choice#OptionID#"
                            value="#OptionID#"
                            required="yes"
                            message="Please select a radio button."
                            checked="#isChecked#" />

                <!--- usability: if user clicks the title, the option should also be selected --->
                <label for="Choice#OptionID#">#OptionTitle#</label>
            </div>

            <div class="formSubmit">
                <cfinput     type="submit"
                            name="submit"
                            label="Submit"
                            value="Submit"
                            validate="submitonce"
                            onkeyup="javascript:alert('Submitted!');"
                            onclick="javascript:alert('Submitted!');" />

            </div>

        </cfoutput>

    </cfform>
    
    <cfelse>
    <p>Sorry, the selected record is no longer available.</p>
</cfif>

That's pretty much it folks. If you have a different way to handle this, please feel free to share. Hope this helps!

To learn more about the CFInput tag, visit http://cfquickdocs.com/cf8/?getDoc=cfinput#cfinput

What Width or Size Should I Design the Web Site For?

It's a question that comes up time and time again: "What width or size should I design the web site for?" Unfortunately, the answer is always the same, "it depends."

It depends on what? Well, it depends primarily on two major considerations:

  1. Your target audience's screen resolutions
  2. The amount of space needed to display the information in a readable format

If you don't know the screen resolutions of your target audience, then take a look at W3Schools Browser Statistics and specifically the Browser Display Statistics page. There, you'll find some fairly good information based on their log-files. Of course, if you have access to your client's web stats, check there first.

Keep in mind that if you intend to use the entire display width, be sure to leave room for the scroll bars and such. For the most part, simply subtract 20 pixels from the width to determine your maximum design width. For example, if your intended audience is using 800x600, then your maximum width should be 780 pixels.

I'm all for web site usability and would rather not have to force a visitor to scroll to the right to see important information simply because their monitor's screen resolution was set lower than the width of my intended layout. However, if your target audience utilizes for example 1024x768, then by all means, feel free to use the extra real estate ... but only if you need to. This might make sense in a corporate environment where you are designing an intranet and you know for sure what dimensions the employees are/would be using.

People are also visiting the web with their cell phones, PDA's and other handheld web-enabled devices at an increasing rate. By using Cascading Style Sheets (CSS), you can create an entirely different display to accomodate these visitors. So keep this in mind when planning your design.

One thing I try to bring up to my design collegues, is to think about how you personally use your web browser(s). Do you expand it to the entire width and height of your available display? I don't. I usually have several windows open at the same time and rarely do I expand the application to my entire available display. Why do I bring this up? Well, if my display is 1024x768 and the web site is using a full 1004 (or more!) pixels, then I'm probably having to scroll right to see any content.

So, whilst I'm standing on this soap box, I'll try to throw in one last thought here. If you are designing a web site for the general public, I would recommend keeping the width within 780 pixels. Why? Because as of January 2008, according to W3Schools Browser Display Statistics, approximately 8% of visitors are using 800x600 displays. I know, you're saying, "but that means 92% are using 1024x768 or higher!" You would be correct. However, I believe 10% is a significant number. Would you be willing to simply ignore or turn away 10% of your paying customers?

© 2008, Stephen J. Withington, Jr.  |  BlogCFC was created by Raymond Camden – Version 5.9.003

Creative Commons License  |  This work is licensed under a Creative Commons Attribution 3.0 Unported License.