I’d like to say Thank You to everyone who’s commented, downloaded and enjoyed Manifest. I really do appreciate the support.

That being said, I’m considering making some updates to Manifest based on how I’ve seen it being used in the wild. While I have my own list, I’d like to hear from you as to what you would like to see (if anything) in an updated version.

I wanted the process of making my first publicly available theme to be fun. I also wanted to use it as opportunity to use some of the CSS3 (and even CSS2) features that I don’t normally get to use. IE6 was a roadblock to both objectives. There’s been some chatter recently in the web design community about when and how IE6 support should be phased out. Some elect for a more progressive approach, while others elect to drop support entirely. For Manifest, I went with the latter.

If you view a Manifest based site in IE6, you’ll be presented with an unstyled (but completely functional) site with polite message at the top informing your users that they should upgrade their browsers to something more current.

Here’s some common questions/comments when it comes IE6 support.

• A large percentage of my users still use IE6 : Manifest may not be the theme for you. The alternative would be to encourage your users to upgrade to a more modern and secure browser.
• Many people work in offices that still run IE6 : Encourage your employer to upgrade to a more secure browser. Using a browser that’s less susceptible to viruses and hacking is good for your employer. Oh, and get back to work! What are you doing browsing the internets on office time?!
• Will support for IE6 be added to Manifest? : No.

It’s not that IE6 support can’t be added. A good percentage of my day is spent getting complex web applications and ecommerce sites working in IE6. But it’s not a very fulfilling portion of my day. I’m not going to go into detail as to why IE6 is the bane of every web developer, there are plenty of other resources available that go into that. Here are a few:

• Bring Down IE6. A newer initiative.
• DearIE6. Send your regards.
• Browse Happy. Switcher stories.
• To Hell With Bad Browsers. Written eight years ago and still relevant.

Today marks the release of Pronto - All is Golden. Pronto is the side project of Wilco keyboardist Mikael Jorgensen. Don’t let the Wilco association give you preconceived notions of the sound of the record. It’s less of the Wilco alt-country sound and more of a grass roots Americana sound. I’ve heard some refer to it as AM Radio rock. I’m not exactly sure what that is (I hear the older folks used to listen to it), but what I do know is that it sounds damn good and you should pick yourself up a copy at the the Contraphonic web store, iTunes or Amazon.

In addition to the new album, today also marks the launch of the new Pronto site. I assisted in the XHTML/CSS development and Wordpress implementation. Visit today to find out the latest band news, tour dates and sign up for their newsletter. They’re also on that hip new thing called Twitter, so you can follow them there as well.

Full Disclosure: The exceptional drummer of Pronto, Mr. Greg O’Keeffe, is not only a friend of mine, but also my employer. While that may insinuate some bias in my opinion of the album, it doesn’t. I’d just as openly let him know that it sucks if I thought it did… right after my yearly review.

Pros

