When I was hired at LexisNexis back in 2003, it was to develop HTML templates, often to take to Usability testing. I’d been building actual web sites professionally for four years, so initially I felt this was “a step backwards”. Soon, however, I realized that template building is really more of an art, and indeed more elegant.

When you’re working on a website, you know what you’re building. When building a reusable template, there is a level of abstraction that must be accounted for. It’s a focus on the presentation layer for its own sake, rather than as the wrapping paper laid over the all-important data.

Over several years of template building, I’ve found there are several important notions that increase the efficiency in template creation as well as the overall quality of the deliverables.

Pick a Server-Side Scripting Language

PHP, JSP, ASP- I don’t care.

Identify variations in user or system state

A site of any complexity will have some level of variation in user or system states (authenticated vs unauthenticated, empty shopping cart vs non-empty). Identify these states up front, and determine what the implications are to the UI.
Create variables to represent each of these states. (loggedIn, cartEmpty). Use these variables to manipulate each individual variance across the site, in response to a query parameter being passed in. It is important to identify a default state.
By treating each variation itself, we are able to account for a greater number of combinations of states.

Be Lazy

Never code ANYTHING twice. Anytime something is on a design, ask if it will occur elsewhere. If so, make a generic version of it and include it. Coding anything more than once is not only inefficient, it risks introducing unwitting variation. If I pass off two pages to a development team and they each treat the same thing differently, which should be used? Leveraging the same code also helps to ensure the code is at an appropriate level of abstraction and can account for variation of data.
For me, the best template project involves the fewest number of discrete URLs.

Remember: this is a TEMPLATE

A template is commonly defined as a pattern. It should be simple to follow and easy to apply elsewhere. Remember madlibs? Enter in the appropriate type of word and it populates where it’s intended to be. That’s what templates should do. Define the rules around the content, and then just give it a slot to plug it in. If you have a column to hold images, build the framework around it to give the images the appropriate spacing you need; don’t expect the next person you hand the code to to apply your specific class names to elements. Dummy-proof it Make your code apply to the whole, and then only code for exceptions as needed. If possible, push back on designs that necessitate “exceptions”.

Respect the Data (Unknown as it is)

Data coming from an external source is like a box of chocolates.. In the absence of specifics, the diligent developer must anticipate the possible areas of variation and recognize the boundary cases. A certain design may work wonderfully if there are three lines of text with a font size of 10px, but what happens when more (or less!) text is needed, or the visitor increases the font size? This is the difference between the designer and the template developer: one is in search of the ideal design, and the other anticipates the limits to which it may be pushed.

Know Where You Are

Relative paths can make or (literally!) break a template project. The use of absolute urls means you don’t need to worry what page is trying to access your assets from.

Assign Appropriate Class Names

This is related to the points above, but is still worth calling out on its own. Reuse code, recognize you’re creating a pattern, and be lazy. Use generic class names related to the overall semantics or layout (i.e. navbar), not the specific data you are trying to markup (search-results-sidebar). Naturally, exceptions can be coded with more specificity, because there must be some knowledge about the particular data for it to be recognized as an exception. But manually calling out the same type of layout of multiple pages is once again introducing the possibility of error: if we have 12 pages we’ve templated out and manually apply a style to 11 of them, is that an oversight or intentional? What do we do when we have to create a new page?

Plan for failure

Depending on the level of fidelity, a template project may or may not have javascript interaction in it. If so, it’s a best practice to check to ensure an element exists before acting on it. This should go without saying anytime, but it’s particularly important when the same footer (and JS script block — you DO put your JS at the bottom of the page, right?) is being pulled into different template pages. Always check to ensure an element isn’t null before attempting to manipulate it.

Explain, explain, explain

There is no shame to commenting code. Especially exceptions or default states. A name and initials is a nice touch as well, particularly when a project is in the early development stages. Many development teams will comment in the server-side scripting language so that it is not rendered in the outputted source code, and outsiders will not be able to see it. This is great; it is only the developers who need to be aware why things were handled as they were.

These are just a few of the tricks I’ve picked up over the past several years. It has occurred to me that template building is almost a different skill than straight-forward web development, and I wanted to capture some of the nuances. I imagine my friends and former coworkers could add to the list!

Just a word of warning — on April 9, 2008, this site may or may not be work-safe. It’s CSS Naked Day, and I’ll be participating. On that day (and a few hours on either side, to account for timezones), this blog will be CSS-free.

The standard blurb is as follows:

The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good ‘ol play on words. It’s time to show off your <body>.

As a web developer who really focuses on the presentational tier, I admit I’ll be interested (and a bit nervous) about seeing how my blog holds up without stylistic treatment. Sure, I trust the wordpress folks, but…

(And yes, I know I could use any number of extensions to see how my site looks unstyled, but there is just something about having it out there for all to see!)

Today I was back in ATG developer training - in their Commerce course. Some of our time was spent looking at templates for category and product pages. This was something I’d been thinking of on my own, and it was good to see that my ideas were right on track.

Basically I had been thinking about templates on both the presentational as well as the content levels. The templates we looked at today were set at the content levels. That is, a particular template could be created to ensure consistency across pages, but there could be rules set up to support deviations from the standard. Elements are associated with a particular template, which would basically serve as the way to retrieve the specific properties of the element.

My second thought was to create a presentational template as well, to support how these elements should be displayed. A simple idea I gave a colleague would be that every product page would contain a description, a title and an image, but in some cases we may want the image to the left rather than the right. The underlying data would be the same, but we would want the presentation to be slightly different. (this could be applied even so simply as including a specific stylesheet)

Wow — Eric Meyer in a box - I’m intrigued.

