Currently, web development is undergoing some major transitions: the HTML5 spec is being developed and CSS3 is being implemented. The browser wars have returned, although this time around, it’s a battle to win developers’ hearts by implementing the newest standards.

Now is the time for developers to re-evaluate their past practices; moving on from the old and embracing the new. I kept that ethos in mind when upgrading the Soupgiant WordPress base theme recently. Among other things we were porting it to HTML5.

I really tried to adopt the commonly advocated view that it’s okay to require website visitors have JavaScript enabled. It was going very well, right up to the final hurdle when I couldn’t resist checking the site I was working on without JavaScript.

Everything looked fine in Chrome, Firefox, and Opera. It was, predictably, Internet Explorer that threw a spanner in the works. For an artist’s impression, visit the demo in IE8 (screenshot via WebPageTest):

HTML5 as seen in IE8

Without Remy Sharp’s HTML5 enabling script the site I was working on was unusable, if anything, it looked worse than the demo provided.

I couldn’t, in good faith, sell a website to a client that some visitors would find unstyled, half styled or difficult to follow in places. I didn’t want to throw out the baby with the bathwater, the additional meaning provided by HTML5 elements is just too great. <header>, <section>, <nav>, <article>, etc all provide meaning to a document that it’s difficult to justify going without.

It’s with the additional meaning in mind that I decided to go with – what I’ve dubbed – HTML4.5. HTML5 provides the meaning while using traditional HTML 4 tags as hooks for styling. It introduces a bit of tag soup, as instead of <article id="content"> ... </article> the code becomes <div id="content"><article> ... </article></div>.

The improvement to site I was working on was immediate, as you can see by visiting the html4.5 demo in IE8 (screenshot via WebPageTest):

HTML4.5 as seen in IE8

I don’t care about tag soup

If given the choice between an unusable website for some visitors or a little tag bloat, I’ll take the bloat any day of the week. In the demo the bloat adds an extra 14 bytes. On the home page for the site I was working on, it’s 40 bytes. I save plenty more than 40 bytes by minimising my JavaScript and CSS (a single key combo with the YUI Compressor TextMate bundle), so I’m not too concerned about the side effects.

A technically beautiful site is the ideal but if a portion of your visitors can’t use it, then the beauty isn’t even skin deep. As Drew McLellan said recently on 24 ways, progressive enhancement is “also known as doing our jobs properly.”

Frequently, I see HTML forms coded as lists. I’ve seen this in code by some publications and people I highly respect, such as on A List Apart. The code may be:

<form action="example.php" method="post">
<ol>
  <li>
    <label for="itemOne">Item One</label>
    <input id="itemOne" name="itemOne" />
  </li>
  <li>
    <label for="itemTwo">Item Two</label>
    <input id="itemTwo" name="itemTwo" />
  </li>
</ol>
</form>

The method remains much the same if using unordered or definition lists. The argument for using this method is that forms are a list of fields. A variation is to use a table, arguing that forms are a table of labels and inputs.

I don’t believe either argument is correct, I believe forms are a series of:

• fieldsets;
• legends;
• labels;
• buttons;
• inputs, selects, options, etc.

All semantic meaning for forms should come from the appropriate HTML tags. If you want to use other elements as hooks for styling, they should be semantically meaningless spans and divs.

I consider the arguments cited above as justifications for making styling easier. Without block elements, forms can be difficult to style. Rather than wrapping each input pair with a list item, I wrap them with divs.

<form action="example.php" method="post">
<div>
  <label for="itemOne">Item One</label>
  <input id="itemOne" name="itemOne" />
</div>
</form>

Wrapping each input pair in a div is just as lazy as wrapping each input pair in a list item. However, as divs are meaningless, it doesn’t require bending of semantics to justify my actions.

There is a valid argument for an element to define an input pair but I think such an element is redundant. We already have a method for defining the pairing of labels with their inputs. The “for” attribute within the label pairs with the “id” attribute of the associated input.

If you wrap your forms in a list or a table, look carefully at what you are doing. Ask yourself; is what you are doing semantically valid or are you lazily trying to make styling easier? As context for your consideration, ask yourself if a whole page of text is really just a list of paragraphs.

Back in the days before browser tabs, a whole new window would open either above or below the window you were currently working on. It was terrible and unstoppable. People kept up this practice because they thought it was a good way to get a user to keep their website open. It was seen as an audience retention device.

The browser belongs to the user. The website belongs to the creator. The website should not perform any actions on the browser that the user cannot control. That should almost always be the situation.

By keeping things uniform we can set expectations with the user that links will always open in the same window and if they want to open the link in another window they have options like middle-clicking or context-menus.

Of course there are exceptions to this. Banks often open up a separate window for logging in and doing actual banking because they can ensure an extra level of security if, when logging out, they can close the whole window.

The best way to keep a user coming back to your site is to have compelling content. They can always come back by pressing the back button if they meant to open in a new window but forgot.

Another problem with opening links in new windows comes with reporting. Reporting and analytics is another post for another time but many people still use the metrics of a visiting time. The time a user stays connected to a site become a dirty statistic if they actually navigate away from the page but it stays open in a seperate browser window. The website owner doesn’t really have an indication of how useful/entertaining/compelling their site is, all they know is they could fool some script into thinking that people were still there even when they weren’t.

These are just some thoughts. Many theories abound in any workplace so I’m sure yours has some too. Feel free to let me know in the comments.

UPDATED: This post was inspired by a discussion, in turn inspired by an article in Smashing Magazine.