Why I use multiple browsers

With Internet Explorer 9.0 on the way, I've been thinking about web browsers. Turns out that I use as many as ten different browsers at work (on Windows), another five browsers at home (on a Mac), and at least two browsers on the road (on an iPhone). Why in the world would I want to use that many different browsers?

Well, platform issues aside, the obvious answer is that I’m a web developer. And, as such, I need to create websites that are compatible with multiple versions of the major browsers. Here are the browsers I have used to do at least some compatibility testing here at Symetra:

  • Microsoft Internet Explorer 8.0, 7.0, and 6.0
  • Mozilla Firefox 3.5 and 2.0
  • Google Chrome 4.1
  • Apple Safari 4.0

But, beyond browser compatibility testing, I also use several different browsers on a daily or near-daily basis. Here’s why:

  • Internet Explorer 8.0 is my default browser. I use it for:
    • Active development, because it is the newest production version of the browser that accounts for the vast majority of our web traffic, both internally and externally. IE has to work!
    • Accessing internal websites, such as SharePoint and the Employee Intranet, because IE does a fantastic job of making security transparent to me. Plus, I can easily extend the search bar in IE to include internal SharePoint sites, like devZone.
    • Accessing external, Symetra-specific websites, such as the ADP Portal and the Learning Site, because IE is our internal standard, and these sites are required to work well with it.
  • I use Mozilla Firefox 3.5 for:
    • Accessing Rally, because Rally renders so much faster/better in Firefox than in any other browser – especially IE.
  • I use the preview browsers in Visual Studio and Windows Live Writer for:
    • Testing code changes before or blog formatting before firing up a web server or posting to my blog to make sure things look mostly correct. (Though, the Visual Studio browser, in particular, is notoriously incompatible with all major browsers, including IE. So, I end up having to test things in the real browsers anyway.)
  • I use the Newsgator FeedDemon 3.1 browser for:
    • Viewing articles linked to one of the RSS feeds I follow, because it is too convenient not to. (Though, technically, FeedDemon uses IE under the hood.)
  • I use Google Chrome 4.1 for virtually everything else, including:
    • Browsing the Internet, especially when I’m starting with a Google search, which accounts for most of my time on the Internet, because Chrome offers one of the fastest rendering engines on the planet, a convenient, combined address/search bar, and a fantastic, tabbed-browsing experience. (Though, I do like the way IE 8.0 will close the current tab, rather than closing the entire browser window when I accidentally click on the wrong X.)

Overall, I’d say I spend the most time in IE and Chrome: IE because I have to, Chrome because I like to.

What browsers do you use? And, why? Which is your default? Which is your favorite? Which browser do you wish would just go away?

Moving past and to the semantic web

In his recent conversation, a coworker mentioned if you’re still using the <table> tag to layout your web pages, “you need to move out of the 90’s.” Of course, I agree. And, I frequently use <div> tags instead of <table> tags.

But, a little digging on the web has shown me I’ve probably been overusing <div> tags. Instead, the recommendations I’m seeing (links at the bottom of this post) are to limit <div> tags to the main layout of your page – things like headers, content, side-bars, and footers. Then, use traditional HTML markup for the content inside each area of your layout.

One such example I ran across used the <fieldset> and <ol> tags to render a form. It looked like this:

<form>
  <fieldset>
    <legend>Please enter your credentials:</legend>
    <ol>
      <li>
        <label for="username">User Name:</label>
        <span class="input"><input type="text" id="username"/></span>
      </li>
      <li>
        <label for="password">Password:</label>
        <span class="input"><input type="text" id="password"/></span>
      </li>
      <li>
        <span class="submit"><input type="button" id="login" value="Login"/></span>
      </li>
    </ol>
  </fieldset>
</form>

Without any CSS, it rendered like this:

image

Of course, that’s not the nicest looking form. But, it does provide some distinct advantages – especially to users who depend on accessibility tools to “view” the web. By enclosing the elements of the form in an ordered list (<ol>), for example, the user can hear how many elements there are in the form.

And, by enclosing all of the fields in a <fieldset>, we give the user additional context that gets repeated with each <label> in the form. This would be particularly useful for a shopping cart, where the Address fields might be repeated in multiple contexts, such as shipping address and billing address. Just enclose each group of fields in a separate <fieldset> and give them an appropriate <legend>.

To get the form to look less like a list and more like a traditionally (<table>) formatted form, I used this CSS:

<style type="text/css">
    fieldset {
        width: 260px;
        border: solid 1px black;
        }
    ol {
        list-style: none;
        margin: 0px 0px 0px -60px ;
        }
    li {
        display: table-row;
        }
    li label {
        width: 100px;
        float: left;
        text-align: right;
        padding: 5px;
        }
    li .input {
        width: 140px;
        float: right;
        text-align: left;
        padding: 5px;
        }
</style>

After which, it rendered like this:

image

Or, after another five minutes, I created this CSS, to render the <label> tags above the <input> tags:

<style type="text/css">
    fieldset {
        width: 200px;
        border: solid 1px black;
        }
    ol {
        list-style: none;
        margin: 0px 0px 0px -30px ;
        }
    li {
        display: table-row;
        }
    li label {
        width: 100px;
        padding: 5px;
        }
    li .input {
        width: 140px;
        float: left;
        text-align: left;
        padding: 5px;
        }
</style>

This rendered the form like this:

image

So, in the end, I learned something today. I hope you do to!

Here are the links I promised:

Enjoy!

Take my advice: Use a single field to represent complex numbers!

When creating data entry applications, it is often tempting to represent complex numbers – such as Social Security numbers and telephone numbers – as multiple text boxes, like this:

image

The thought is that this simplifies data entry by allowing the end-user to focus on the numbers, not the formatting. Sounds good. But, I’m here to tell you that I have been down this road. It is paved with good intentions. But, you do not want to end up where it will take you.

For brevity, let’s just cut to my preferred solution:

  1. Use a single text box to represent the complex number
  2. Use a RequiredFieldValidator to ensure that users don’t skip the field (if necessary)
    • With multiple fields, you’d have to write your own custom validator control.
  3. Use a RegularExpressionValidator to ensure that the data is in an acceptable format
    • You could split the regular expression into three shorter regular expressions, I suppose. But, why would you want to edit the working regex you grabbed off the Intertubes? That would require you to understand the thing!

The advantages of this approach are:

  1. Users can enter raw numbers or formatted text (which helps when the user is trying to copy/paste)
  2. Users can copy/paste in one shot
  3. Users don’t have to tab between extra fields
  4. Users can use Backspace and arrow keys to fix typos (without tabbing/clicking around)
  5. Programmers don’t have to write code to parse/concatenate the fields
  6. Programmers don’t have to write custom validator code

Everybody wins! And, just to prove how simple it is, here’s the code for Social Security Numbers and North American telephone numbers:

Social Security Numbers

<asp:Label ID="SSNLabel" runat="server" Text="SSN:"/>
<asp:TextBox ID="SSNTextBox" runat="server"/>
<asp:RequiredFieldValidator runat="server" Display="Dynamic"
  ID="SSNRequiredFieldValidator" 
  ControlToValidate="SSNTextBox" 
  ErrorMessage="SSN is a required field."/>
<asp:RegularExpressionValidator runat="server" Display="Dynamic"
  ID="SSNRegularExpressionValidator" 
  ControlToValidate="SSNTextBox" 
  ErrorMessage="Please enter a valid SSN." 
  ValidationExpression="^\d{3}[- ]?\d{2}[- ]?\d{4}$"/>

Note: The regular expression above allows formatted SSNs as well as raw numbers. Spaces and hyphens are considered acceptable delimiters, but are not required.

North American Telephone Numbers

<asp:Label ID="PhoneNumberLabel" runat="server" Text="Phone Number:"/>
<asp:TextBox ID="PhoneNumberTextBox" runat="server"/>
<asp:RequiredFieldValidator runat="server" Display="Dynamic"
  ID="PhoneNumberRequiredFieldValidator" 
  ControlToValidate="PhoneNumberTextBox" 
  ErrorMessage="Phone number is a required field."/>
<asp:RegularExpressionValidator runat="server" Display="Dynamic"
  ID="PhoneNumberRegularExpressionValidator" 
  ControlToValidate="PhoneNumberTextBox" 
  ErrorMessage="Please enter a valid phone number, including area code." 
  ValidationExpression="^(?:\([2-9]\d{2}\)\ ?|[2-9]\d{2}[- ]?)[2-9]\d{2}[- ]?\d{4}$"/>

Note: The North American Numbering Plan (NANP) specifies that the area code and prefix must not begin with 0 or 1, for obvious reasons. The regular expression above validates this. It also handles complex formats as well as raw numbers. Spaces and hyphens are considered acceptable delimiters, but are not required. The area code may or may not be wrapped in parentheses, and may or may not include a space (but not a hyphen) after the trailing parenthesis.