Jim Barraud

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.

Back in the dark ages of web markup, the most reliable way to layout anything was by using a table. One of the best utilization’s of the table-based layout was laying out a form. We’ve come a long way in breaking away from laying out forms in tables. There are plenty of techniques for doing this that have already been discussed, so I’m not going to rehash that. Some would even argue that tables are still the most reliable to layout forms.

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

Shaun Inman has an interesting blog post proposing CSS parent selectors. Something a lot of people (including me) have been begging for. The proposal on the surface looks good and sound, but when you dig into the comments, apparently it’s a lot more complicated. Take particular note of the responses from Dave Hyatt, he’s the lead developer on Webkit. You find out why it’s not something that will be implemented, and surprisingly (at least to me), how CSS selectors in general can get expensive in terms of performance. Especially for large scale web apps.

I was always with the understanding that CSS selectors were the most optimal route for CSS definitions, since your getting very specific about the element you want to style and not adding a ton of IDs and classes to your HTML. Apparently when it comes to performance the opposite is true. While it seems this performance hit isn’t noticeable on smaller scale sites, it can become a performance bottleneck on larger scale web-apps. The problem is I don’t know what the degree of the performance hit is and how complicated your site needs to be for it to be noticeable. I’m also not clear on if this is a browser specific issue. Browsers that are referenced include Safari and Firefox, but does IE or Opera suffer from this as well?

If this issue gets any more prominence, I’m sure some performance tests strictly dealing with CSS will start to emerge. As of right now, it’s something take note and of and keep on eye on.

Update: One of my partners in crime at Media-Hive, Mr. Jon Sykes, has posted a 3 part series on testing the above issue. Testing CSS Performance, Testing CSS Performance pt.2, and More CSS Performance Testing.

HTML formated emails are considered the spawn of the devil by some. And by others it’s considered the next evolutionary step in email. Whichever side you sit on, both agree the HTML formated emails aren’t going anywhere and will only become more popular.

From a developers point of view, creating an HTML formatted email can be about as fun as root canal. Why? Because as opposed to browsers, which there are only 2-3 core browsers (calm down fringe browser people), there are 10-15 core email clients. The level HTML and CSS support varies greater then the level of support the browsers had in the dark days of the browser wars. To encourage browser makers to comply to the basic set of web standards support, the Web Standards Project was created. This was (and still is) a group that lobbied browser makers to support web standards. Proving that it was not only for the benefit for web developer, but also for end users and the browser makers themselves. They have been extremely successful their efforts.

The Email Standards Project aims to do the same for HTML/CSS standards support within email clients. They’ve just launched their official site which contains info on why this matters, what you can do, and a list of popular email clients and their current level of standards support. They’ve even created an Email Standards Acid Test for testing the level of support of each email client.

I encourage anyone who has to create HTML formated emails or anyone who relies on them as promotional tools for their business to visit the Email Standards Project and show your support.

Our latest project at Media-Hive has just launched; the website for Diane von Furstenberg. Our role, more specifically for the Hive, was the eStore portion of the website. The eStore is built upon ATG’s Commerce onDemand platform (of which we are an implementation partner). Our task was to implement a new design, created by Sweden Unlimited (who also created the marketing side of the website) into the Commerce onDemand platform. We were integral in creating the base Commerce onDemand HTML/CSS framework so it was a natural fit for us to implement the new DVF design into the platform. My personal role was the HTML/CSS integration of the new design as well as the Scene7 integration which allows for product image zooming and alternate view display.

The font size of the calendar module on the personalized homepage is very small. And just got smaller with introduction of your theme options for the personalized homepage (which I like, so thanks for that). The font-size declarations in the classes “eventChip”, “eventCell” and declared inline in the div with an ID of “createEventLinks27” are causing this unnecessary eye strain. Removing these declarations will make the font readable again (and the module useful again).

I am submitting this message in triplicate to ensure it reaches the proper personal. Also attached is a screenshot of the issue.

Thank you for your time.

Update: Looks like Google has fixed the issue by updating the font sizes units from percentage to ems. Good show.