CSS Sculptor appears to be yet another “web development in a box” solution, but this one is standards compliant and (obviously) CSS-based. I listened to one of the tutorials for only a few moments, but it mentioned something about “if you click in the wrong area [the program] will remind you…”. I suppose that is how they can ensure the standards-compliance.

When I first started working in CSS, I used top-style to learn what styles or attributes could be applied to which elements. I suppose this program simply provides a stricter framework.

I would be interested to find out how robust the program is, if a user would have the ability to really get at the code and muck about, or if they are limited to working within the established framework. I notice there is mention of faux columns — does that mean there are CSS “modules” or techniques that are included and/or can be imported at will? I’m afraid I don’t entirely understand how this dreamweaver extension works — could it itself be extended upon? Does it clean up code that a user inputs manually?

Lastly, I would be very interested in seeing what the generated code would look like in terms of optimization. I don’t suppose there would really be any hope for true cascades?

I don’t see myself spending the $99 for the software (although I would have downloaded a free trial ), but I will be interested to see what sort of review/response there is to this product..

I was recently asked how I approached coding, in terms of validation and standards. I said that when I had complete control over the code, I coded to xhtml1.0 strict. “for all browsers?” I was asked. The question took me aback. Yes, of course for all browsers. I wouldn’t even know how to code differently for separate browsers. Sure, CSS and JS take some work to standardize, but for me, coding to xhtml1.0 strict is a no-brainer. [I did give the disclaimer that when using an imposed infrastructure, I had to take a step back down to HTML4-.10 transitional for when we were using struts, and I'm still not sure we'd validate]

Further in the conversation I realized that while I can strongly claim adherence to xhtml1.0, I can’t do the same for a certain version of CSS or javascript. I know there has recently been a call for CSS2.2, but honestly, I just use code that works. So too for javascript. In a similar case, I skimmed something that mentioned some new functionality for javascript1.6. Are we up to 1.6? Who knew?

That’s what struck me: the aspect that I consider ’stable’ (xhtml), I code to completely and I’m familiar with it. The other two, that require more knowledge of ‘what works’ and ‘what doesn’t', I have more applied knowledge. I don’t know if it is due to the age of the technologies and how well they are handled by user agents or not. That is, (x)HTML is a markup language, and is platform- and device-independent. It is when you get into presentation and behaviour that the browser quirks rear their ugly heads, so it is not simply a matter of knowing the technology, but also how it interacts with the various platforms.

Will I ever get to a point where I can say “I code to CSS3?” I’m not sure..

Just came across Eric Meyer’s Formal Weirdness, which reminded me of some other thoughts I’ve had as of late with regards to forms.

The styling of form elements is challenging using CSS. I keep stumbling over the fact that name is deprecated in xhtml1.0 strict, yet I can’t submit a form without it. I still tend to use dot notation to access form elements, yet use the DOM to access elements outside forms.

These differences have caused me to start thinking of forms as separate entities than the rest of the page, with different access methods (behaviour) and display properties (presentation). In my response to Eric’s post, I mused if this was a result to how the web has evolved:

stage 1: static pages contained information for people to access
stage 2: forms allowed users to interact with the page.

The fact that the two stages are fundamentally different in terms of purpose is illustrated by the fact that screen readers have different ‘modes’ for the two purposes. Now here’s a thought: why are there different modes for non-sighted users? Is there an assumption that sighted users can differentiate them based on visual clues? Is there a reason why we can’t go all willy-nilly, styling things to our heart’s content? Does Safari really have a good reason for squelching our creative flair?

I wonder if the further modularization of XHTML and the adoption of XFORMS will make it increasingly obvious that the rules are different…

One of our Human Factors Engineers just asked us to compile a list of “what makes good code”. He had a few initial suggestions, and they were added to for the following list. Although I think we are aware of certain principles, how do we create a checklist of what is “good” versus “poor”.

1. The code is valid
2. Inline comments are used consistently and effectively
3. Alignment and structure of the code display allows for easy scanning and reading
4. The code is accessible
5. Tables are not used for layout
6. CSS is used appropriately via an imported style sheet, a linked style sheet, or styles in the header (in that order).
7. The code is as slim and compact as possible
8. The code uses semantic markup
9. Inline styling and scripting is kept to a minimum
10. Graceful degradation is kept in mind

Today we are having a meeting with the visual designers to set out ‘theme names’. I am working on developing a library of UIBuilding Blocks, and will be using these themes to categorize the display. So far I’m looking at using xml, xsl and css, and have already had some fun in trying to tweak the xsl to get the different designs we have already established.

I definitely see merits in this, but it will take some time to get it right! Once it is in place, however, I definitely foresee many benefits!

You can’t currently use CSS to target input elements of a specific type. (i.e. radio, text, etc). This can be a pain when you want to set padding on radio buttons, or a width on textfields. Today’s issue was adding left padding to a button.

I decided to throw together some script to find these elements and apply the appropriate style info, and this is what I came up with:

function cssInputTypeFix(tipe, stile,val) {
  <!-- until browsers support CSS input type -->
  var inputs = document.getElementsByTagName("input");
     for (var i = 0; i < inputs.length; i++) {
         if (inputs[i].getAttribute("type") == tipe) {
             inputs[i].style[stile]= val;
         }
      }
   }

I then applied this when the page loaded, with Simon Willison’s handy dandy addLoadEvent script

addLoadEvent(function() {
   //cssInputTypeFix(type,style,val)
   cssInputTypeFix('button', 'marginLeft', '5px');
   }
)

And of course, as soon as I finished I did a search on the web and found this article: http://www.dustindiaz.com/input-element-css-woes-are-over/ It is along the same lines, although he creates styles such as input.text, input.button and uses the onload event to append the appropriate classname. Well, mine can do that too

cssInputTypeFix(‘button’, ‘className’, ‘button’)

where you have a class named button.