Proper Internet Explorer Browser Testing
by Mike Badgley on March 25, 2011
The recent release of Internet Explorer 9 has brought a lot of excitement to the Web community, yours truly included. The standards and performance levels of the browser can rival (and in some cases surpass) any other product offering that is currently out there. IE9 is in short an awesome browser and already I’ve been impressed with the way it performs – particularly with JavaScript-based animations where it blows the rest of the competition out of the water. And yes, that it includes the faster-than-a-speeding-potato Chrome.
While this is all well and good, it means that we now have four versions of IE (v6-9) to browser test on, which means there needs to be a viable solution that allows us to test properly across all four versions.
One of my pet peeves with all browsers is the inability to have multiple versions installed at any given time – this goes for IE, Firefox, etc. Obviously this can make browser testing a time consuming and laborious task, and as such can lead to lazy development (i.e. “It works on IE8, so I’m sure it’ll be fine on IE9 or IE7”).
As you may be well aware, a number of tools exist that aid in browser testing, such as Spoon.net and IETester. While these tools are useful, there are a number of shortcomings that make them not ideal candidates.
The best, most consistent solution, is to use Virtual Machines. Virtual machines allow you to run multiple Windows environments from within your existing Windows desktop, meaning you can have a virtual machine installed for each particular IE browser that is being tested.
Microsoft offers these images as free downloads on their Web site, and although they expire after a set number of months, a new version is always made available.
The image files below provide virtual machines with IE6, IE7 and IE7 installed:
XPSP3-IE6.EXE– Windows XP Server Pack 3 with Internet Explorer 6 installed.XPSP3-IE7.EXE– Windows XP Server Pack 3 with Internet Explorer 7 installed.XPSP3-IE8.EXE– Windows XP Server Pack 3 with Internet Explorer 8 installed.
Below, are some simple installation and configuration steps to aid you through the process of setting up a virtual machine on your computer. I will take you through the process of installing XPSP3-IE6.EXE (Windows XP Service Pack 3 with Internet Explorer Installed). I am assuming you are on a Windows 7 box, but the steps would be similar for XP.
Step 1: Open and extract the VMC image
Double-click to open the EXE file. A security warning dialog box will be displayed. Click the Run button.
Upon clicking the Run button, the license terms and agreements dialog box is displayed. Click the Yes button to agree to the terms defined.
Finally, you will be prompted to define a installation location for the files that are contained with the EXE file. Choose a folder location on your computer (i.e. C:\Users\mike.badgley\Documents\Windows Virtual PC\Virtual Machines\IE6). Note: If you wish to install the files to a new folder, you will have to create this manually from within Windows Explorer as there is not option from within the dialog box to do this.
Step 2: VMC files extract
Due to the size of the VMC file, it will take a few minutes to extract all of the files to your destination folder.
Once the extraction procedure is complete the dialog box closes and the first part of the installation is complete.
Step 3: Create a virtual machine within the Windows Virtual PC application
Now that the files are extracted, it is time to create a reference to them so that you can have a working version of the virtual machine from within your computer. This is all done through the Windows Virtual PC application, and it can be found by searching for ‘Windows Virtual PC’ from the Start menu, as shown below.
The application loads what looks like a regular Windows Explorer window that lists all the VMC’s that you have installed up to this point. Near the top of the window will be a toolbar that contains the functionality for creating and maintaining VMCs. You will need to click on the Create virtual machine menu option, as shown in the screenshot below:
Step 4: Virtual machine wizard
This step goes over the process of adding in a reference to your VMC file. Upon clicking the Create virtual machine menu option, you will be greeted with the following dialog box:
Provide a name value, which can be anything you want, and then use the Browse button to select the folder that the VMC files were installed to in steps one and two. Click the Next button to continue once you have filled out both fields.
Next, you will be prompted for the amount of memory (RAM) to allocate to this VMC. The default is 512 MB which is generally sufficient. In addition, there is a checkbox for Networking. This box needs to be checked so that your virtual machine will have full network access. Click the Next button to continue.
Finally, point the application to your newly-installed VMC. To do this, select the Use an existing virtual hard disk option and browse to the location of the files that were extracted in steps one and two. Once the location has been defined, click the Create button and a new VMC reference will appear within Windows Virtual PC.
Step Five: Launching the VMC
Launching the newly-installed VMC is as easy as double-clicking on the reference to it within the Windows Virtual PC application. This will open a new window and you’ll see the machine loading within the application window.
The first time the VMC is run you may be prompted for hardware installations. This can be cancelled/ignored as it will not affect the use of Internet Explorer.
This basically completes the installation process of a virtual machine, but to enhance the experience, I recommend that you install and enable Integration Features, which can be found within the Tools menu. This will allow you to share drives and also increases the performance level of the VMC to the point where it acts like any other application (by default it’s fairly sluggish). In addition, installing the Integration Features will enable the ability to share local and network drives.
Understanding a browser’s default CSS
by Mike Badgley on January 19, 2011
On the heels of my recent post on the potential pitfalls of using CSS resets, this post continues in that same vein.
The question of why we even need to use a CSS reset is a good place to start. All browsers – at least the major players – come with their own default internal style sheet. This is why when you view a plain ‘unstyled’ HTML file within a browser, the text is bolded in certain areas, headers and paragraphs have margins, and lists have either numeric or symbolic bullets.
This doesn’t happen by accident. When each browser manufacturer deploys their product, a default ‘internal’ style sheet (in some cases more than one) is included that defines basic styling for all the available HTML elements it supports. This is why, for example, that an <h1> tag has a large font size, is bolded and has margin space above and beneath it. The vendor specifically defined these styles within the internal stylesheet for the browser.
So, when you apply a reset within your main CSS file, it’s actually overriding some (or all) of the settings that the browser manufacturer had predefined. The danger of this is that it’s easy to forget what the browser is pre-defining. We think everything is ok – that all of the browser’s are on the same playing field because we’ve applied the latest-and-greatest CSS reset to them.
And most of the time that assumption would be correct, but other times you will come across issues in a particular browser and have no idea why they are happening.
Let’s look at a common problem I’ve seen posted numerous times – I’m sure you have come across this (and it’s solution) as well:
In all version of Internet Explorer, there is a vertical scrollbar that appears on the <textarea> element. The solution is rather simple, but it’s funny how some of the more simpler solutions can cause so much frustration in finding! Adding the following CSS does the trick:
textarea {
overflow: auto;
}
My point here is not necessarily the solution to this problem, but the method in which it is found. Instead of wasting time testing different options, the more ideal method would be to see what default styling the browser is applying to it.
Thanks to a most helpful resource on iecss.com, you will find a listing of all HTML elements and the default styling that IE apples to each. In the case of the <textarea> element, the following is applied by default:
textarea {
background-color: #FFF;
border-style: inset;
border-width: 2px;
font-family: monospace;
font-size: 10pt;
overflow-x: hidden;
overflow-y: scroll;
padding: 1px;
white-space: pre;
zoom: 1;
}
That overflow-y statement jumps right out at you. Now it is competely obvious why the scrollbar was appearing! All that is required now is to override the statement and the issue is solved.
textarea {
overflow-y: auto;
}
In my opinion, a lot of CSS issues and “bugs” that we have in various browsers have a much better possibility of being solved once we know what we’re “fighting” against. Having these helpful charts from iecss.com will only help in that effort.
Blindly using CSS resets
by Mike Badgley on January 17, 2011
CSS resets are great and make life a whole lot easier as it allows front-end developers to start on a ‘clean slate’ across all browsers with all the available HTML elements. However, that does not mean that they have a place in every HTML template build. Blindly adding a reset to your style sheet at the commencement of the production process is not always the smartest or efficient way of doing things.
In the past, I have found this out the hard way, and a lot of the time it was not fully understanding (or knowing) all the details of the environment for which the templates were intended for. Not considering the environment for which they were intended was digging an early ‘hole of failure’ for myself. Looking back at my experiences I now understand the importance of both know of and about the environment (typically a CMS), as it plays such a vital role in knowing whether or not a CSS reset should be used.
The difference? Taking the time before template production begins to get a clear understanding of the environment for which the work is intended for. The alternative to this of just going ahead and blindly inserting a trusty reset will potentially create havoc that will require a considerable amount of time debugging and fixing.
This does not mean that CSS resets should be thrown out the window. There are many great CMS products out there (i.e. WordPress, ExpressionEngine, Sitefinity) that will be unaffected by whatever CSS you throw at it, and thus work absolutely fine with a reset, as their administrative screens are (for the most part) separate from the public portion of the site. But other CMS’s, including SharePoint, are affected and as a result can be crippled (display-wise) by a reset.
This doesn’t mean you need to be an expert on all the CMSs that are out there. True, experience and familiarity with a product does help, but overall just a little basic knowledge on a particular product can go a long way.
Let’s look at an example of recent work I did for a SharePoint environment. I’m by no means a SharePoint expert – far from it – but a little bit of research confirmed for me that a CSS reset was completely out of the question, for a couple of reasons:
- The back-end appears to be tied to the front-end in the sense that I have the ability to completely change the look-and-feel of the administrator controls with the CSS that it intended for front-end (public) consumption.
- Core style sheet included with each SharePoint site and are not intended to be disabled/removed. These provide base styling for all public and administrative-only controls.
Instead of using a CSS reset and causing countless display issues, I kept things ‘as-is’ and made sure that all custom content pieces I was styling were reset – taking it from a global to a local level. In other words, instead of resetting all of the HTML elements on a global level (<h1>, <h2>, <p>, etc.), I reset on an item-by-item level:
.custom-widget p {
font: normal 13px/normal Arial, Helvetica, sans-serif;
margin: 0;
padding: 0;
}
Working on remote pages using wget
by Mike Badgley on January 5, 2011
Updating and fixing layout issues on sites that are hidden from the public can be a tricky process – especially when you’re unable to replicate the problem with your (normally out-of-date) version of the site. Solutions such as saving the page via the browser (File -> Save As) never seems to work well, which means your generally looking at fixing the problem(s) using screenshots and best guesses. Either that, or having the client send you every file that the page references, which would not only be cruel, but very time consuming.
What I needed was a tool that would download a single page in it’s entirety. It had to be simple to use, and more importantly, quick!
Enter wget. This handy little utility is exactly what I was looking for. It’s quick and easy to use and does the job right by downloading the entire page – as if you copied it directly form the server.
Usage
Although it lacks a GUI, this is still a simple tool to use:
- Open up a command prompt window and change to the directory where the application is stored.
- Run “wget -k -p [URL]” where URL is the page you wish to retrieve.
- wget will proceed to download both the page and it’s assets (-p) and store them in a folder in the same location as the application itself, while at the same time updating all the links to point to the internal/downloaded versions (-k).
Now whenever a client has a display issue on their non-public site, I just have them run these three steps and send me the folder of files it creates, thus giving me a local version of the page that is identical to their’s.
Potential Issue(s)
After testing this out on a few sites, the only issue I’ve come across is with background imagery referenced from a style sheet not being downloaded. I’m not sure why this is the case, as it seems to work for some CSS files but not others. That being said, it is by no means a show-stopper - I can live with missing imagery as 99% of the time the issue is layout and not image related.
How to achieve vertical text with CSS
by Mike Badgley on October 18, 2010
Jeffrey Way, of Nettuts+ had an interesting problem this morning that he posed to the Twitter community which was finding the easiest way to create vertical text with CSS.
A number of suggestions were put forth – some using JavaScript and others using space hackery. I wasn’t to crazy about any of the solutions I saw, as detailed on Jeffrey’s blog post. The one he ended up going with is not a ‘real world’ solution, as it involved putting a space between each character of the word. That screams ‘hacky’ to me…
My solution, although admittedly not tested fully, gets rid of all the JavaScript and spacing hacks and is closed based to a solution that is outlined on Jeffrey’s blog post on the topic (method 4). The key property in this solution is a CSS3 property that works in every browser – word-wrap, and is as follows:
.vertical {
font-size: 12px;
position: relative;
word-wrap: break-word;
width: .1em;
}
That’s as easy as it’s going to get – a nice and clean solution that will work with any font size and not be dependent on JavaScript or forcing the content author to insert spaces after each letter.