• Speed. Safari 4 is significantly faster than any currently shipping browser and it’s very noticeable upon use. I say shipping because the current nightly builds of Firefox appear to be on par in terms of performance.
• Coverflow History. I’ve usually found browser history to pretty much useless unless you know the exact time your were looking at a particular site. Being able to scan through your history as a series screenshots is awesome and makes using the browser history much more usable.
• Topsites. While not particularly ground breaking (this was introduced with Google Chrome, topsites is a nice to have feature that will display your most visited sites as your homepage and notify you if they’ve changed.
• New Web Developer Tools. I haven’t had the time to fully try out the new web developer tools, but from my quick poking around I can tell they’re vastly improved over the previous version. Time will tell if they give Firebug any kind of run for it’s money.
• New Web Technology Support. I’m itching to try out some of the new standards (non-standards) support for upcoming web technologies they’ve added.

Cons

• Tabs at the top. Placing the tabs at the top of the window is an interesting choice, but I feel it’s done purely because google did it with Chrome. I don’t have so much an issue with the tabs at the top as much as I do with how they’re implemented. Now that the tabs are at the top in the window title bar, you can’t just drag anywhere on the tab to move it around. Doing that moves the window. You need to click and drag on the designated area on the far right of the tab to move it. You can also no longer double click anywhere on the tab bar to create a new tab, you need to click the designated button to do so. And visually having the tabs break up the title bar is a little jarring, especially when you have other windows layered on top of them as in the following image.

Overall I’m pretty impressed with the new Safari beta. And it is just that, a beta. I have noticed a couple bugs here and there, but no show stoppers. Like I said, my only real complaint is the new tabs, I’m just not digging them. Luckily there are a couple of hidden Safari preferences, one of which that allows you to revert back to the old tab style.

On twitter (my new favorite gauge of public opinion) I’ve noticed that the general reaction to the tabs has either been met with absolute dislike or the “going to try and get used to it” attitude. Along with a smattering of people who really like it. It will be interesting to see how Apple responds in further betas or in the final product.

I’m not going to go too much into detail with what’s changed visually or technically. I’ll just invite you to check it out and let me know what you think. I’m still cleaning up a bit of the code and will probably be making tweaks over the coming weeks, but overall I’m pretty happy with this one.

One thing I will mention though is that I’ve completely dropped support for IE6. So the 36 of you out there who are still using it to visit this site will get a completely unstyled experience. It’s time to upgrade people.

Below are screenshots showing the email with images off (default) and images on.

Lets take an email I recently received as an example.

At first sight this resembles a typical spam email. Usually a spam email that made it through my spam filter that’s trying to sell me something I don’t need, which I would just mark as spam. But looking closer I see it’s from MINI. I signed up to receive information from this company, but due to it’s poor presentation I would have just assumed it was spam and trashed it. But why does it look like this?

The common default for most email applications is to not display images that are contained within an email. This is an anti-spam measure. Spam often tracks the success and validity of the email it was sent to through the display of the images contained within the message. In order to view an HTML based email properly the user either needs to change this default behavior in the applications preferences (not a good idea) or by clicking the “display images” button that your email program will usually display. But as you can see from the following screenshot, even pressing the “display images” link only gets us half the way there. We’re still missing the text that’s displayed above and below the images because it’s black text on a black background. And the text that’s missing is important. It explains how to unsubscribe from receiving these newsletters should I want to. And ironically it also explains that if I’m having trouble viewing the email, I can click a link to view it properly. So much for that.

So how can this be fixed? I’ve gave myself one hour to create a fixed version of this email from scratch to demonstrate.

First I removed the black background that spanned the entire email. This allowed the header and footer text of the message to be shown, since it wasn’t visible due to the text color also being black. Instead of changing the text color to white, I choose to remove the black background so there is more focus on the message and less on the header and footer of the email.

Next I added alt text to all the images being used in the email. When using images that contain text within the image, use the alt tag. The image alt tag will display the text contained within the image if the image is not displayed. Also keep in mind that the default display color of the text will be black, so if you choose to you use a black background such as in this email, you’ll need to apply a color style to the image to change the color of the alt text so it’s readable.

With those small changes, the email that the recipient would receive would look like the following.

But this can be improved even further.

I’m a big advocate of using pure HTML text and not using images to layout your text. Images are often used to ensure a particular font is used. But I believe the cost in lost usability and accessibility is too high for ensuring your particular font is displayed (the one exception being logo branding). So I’ve created a second version of the email removing the image based fonts for pure HTML based text.

As you can see in the following screenshot, even without the images being displayed the visual style being sought by the company still comes through.

When we choose to display images, here is our final email.

As I mentioned previously, these changes took less than an hour. But they moved the visual presentation and accessibility of the email miles ahead of it’s previous incarnation.

Mr. Sykes has recruited me to help out with the UI and design of the site. So look for updates to usernamecheck.com in the coming weeks (or days).

There’s one aspect of table based layouts that has eluded the non-table based layouts. The magic of the table cell. Or more specifically, the magic of multiple table cells working in unison. If the width of one table cell expands, all the others in the column follow along. This is especially useful when it comes to laying out forms. When laying out a form with tables, one cell is defined as the form label and the adjacent cell is the actual form element. This is repeated down the table columns for additional form elements. Instead of having to explicitly define a width for the label cell, the form label widths can be defined by width of the cell with the longest text label. This helps keep the form elements and form labels properly aligned without having to define an explicit width for each individual form label.

When it comes to non-table based layouts, each element is independent of the other. If the text size in one form label is longer than the others, the other labels don’t care. They stay right where they are with their own defined width. To get the form labels and elements properly aligned, you need to explicitly define the width of all your labels. Which can be a totally acceptable solution if you know what the content of every form will be and how long the average form label will be. But when it comes to dynamic systems that may have a single form layout framework used for all forms throughout the system, you may never know what text is thrown into the form labels or how large the form may be. Leaving you’re explicitly defined form structure in a highly dynamic system to become inconsistent at times.

Two forms with explicitly defined widths with varying length text labels

So why go with the non-table based solution? Flexibility. The flexibility you have with your form layouts far outweigh this one issue. Want you’re labels to the left of your form element instead of the top? Or maybe on the right instead of the left? It’s a matter of just changing the CSS declarations related to the label. To do that with a table based structure, you need to restructure the table. And within dynamic systems that may have that form distributed through several files, you could be in for a lot of hurt in updating that table.

Which brings us back to the special magic of the table cell. For a long time it’s been defined in the CSS 2.1 specification that the “display” property could not only define the layout of an element as block or inline, you could also define it as table, table-row, table-cell and various other table properties. These table based display properties allow you to define other elements, such as divs, to take on the structural properties of these table elements. But support for these property values has been spotty or non-existent in most of the major browsers. But this will be changing with the upcoming crop of new browsers.

In trying to come up with optimal form layout markup for one of our clients at the Hive, I wanted to find a solution for the form label issue described above. The following is some sample markup of a simple form.

 <div class="myForm">
    <div class="row">
      <label for="text1">Label</label>
      <input type="text" name="text1" />
    </div>
    <div class="row">
      <label for="text3">Here's a super long label</label>
      <input type="text" name="text3" />
    </div>
    <div class="row">
      <label for="text2">Another label</label>
      <input type="text" name="text2" />
    </div>
  </div>

The goal is for all the labels to be align flush right against the form elements, have both the form elements and labels aligned vertically, and have the overall form aligned to the left of the containing element. But I don’t want to assign a width to the label because due to the dynamic nature of the form, I won’t know what the length of the label text will be or how many elements may makeup the form on a given page. For example, if I define the label width as 200px and there’s only two form elements with the labels of First and Last, the form won’t be aligned flush left of the containing element due to the large label width and short text strings within it.

This is where the table based display properties come in handy. I’m able to layout my form using semantic markup, but I’m then able to define that semantic markup to use some of the layout qualities of a table. I’ve essentially defined a sudo table by declaring these table based values in the display properties of various CSS element declarations.

.myForm{
  display: table;
}
.row{
  display: table-row;
}
label{
  display: table-cell;
  text-align: right;
  padding: 0 5px 10px 0;
}

This works in Safari 3.1, Opera 9, Firefox 3 (RC 1) and the IE8 beta. The IE8 beta is a little flaky, but it’s an early beta and there’s still more work to do on the CSS front for IE. Firefox 2 support is partial and IE6/7 support is non-existent. So use of this technique will depend on which browsers you choose to support.

Is this a solution to be used every time you create a form? No, of course not. This may even be an edge case for most people as their forms may be pretty straight forward. But there often times I find myself with the need to have the actual text of the label define width of the form labels. As with all design decisions, it really depends on the context within which your using your form and the problem you’re trying to solve.

You can view example of this technique here