Monday By Noon

Current Events: The Official End to XHTML

Jonathan Christopher — Mon, 06 Jul 2009 11:43:47 +0000

Late last week, the W3C released a seemingly “light on perceived emphasis” note announcing that the XHTML 2 working group is expected to disband at the end of 2009. The long running debate between XHTML and HTML has finally come to a close, and we’re all better off for it. Regardless of your opinion on the subject, you’re better off. Instead of two camps working toward separate goals, our efforts are now combined for the greater good and we’ll all benefit.

It’s been a long time coming

The debate has raged for quite some time, and many people have taken a stand on the matter, including myself. From the people I talked to, most had taken a stance on one side of the line, and been comfortable in doing so. Each camp had good reason behind its decision, but HTML 5 is now the official victor.

The response to the announcement has been very… interesting. There is quite a bit more misinformation out there than I had originally expected. I realize that not every developer writing markup is going to know the defining characteristics of such emerging technologies, but there are some misconceptions out there that just don’t fit. If you’re at all confused behind either technology, there is a ton of information out there, and I highly recommend you bookmark a few articles to read at your leisure over the coming weeks.

Reading a few of those articles should really help you to begin to understand the fundamental differences between HTML 5 and XHTML 2. They will also help you to recognize the similarities as well.

What it means to you

One of the most interesting pieces of commentary I’ve come across to date on the subject is the reactions posted to Mr. Zeldman’s XHTML DOA WTF. It’s obvious from that comment thread alone that there is far too much confusion surrounding this decision that has been made by the W3C. Many people don’t understand the true effect this has on our future work, and fail to see the benefit of such a decision being made. Also a very interesting read, specifically as a follow-up to Mr. Zeldman’s comment thread, is Comments on Comments on Zeldman’s XHTML [DOA] WTF.

A great way to continue the streak of knowledge is to check out a great resource that has bubbled up recently: An Unnofficial Q&A about the Discontinuation of the XHTML2 WG. Although unofficial, it is by far the most targeted Q&A I’ve seen so far. A big take home message in the Q&A is this:

Did the W3C kill XHTML2?

No, XHTML2 was already dead for all practical purposes due to its failure to be backwards compatible and its failure to deliver compelling new features. The W3C just announced they will take it off life support.

XHTML2 has indeed been dead for some time, the announcement only makes it as official as it could ever be.

It’s a great move for everybody

I’m a huge fan of HTML 5, and I was pleasantly surprised to see the announcement from the W3C last week. I’ll also go on record saying that although it was beyond the scope I had imagined, the reaction of many developers is completely expected. Unfortunately that’s a result of not enough self-education, and will eventually sort itself out. I will continue to prefer HTML as opposed to XHTML simply because I will continue to enforce the aspects of XHTML I really enjoyed in the HTML I’ve been writing and will continue writing. Another piece to take home from An Unnofficial Q&A about the Discontinuation of the XHTML2 WG is:

If I upgrade from XHTML-served-as-text/html to HTML5, do I need to revise all my empty tags?

No. HTML5 permits both the XHTML-style syntax (
) and the HTML 4-style syntax (
) for void elements (elements that never take any content).

The syntax rules seem to be the most common denominator when it comes to XHTML fans. You can still write markup in a very strict way, but you’ll need to enforce it yourself as the rules themselves are more lenient.

Last, but absolutely not least, how can you not like this:

What’s the doctype for HTML5 documents?

Simply:

There is quite a bit of great information in An Unnofficial Q&A about the Discontinuation of the XHTML2 WG and you should assign it to yourself as required reading this week, along with a number of other articles on HTML 5 and what it means to everyone, not just us writing the markup.

Google’s “Let’s Make the Web Faster” Movement

Jonathan Christopher — Mon, 29 Jun 2009 12:04:57 +0000

I love Google, I really do. The company and all of its work is heavily integrated into everyone’s lives no matter how hard you may try to escape it. Google not only takes a lot of initiative when it comes to the Web in general, Google has done a lot to facilitate Web development on many levels. From Google Code to Google Gears and many (many) in between, Google’s latest venture, Let’s Make the Web Faster, is geared directly at Web developers.

What you can learn

By far the largest resource available on Let’s Make the Web Faster is the collection of articles available. The articles are put together quite well, involving a good blend of video and supporting imagery. You’ll be able to quickly learn the background behind some of the jargon used in document optimization.

Articles aren’t limited to front end development, because there’s more to writing markup and style if you’re a Web designer. Google takes the time to discuss other relevant areas such as the optimization of Web graphics for faster download times without losing quality. There are also articles on optimizing your JavaScript and even some PHP performance tips. One of the headlines that first caught my attention was UI Messaging and Perceived Latency — what a great topic. Google also includes a number of links to various Tech Talks @ Google, which are always a good watch.

Let’s Make the Web Faster launched as a very information-rich resource, and I imagine Google will be adding new articles fairly consistently from here on out. What’s great is that Google has done its part in retaining the community value of Web developers by devoting a section of Let’s Make the Web Faster to the community, opening doors for your input.

As with everything, be wary

Just because you read it on the Internet, the information you got may not be bulletproof, even if Google wrote it. Articles attempting to Debunk Google’s Internet Optimization Tips are beginning to crop up, and I think it’s great. Google suggests a number of techniques, actively put in practice on many Google products, that I will personally never employ just because it skirts around a rule or two. Saving a few bytes by writing sloppy code just isn’t something I’m interested in doing.

Like every Web designer, I’ve worked in PHP. I tend to really like PHP, but I don’t know PHP on the intimate level that programmers know PHP. I’m still learning about how the language itself actually works. I’m specifically interested in what PHP does differently than other languages which causes it to be huffed and puffed upon by so many.

It’s very interesting to read that some of the PHP optimizations suggested by Google may not be entirely accurate. I always enjoy reading technical pieces written by programmers who will always know more than me about programming. The existence of such a thread shows the nature of the PHP community, and it’s good to see that even Google might not know everything after all.

The important thing to keep in mind when reading Let’s Make the Web Faster, as with reading every article on the topic of Web development, is to take everything with a grain of salt, and to not follow the advice blindly.

Page Speed for Firebug

Everyone knows about Firebug. It’s arguable the most widespread, actively used tool by the majority of developers and designers, and for good reason. The tool changed the way many people approach front end development, and it was a true game changer.

Some time ago, Yahoo! released an add-on for Firebug called YSlow. The tool aimed to help developers analyze documents and suggest optimizations not only for speed, but rules for optimization. YSlow proved to be very helpful for many people, and I know I learned a thing or two about some of the techniques I had been using for quite some time.

As part of Google’s initiative, they have released Page Speed, also a Firebug add-on aimed at page performance analysis. After installing the Page Speed add-on, you’ll notice a new tab within Firebug:

As with YSlow, you need to invoke the analysis by clicking a button quickly after navigating to the document you’d like to test. After completion, you’re provided with a very detailed report containing a breakdown of the criteria against which your document was run:

Additionally, Page Speed takes another step forward in offering to apply a number of optimizations to your document immediately. For instance, if deemed necessary, Page Speed will go ahead and minimize your JavaScript on the fly, as the browser downloads the JavaScript, having an optimized version ready at any time:

The last feature within Page Speed I’d like to tout is the CSS analysis. Beyond suggesting the combination of CSS files to reduce the number of HTTP requests, Page Speed will examine your style sheet on a per-line basis, letting you know what could be written better:

Page Speed will separate your ‘very inefficient’ and ‘inefficient’ rules and let you know what makes each less than ideal.

As with YSlow, Page Speed has links throughout the panel directing you to the information backing up the suggestion, found on Google’s Let’s Make the Web Faster. I would suggest that everyone have Page Speed at the ready during a testing phase of a Web project. It will make sure your documents are top notch concerning performance, and you’ll become a better developer because of it.

There is an abundance of information available if you’d like to read a bit more before installing Page Speed. Even if you’re not a Firefox user, I absolutely suggest keeping it on hand not only for render tests, but optimization tests using Page Speed as well.

Overall impression

There is a lot to learn as far as Web page optimization goes. As new technology appears, you’ll have to learn even more, but it’s an important aspect of Web design and a valuable part of the medium. It’s important for you as a professional to know how to produce work of the highest caliber, and optimizations can do a great deal to make your work feel that much more polished. Google’s “Let’s Make the Web Faster” is a great platform that should help spread the word very quickly to a large audience.

I hope to see Google continue developing content for the recent project, and I hope to see a decent community response, especially debunking any poor advice Google may be giving by offering detailed responses. While certain practices may achieve the most desirable result, it will be up to the community to ensure that the actions aren’t welcoming detrimental side effects causing more problems than before.

Improving Your Process: Faster Front End Development

Jonathan Christopher — Mon, 15 Jun 2009 12:19:59 +0000

In our business, time is of the essence. Regardless of your billing policies, as a professional designer it is imperative that you have the ability to accurately estimate a workload and then follow through, on schedule. The ability to estimate work comes only with experience. You can read countless articles on design, even specifically on Web design, but until you get at least a year of consistent, professional work under your belt, it just won’t be there. It’s absolutely no fault of your own, simply because you haven’t worked enough.

That said, depending on your billing structure, you’ll be able to optimize your workflow in such a way that not only reduces your stress level, but will make your clients happy to boot. I mention a dependence on your billing structure simply because sometimes getting a project done well under a time-based budget can result in trouble for you financially. The important thing to realize, however, is that with newfound extra time comes extra polish. If you come in a few hours under budget, you now have the time to try that element you were toying with in design. Does it work now? How about the leading in that area? Would it look better if it were bumped up, just a bit?

Reducing the time you spend on front end development can lead to more experimentation and a better end product should you have extra time to play with late in a project. Personally, I like to keep front end development estimates to a minimum, allowing the budget to focus on design. I work with a team of designers, so the better we plan from the start, the better a project will go.

Have a plan, start with a static file

By far the most effective way to cut down on front end development time is to be involved in the design process. You don’t even have to be the designer, but you should periodically review any design for a basic feasibility assessment. That’s not to say that you should be prototyping designs to make sure something is going to work, but you should be able to process a design to a level that will let you be comfortable with it.

As you examine a design, try to abstract your brain from admiring the aesthetics of the design. Try to visualize how you will approach the front end for this document. Take a look at a comp for another page, can you determine how much markup and style you’ll be able to reuse from the first page to this one? Are there any modifications that should be made to the design to establish some consistency on a more technical level? Take a second look at the design, take a third look. Has someone added a gradient or texture that physically can’t translate to the Web?

Once you’ve signed off on approval for a design and it comes time to begin work, I can’t emphasize enough how much it will help you to start with a static HTML document. Stay away from your server side technology, no matter what it is, and instead use a static file that takes advantage of any dynamic resources you’ve set up.

For example, at my company we’ve established a site framework that we use to begin each project. In this site framework is your usual array of template-supported, server-side powered files that tie in directly with our CMS, and the like. Alongside this set of files are two static files: home.html and secondary.html. These are the first two files I’ll open and work with on a project.

The files are prepped in such a way that the path to the CSS directory is hard coded, removing the need to copy and paste once our original documents have been written. I’ll work my way through a secondary page, then the home page, and once that’s done, I’ll integrate.

Write your markup first, all of it

Nearly two years ago, I wrote about my development and design process. Much of my strategy remains the same to this day, specifically the first steps I take. The initial markup process ties in heavily with the original review of a site design. From the first time I open a PSD or PNG my mind begins working, breaking down the design into markup and markup alone.

I’ll break apart the design into sections, until I’ve found myself at the lowest common denominator, whether it be an h3 or an li. Once I’ve got a general idea of the overall structure, I’ll write it. All of it, from #header to #footer. I’ll switch to and from Fireworks (or Photoshop) and my editor, making sure all of my elements are in place.

Writing the initial markup for a document doesn’t take very long, an hour if you take your time. There really isn’t that much to it, especially if you’ve had a look at the design as it was being put together. You already know what to expect, and you can hit the ground running.

The important thing to keep in mind at this step is optimization. Don’t move on to CSS until every bit of markup is in place to support the design. Sure, you’re probably going to have to add an element or two as you continue development, but getting the initial structure entirely in place will be super helpful when it comes to the style layer.

Use a reset stylesheet

I can’t stress enough how helpful a reset stylesheet is when it comes to optimizing your front end development. It doesn’t have to be Eric Meyer’s reset stylesheet, but working from a consistent base is extremely helpful when it comes to building out your CSS, even more-so when it comes to The Browser Gauntlet.

Write CSS in blocks

I can remember my first few weeks with CSS; I’ve never been so excited to refresh a browser, and I never will be again. With each refresh came a new and exciting change that I was struggling to understand. Learning about CSS was very exciting for me, but it forced me to implement designs slower than ever. As with everything, the more you do, the better you get. As your skill with CSS grows, force restraint on yourself when you think you need to refresh the browser.

Chances are, that property:value; you just set is going to work out just fine. Move on to the next, and the next. Finish setting all the properties you want for that selector and then switch over to refresh. Once you’ve become comfortable with that, style an entire div before refreshing. Once you’ve become comfortable with that, structure your entire document before refreshing, and the move on to styling each div you just positioned.

The more CSS you can write in a single thought, the better and faster you’ll be. The important thing to keep in mind, though, is not to write too much at once. As you’re forcing yourself not to refresh, you may make a significant mistake that wreaks havoc on a few dozen lines of later CSS. Push yourself, but don’t push yourself too far too fast.

Save JavaScript until last

Exciting as it may be to implement, make sure you’re postponing all JavaScript development until last. Integrating JavaScript too early is going to destroy the integrity of both your markup and style, and will cause more trouble than it’s worth.

Instead, take the time to develop the markup and style for any states you may be integrating with JavaScript, and make sure they’re ready to be toggled (or otherwise) via JavaScript. Abstracting markup and style from JavaScript can help you to focus and optimize as you put together a design.

Take advantage of helpful tools

My last tip is something I depend very heavily on; finding the right tools for the job. If there are any applications under consistent development and refinement, it’s Web development applications and tools. Even browser makers are now giving us gold platters with which to work through built in developer tools.

First, find yourself a great text editor. Who cares what everyone else is using, find something that you enjoy working with, and most important: something stable that saves you time. I can definitively say that TextMate (Windows users: e text editor) has had significant impact on my development time.

There are plenty of fancy tools out there, but I can’t stress enough the importance of your editor.

Along with your editor, another integral part of your workflow is your browser of choice. Your browser should support your efforts, providing the tools you need to get the job done. Toolsets for browsers have been talked to death, but a favorite tool of mine has never received much press, and I’d like to heavily suggest your adoption of it.

ReCSS is a bookmarklet that comes from dojo and it’s something I use on a very consistent basis with every project. The sole purpose of the bookmarklet is to force a reload of CSS used on the current document. This helps you to avoid reloading the entire page (including server processing and other latency) and instead request only the latest stylesheets. It’s such a simple idea, but I’ll use the bookmarklet at least a few dozen times per-project to ensure that I’m not dealing with any caching issues.

Let’s have it

Do everyone a favor and post your favorite time saving front end development tip or trick.

Improving Your Process: Thinking More About Your CSS

Jonathan Christopher — Mon, 01 Jun 2009 13:17:50 +0000

Over the past few months, I’ve been trying to keep an eye on myself as far as writing CSS goes. Writing CSS leaves a lot in the hands of the author, and every designer has his or her very own method to madness. When it comes to CSS, you can do anything you want, which is mostly valuable, but sometimes hurtful with inexperience. I’m always curious to know the thought process behind writing CSS from the eyes of the author, as every stylesheet can be quite different from the next.

The way you write your CSS today depends heavily on what you were initially taught (self or otherwise) in conjunction with other things such as what you’ve read that counteracts your teachings, as well as the level of desire to improve your craft. I like finding out the lessons learned behind your reasons (or lack thereof) for writing CSS the way you do.

I really enjoy writing about CSS, and if you’re a fairly recent subscriber, here’s a quick breakdown of my tips, tricks, and suggestions from the past:

Write Better CSS: One of the earliest articles I had written for Monday By Noon, but I still practice much of what was written over three years ago.
Improving Your Process: CSS Techniques Part 1: In the first part of the Techniques series, I mentioned a few ways that I tried to be more organized with my CSS writing, especially when working with a team. I have made some revisions since the publication of that article, specifically in dealing with browser defaults. Apart from that, I still stand by the advice offered in that piece.
Improving Your Process: CSS Techniques Part 2: In this article I made public my switch to using a reset stylesheet. I also tried to put into words some of the thought process behind my front end development process. You won’t find many code samples in that article.
CSS Organization Methods and Writing Style: This article was all about writing style. Style as far as comment blocks, overall stylesheet organization, right down to single line versus multiline. I touched on the idea of using flags as a hook for searching to quickly find various sections of your stylesheet, but that didn’t catch on with me.

With that reviewed, I’ve got a few other things I’d like to share as far as my CSS writing style is concerned.

It’s about patterns

One of the best habits I’ve found for myself is the desire to find patterns in designs. Patterns go a long way in design, and every good design inherits a certain level of pattern. Whether it be in organization, texture, or otherwise, a pattern provides consistency, and you’ll see patterns everywhere on the Web.

It will be in your absolute best interest to discover these patterns prior to writing a single line of markup or style. You want to use patterns to your benefit. Not only will finding patterns reduce your workload, it will make maintenance that much easier.

Jeff Croft recently posted an insightful article on finding patterns in CSS, but instead compared it to applying OOP concepts to CSS. I’m a big fan of Jeff, and much of my fandom comes from a similarity not only in workflow, but also opinion and thought process when it comes to Web design. In that article, Jeff puts into words something I’ve tried to verbalize in the past, and I’m thrilled to have it as a reference now.

I can see how using OOP methods in your CSS can be an eye-opening discovery, but it’s very important that you don’t become overzealous with it. As with many aspects of Web design, there is a fine line to walk when it comes to finding a happy medium with something like this. You’ll need to take a step back and really think about your implementation before taking action, else you’ll find yourself fighting an uphill battle when it comes to troubleshooting and maintenance. Using too many classes in a widespread way is going to cause trouble when you need to make a sitewide change and need to edit nearly every file on the site because you used a combination of classes in too many places.

Before I begin writing a line of markup, I take enough time to look at every comp for a website. I’ll look to see which elements, both structural and stylistic, have a repetitious property to them. I’ll keep these repetitions in mind as I write my initial markup, and then again when I’m later starting to write my CSS, and use the patterns to my advantage. Experience will help you better recognize and use patterns as you design and build more websites, but it will be a great skill to focus on throughout your career.

It’s also about structure

One of my biggest peeves when maintaining CSS is poor stylesheet structure. That is to say, when a production stylesheet has been in place for a decent amount of time, and the website has undergone some revisions, the edits were not properly put in place. Instead, declarations are sometimes simply appended to the end of the file to ensure their application, instead of finding the proper place in the file in which to make a change. I can recognize the desire to do such a thing, especially if you’re doing maintenance yourself, and the original file structure is so unkempt it would take hours to sift and organize it yourself. While the fault lies with the original author, it’s something that should be entirely avoided from the start.

I don’t mean to say that the way I write my CSS is a superior way to do so, my point is that you need to have some structure to your stylesheets. The technique I use for structuring my stylesheets is roughly the following:

Global styles such as ‘main’ copy properties (size, color, font) at the top
Global structure definition (main (secondary) page structure)
Header styles
Content area styles
Sidebar styles
Footer styles
Per-page specific styles

My basic reasoning is to work top down as far as specificity is concerned. I’ll work from the most global properties down to the most detailed as I work through a stylesheet. I try to keep things organized with how I think in a way. I’ll start with the main structure of the document, and then continue to style the header, content area, sidebar, and footer, respectively.

Once the more generic, consistent styles are taken care of, I’ll set up sections of the stylesheet specifically for one-off pages in the site should the design require it. Proper attention is given to these groups of styles via comments outlining which page is associated with a set of selectors.

Working in such a way will help you abstract which edits will affect the site in its entirety as opposed to the single instance you’re trying to modify. When working on a site you didn’t originally style, it’s very easy to make an edit that may in fact destroy a significant portion of the site you’re not even aware of.

Do you consitently keep your CSS in check?

Is it strange that I still put this much emphasis on the quality of my stylesheets? Are you at all interested in how other people write CSS or do you prefer to work in the way you’re comfortable? What techniques do you use when organizing your stylesheets from a more global perspective, as opposed to writing comments here and there for reference?

Building Functional Alt Sites using SWFAddress

Jonathan Christopher — Mon, 18 May 2009 15:40:37 +0000

My position on Flash changes from time to time, but to be brutally honest, I’m not a big fan. I absolutely see its worth, and understand that using Flash can enhance the experience of a website in a wide variety of ways. To me, though, Flash is not the Web at its greatest. The Web, to me, is information. It’s a living, ever expanding library of data available for our interpretation and digestion. That’s not to say that the Web can’t be used as an entertainment platform, however. The Web is becoming more adaptive to the entertainment industry than it has ever before, and all for good reason.

When it comes to websites though, seeing a website built in Flash is a near guaranteed turn off personally. To me, a website built in Flash forks away from the inherent purpose of a website, and turns into a novelty. From the most generic standpoint, my opinion doesn’t even generate from the accessibility and performance concerns that come from a website built in Flash. It’s the usability of the website, the fact that it’s just, different.

However, many clients are attracted to websites built entirely in Flash. To me that comes from an interest rooted in everyone: motion. Things that move are, by default, more interesting to look at. I think I’ve discovered that my distaste for such things comes from a personal appreciation that has evolved as a Web designer. To me, a website with a solid design, solid information architecture, is extensively more pleasing than something that glows and animates left to right simply for the sake of visual stimulus. Information architecture, to me, is that visual stimulus, and making it move around completely detracts from my experience.

I don’t mean to say that a Flash site, by default, lacks anything from an information architecture point of view. In fact I’ve seen many Flash based websites that were designed terrifically, I simply would have preferred to view it as markup and style. I have the upmost respect for Flash designers & developers, as some of the work is simply stunning. I’m speaking from an abstract personal preference here, full of my own bias. I don’t mean to offend and I hope this isn’t coming off with any sort of attitude.

Working with Flash as a front end developer

I think my opinion of Flash based sites comes from my position as a Web designer. Specifically I’m a Web designer with a focus on front end architecture, quite different from a Flash designer. I’m a big believer in great teams working very well together, and my company has some terrifically talented Flash developers that I work with every day to create stunning pieces that please our clients. I need to put my opinions aside and make sure that the client gets what he wants, all the while making sure the website has an equally effective and useful alternate site to use. That involves a revised design to accommodate the variation in medium, as well as the development and deployment of that website for use.

One of the greatest things to ever happen to Flash, in my opinion, is SWFAddress by Asual. SWFAddress is:

SWFAddress is a small, but powerful library that provides deep linking for Flash and Ajax. It’s a developer tool, allowing creation of unique virtual URLs that can point to a website section or an application state. SWFAddress enables a number of important capabilities which are missing in today’s rich web technologies including:

Bookmarking in a browser or social website

Sending links via email or instant messenger

Finding specific content with the major search engines

Utilizing browser history and reload buttons

Basically, what SWFAddress does is give Flash the ability to behave that much more like a regular website by enabling the built in functionality of the browser within the Flash movie itself.

Using SWFAddress is necessary when working with a Flash website, not only for the inherent functionality improvements, but also to the benefits of your alternate site. The Asual team has included many examples of SWFAddress as well as documentation for each, the one to focus on is the SEO Example. This sample demonstrates what SWFAddress can do to integrate your Flash site with your alternate site seamlessly, allowing for effective search engine indexing, as well as equivalent access to your alt site.

The demo provided gives you access to a bit of PHP that handles quite a bit of redirection when it comes to processing a URL request. The script will help to determine if the visitor does indeed have Flash/JavaScript and in turn provide the proper “enhanced” URL, while passing site content to a user without the ability to view the Flash site. Clean URLs are retained and it’s actually a very effective solution.

Making an effective alt site

Building a Flash site is quite a bit of work, not only on the Flash side of things, but the development and maintenance of the alternate site as well. SWFAddress will route your traffic effectively, but you’ll need to manually distinguish which pages should serve which content and make sure equivalent content is represented in both websites.

With a content management system, you’ll be able to pull the same data per page via XML or otherwise, allowing both the Flash version of the site as well as the alt site, to pull from the same data source which will remove any discrepancy when it comes to content.

The inclusion of SWFAddress helps to tackle many of the baggage of Flash, and allows Web designers to create a very effective alt site both for the sake of search engine saturation, but even more importantly the benefit of accessibility.

What do you think?

What’s your opinion on Flash? Has that boat sailed when it comes to full websites? Will we see Flash only used when really necessary, for rich site widgets, video (until HTML5 becomes available), or other implementations limited to Flash? Does it bother you when you find yourself at a website built entirely in Flash? Does SWFAddress help with any issues you’ve got with Flash? With the advancements in front end technologies such as CSS3, CSS animations, canvas support, and O3D, do you think Flash is steadily taking a back seat for things to come? I’m just not sure if I’m alone here, and would love to hear some other opinions.

Covering the Implication and Basics of CSS Animation

Jonathan Christopher — Mon, 04 May 2009 12:45:53 +0000

Over the past few months, I’ve been embracing progressive enhancement on a new(er) level. I’ve been using CSS3 to make my life easier, leaving other browsers in the dust with the extra touches. I’ve lost all interest in making sure a design looks equally sophisticated in substandard browsers, and instead opted to leave that last column in my table left aligned instead of making the table a bit easier to read with right justification.

Of course I still support IE, and I don’t want to bring that up for debate at this time. That poor horse has been long gone for quite a while, so we can all put our sticks down for a bit. I have, however, taken a more aggressive personal stance in my lack of attention to detail when it comes to that browser family.

A tweet by Jeffrey Zeldman really got me hooked to the prospect of further adoption of CSS3:

When all browsers except IE support CSS3, it will test the limits of progressive enhancement as a design philosophy.

With my further embrace of and focus on CSS3 came an increased interest in other bleeding edge techniques in Web design, primarily CSS animation.

Does CSS animation belong?

One of the ways in which I’ve been trying to raise the overall comprehensiveness of my projects is incorporating CSS animation where it may enhance the experience of a particular design. Animation in CSS has, from time to time, been a hot topic in Web design. Does animation belong in CSS? Does it constitute behavioral modification to the document, and therefore find its proper place through JavaScript? Is animation technically behavior?

Trying to classify the true placement of animation has proven to be a personal challenge to me. I can see both sides of the argument. I agree that animation can be correctly implemented through JavaScript, as has been done for some time. On the other side of my personal coin, I see that animation is more of a visual stimulus as opposed to direct behavioral change (e.g. updating the DOM with data received via AJAX).

The basics of CSS animation

As with all new technologies, you should take a minute to familiarize yourself with implementation as well as implication to make a more educated (and therefore accurate) decision to (not) use it.

The WebKit team provided a very nice write up upon the release of a nightly build that supports CSS animation. In the post, an overview of animation with CSS is provided, as well as a bit of documentation and example.

The WebKit implementation of CSS animation has a bit of a learning curve, but once you decipher how it works, it’s quite elegant (in my opinion). Applying a CSS animation comes in two steps. You’ll first designate your style as you would normally, defining any properties you’d like, with the addition of something new: -webkit-transition.

-webkit-transition is actually shorthand for three transition properties:

transition-property: The property to which the animation will be applied
transition-duration: The length of time the transition will last
transition-timing-function: Possibly better explained as the easing method you’d like to use

With these three properties, you’re provided a set of tools that can directly affect the richness of your designs, bringing the level of interaction up a notch or two. To make things even more elaborate, the WebKit team has also included support for comma delimited transition declarations, allowing you to animate multiple values using a single property declaration.

A finished implementation of WebKit CSS animation may look something like this:

div.message a.dismiss {
  opacity:0.2;
  -webkit-transition:opacity 0.3s ease-in-out;
}

div.message a.dismiss:hover {
  opacity:1;
}

If you’re using a recent build of WebKit that supports CSS animation, check out the example.

CSS animation can have dramatic affect on your designs, especially in Web application enahcements. Jonathan Snook recently published a screencast outlining his use of CSS animations while playing with Titanium, a platform I’m actively researching as well.

Jonathan’s use of CSS animation in his screencast really brings its potential to the surface. With animations such as the combination of scale and opacity to achieve stellar effects really helps to make CSS animations shine.

What should control animation?

Truly classifying CSS animation has been a personal challenge for me as a designer; what are your thoughts? Do you feel that animation belongs in the realm of style or behavior? Do you feel animation is something else entirely? Now that an option beyond JavaScript has surfaced, did that change your opinion? Do you see animation in CSS being continually adopted on a more consistent level when it comes to adding ‘that little something extra’ for those using an applicable browser?

A Couple of Quick Tips for JavaScript Optimization

Jonathan Christopher — Mon, 27 Apr 2009 13:51:34 +0000

I’m a huge fan of JavaScript. I’ve spent the past couple years trying to really enhance my knowledge of the subject, and with the volatile ingenuity of the modern Web, I’m able to pick up new things on a very consistent basis. Keeping myself in check, however, is a recognition that I’ll never embrace all there is to know about JavaScript. The best I can do is teach myself everything I can, and have consistent discussion with those who know more than me. What better way than publishing?

I work primarily in jQuery when I write JavaScript. I’ve become very comfortable with the library, as it meets my needs on a very consistent basis. I’m not biased, however. With each project, I evaluate whether there’s a need for a full library such as jQuery. There have been many projects which simply didn’t need the full functionality of a library as feature-rich, and therefore bigger in file size, as jQuery. Many times I’ll use a more lightweight library such as DOMAssistant which lets you build your own library with modules you’ll be working with. There have been many times where dLite (DOMAssistant Lite) has been more than enough to work with, this site for example.

You should evaluate which library you’re using on a case-by-case basis as well, as it seems that with jQuery being so popular, many designers simply default to using it with every project, even if they’re only binding a click event in one area of a website.

As I’ve been writing more elaborate pieces of JavaScript, I’ve picked up a bit more knowledge in optimizations. It’s become my focus lately; trying to write cleaner JavaScript resulting in faster processing and therefore a better experience for the user. I’d like to quickly discuss a couple things I’ve started doing to ease the load of JavaScript on the browser and therefore the user.

Creating reference variables

Traversing the DOM is sometimes expensive, depending on your selector. Keeping node selection to a minimum will help speed up your scripts quite a bit. If you’re working with a specific node repeatedly, it will probably be in your best judgement to define a variable with that node, instead of traversing for it repeatedly.

For example, if you need to manipulate multiple children of a parent element, it is probably in your best interest to define the parent element as a variable, and work with the children from there.

While not a gigantic enhancement, we can project the benefits on a larger scale, especially when working with a classed element as opposed to one which has an id. This comes in especially handy if you’re nesting animations, and you need to work with the initial element throughout the process. You can simply reference the variable you’ve defined instead of possibly having to hunt for a parent() or two.

While libraries such as Sizzle are dramatically enhancing node selection, it’s always good practice to write inexpensive code, and sometimes selector abstraction is the way to go.

Avoiding iterative DOM manipulation

Perhaps the biggest change to embrace was to avoid manipulating the DOM iteratively. That is to say, making a change to the DOM each time you run through a loop. This practice is definitely not limited to jQuery, but I’ll be using jQuery syntax in code samples throughout this article.

Keeping this in mind came in very handy as I was working with creating custom selects via jQuery. Essentially what I needed to do was loop through an existing select and duplicate each option value as a list item in a newly created list. At first you may write your snippet like so:

// parse all options within the select and set indices
var i = 0;
targetselect.find('option').each(function() 
{
  // add the option
  target.find('.options ul').append('' + $(this).text() + '' + i + '');

  // check to see if this is what the default should be
  if($(this).attr('selected') == true)
  {
    targetselect.parent().find('a.dropdown_toggle').append('').find('span').text($(this).text());
  }
  i++;
});

You’ll notice that with each iteration of the loop, we’re appending a list element to our unordered list. If you’re running this function on a document with quite a few selects (especially with many options), you’ll notice quite a bit of lag.

This code can be better optimized by abstracting the injection until after processing the select in its entirety by concatenating the list items to a string, and then appending that string a single time:

// parse all options within the select and set indices
var i = 0;
var options = '';
targetselect.find('option').each(function() 
{
  // add the option
  options += '' + $(this).text() + '' + i + '';

  // check to see if this is what the default should be
  if($(this).attr('selected') == true)
  {
    targetselect.parent().find('a.dropdown_toggle').append('').find('span').text($(this).text());
  }
  i++;
});
target.find('.options ul').append(options);

Instead of appending the list item with each iteration, which becomes very expensive very quickly, we simply build a string and work with it once the heavy lifting has been done.

Do you have any tips?

I know these tips are nothing extraordinary, but I hope they may help you enhance the performance of your future scripts. I realize that my code examples use jQuery syntax, the tips themselves can be applied to any implementation of JavaScript.

Do you have any techniques you’re using consistently in the interest of both code organization as well as optimization?

Taking Advantage of What Tables Have to Offer

Jonathan Christopher — Mon, 20 Apr 2009 14:34:28 +0000

We’ll skip right over the nasty past that tables have and cut right to it: tables always have been and will remain very useful in Web design. A well designed group of tabular data can be an outstanding aspect of any document. Unfortunately, tables have a bit of baggage in that applying your desired style can sometimes be quite the challenge. As with everything in Web design, experience will teach you what is easily done and what just isn’t possible.

There is a ton of information available on what you can do with a table, but I’ve got a few things I’d like to share as well.

Effectively structuring your `table`

Beyond the basic structuring of table data using table rows and table cells, there are a number of elements you can use to make your tabular data that much more structured.

Some of the more basic, but helpful elements to take under your wing are row groups. Row groups consist of thead, tfoot, and tbody. You can group your table heading rows in a thead tag, your table footer rows in tfoot, and the data itself in a tbody tag.

Segmenting your rows into these categories will allow you to write more targeted, straightforward styles for your table. Instead of giving your table rows a specific class, you can use these tags to make your markup more semantic and easier to work with.

As with everything, there are some rules to implementing these tags in your table. For example, the most interesting aspect of this group of tags is that when using tfoot, you must include it before your tbody tag. According to the W3C:

TFOOT must appear before TBODY within a TABLE definition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data

It seems counterintuitive from a human standpoint, but rules are rules.

Perhaps the best kept secret about tables

It wasn’t until a few years ago that I stumbled upon one of the most valuable things I have learned about table markup. By default, columns in tables behave in a liquid manor to accommodate the data held within each cell. If a column of cells has more content, a bigger area will be devoted to that column of data. More often than not, however, when designing a table you’ll want each column of data to have a more targeted width. For a long time, simply due to ignorance, I would solve this issue by giving my table cells a class a defining a width using said classes.

That was of course until I came across column groups. Column groups allow you to tackle this very issue by giving each column a specific id and styling your widths from there. For example:


	New York Yankees 2009 Schedule Snippet
	
		
		
		
		
	
	
		
			Date
			Time
			Opponent
			Home/Away
		
	
	
		
			April 20
			7:05PM
			OAK
			Home
		
		
			April 21
			7:05PM
			OAK
			Home

New York Yankees 2009 Schedule Snippet
Date	Time	Opponent	Home/Away
April 20	7:05PM	OAK	Home
April 21	7:05PM	OAK	Home

To style the columns of the above table:

col#date { width:25%; }
col#time { width:25%; }
col#opponent { width:25%; }
col#home_away { width:25%; }

Using column groups is a much more effective way of styling your columns. There are a number of ways to define the actual width of your columns, you’re not limited to a percentage. Definitely take a few minutes to read the W3C documentation on these elements if you’re not familiar with them, your life may get a bit easier.

Further styling your `table`

Beyond the markup behind your tables, applying a layer of style is a different aspect of designing your table. There are many techniques for styling your table, and depending on your design, some techniques may work, and others won’t. My general technique involves adding only paint that helps support digesting the data. The last thing you’ll want to go overboard with styling is your tables — they’re meant to be a useful tool used in organizing a group of data. Keep that in mind as you add your style declarations.

One thing I’ll try to do, especially with larger tables, is include a variant of zebra striping. Zebra striping involves alternating every other row of a table to make it easier to discern the relationship between the columns represented in that row. There have been many studies behind the true value of zebra striping, and plenty of articles written. While research shows that zebra striping doesn’t improve readability on any sort of conscious level, in my personal experience, when used properly, zebra striping can make a table easier to read. I will admit, however, that I’m much more likely to use a soft border as a separator between rows as opposed to changing the background color entirely.

Another trick that I’ve become accustomed to using is pseudo-classes, specifically :first-child and :last-child. When applied to table cells, you can easily control your end caps to achieve a more polished look.

For example, using table th:last-child in conjunction with table td:last-child can allow you to right justify both the heading and data cells of your table which may prove beneficial to the overall design.

Share your tips & tricks

That’s what I do to keep my tables in line and looking pretty. Do you have any tricks up your sleeve that you have become comfortable with over time? Do you find yourself working with tables very often from project to project?

Our Yearly Reminder of What it’s All About

Jonathan Christopher — Mon, 06 Apr 2009 13:28:10 +0000

For the fourth year in a row, Dustin Diaz is bringing back CSS Naked Day. CSS Naked Day was brought about by Dustin as an effort to celebrate the goodness that is semantic markup and good document hierarchy.

The idea is this: for one day, each bit of CSS is removed from your website. For real. While the makeup has been removed, your website should remain proud. CSS Naked Day usually generates quite a bit of chatter, but there are plenty of designers who don’t know much about it.

The point of it all

Much of the (minimal) negative feedback about CSS Naked Day surrounds the concept that completely removing the style layer from a website will bring businesses to a screeching halt, turn clients into enemies, and generally wreak havoc on every website it touches. They’re missing the point.

We can safely assume that it wasn’t Dustin’s intention for shops to remove the style from client websites in celebration of CSS Naked Day. Instead, he’s trying to actively spread the word about the good things behind markup structure by enticing the Web design community to show that solid markup can indeed be a beautiful thing.

The idea behind CSS Naked Day is that you the designer remove the style layer from, say, your personal website. In doing so, you show the world that you truly know and understand what you’re doing under the hood and you make it look good. Your confidence in removing the CSS from your website is an act of community participation, not a hostile act against business.

Why I participate

I’ve participated in CSS Naked Day each year since its inception, and I hope Dustin continues the tradition for many years to come. I think it’s great to see that so many people appreciate the value of Web design, and I feel that CSS Naked Day helps bring us back to our roots for a few hours. All the while we’re spreading the words about semantic HTML to up-and-coming designers who are still wrapping their heads around the concepts and purpose of semantic markup.

I enjoy checking out the websites of participants and seeing what creative solutions others have implemented on one of the lowest levels we work. I check out nearly all the websites listed on the participant list and it’s great to see such an abundance of style-less documents for a short time. The worst part is not being able to view every site in the short window that is CSS Naked Day. The best part, though, is being able to easily make use of the website given that the style layer has been completely removed.

CSS Naked Day is a great way for a knowledgeable Web designer to get back to basics and be reminded of the fact that (X)HTML alone is an impressive markup language, allowing us to convey meaning on levels that many people will never see.

Will you participate this year?

CSS Naked Day has been around for years — what’s your track record? If you’ve participated before, do you plan on doing so again? If you haven’t, how come? If you’d like to find out the more technical details on participation, specifically how to implement a date check on your website to remove all of your CSS, there are a number of code snippets and plugins available on the official CSS Naked Day website.

Sexy Web Design Book Review and Giveaway

Jonathan Christopher — Mon, 30 Mar 2009 12:41:09 +0000

I’ve just finished reading Sexy Web Design, a very recently published book by Elliot Jay Stocks. I first saw Elliot speak at The Future Of Web Design 2007 during which I became an instant fan. His keynote was titled “Destroying the Web 2.0 Look” and not only did he engage the entire audience with thoughtful opinions, but also injected just the right amount of humor as well. I’ve been a subscriber ever since, and I was thrilled to see that he has put out a book.

Content summary

Chapter 1: Interfaces are Sexy provides a detailed explanation of what subsequent chapters in the book will cover. Interfaces are the first topic of conversation, and Elliot gives some insight as to why he’s a designer. The gap between real life and Web design is bridged by the topic of interface; what you see is what you get, and if it’s hard to use, there’s a problem. We’re also given a brief overview of Elliot’s suggested design process, which I took great interest in, with my fascination of process at the forefront. Unsurprisingly, Elliot’s design process is spot on in line with what I have found to bring the greatest success. Through his writing, it’s apparent that he’s faced resistance (read: cut due to budget) in the same areas as well, specifically the research phase. Throughout his explanation, Elliot provides some visual examples to support exactly the topic at hand.

The remaining chapters carry you through the design of a client website from beginning to end, outlining in detail the steps explained in chapter one. Chapter 2 focuses on the research phase of Web design. Elliot discusses the importance of receiving an informational design brief, which is imperative if you’d like to start off on the right foot. The design brief needs to answer (at least) a few standard questions that will give you enough insight to explore the proper angles in your design. Brand consistency is also touched on, something that takes true talent to effectively retain. Elliot also shines some light on his inspiration process, which ties heavily into the research phase, taking into account the details provided in the design brief.

Chapter 3: Structure is all about figuring out the underlying foundation for your design. Part design, part information architecture, part page hierarchy, the structure phase of a design process can bring anything to an entirely new level by adding a completely new level of organization to the table. As you read, you’re walked through the process of mapping out the site at hand, sketching some ideas, and finally carrying those sketches to the computer and digitizing them as wireframes. These resources will be heavily depended on throughout the rest of the design process.

The navigation of a website is arguably the most important feature throughout. Without an effectively implemented navigation, calls to action will be ignored, readers will become frustrated, and the website will be considered ineffective. Chapter 4: Navigation and Interaction discusses the various methods of including site navigation as a way to support website browsing, all while meeting the goals of the site itself. The chapter touches on many various navigation implementations, from global navigation, to breadcrumb trails, to supporting navigation. Additionally, the chapter discusses lists, drop-down menus, tabs, accordions, tag clouds, and tool tips as methods of effectively navigating appropriate information sources. Form interaction is touched upon in this chapter as well, providing some items to keep in mind as you’re putting together information entry sections of your website.

Chapter 5 focuses on another very popular phase of design; Aesthetics. Elliot regards this phase as ‘the fun part of design’ and that definitely comes through while reading this chapter. He takes the time to discuss some basics as far as design principles and color theory go, and ties that in with a few more technical details integrated with Web design. A few pages are devoted to the grid, which is, in my opinion, an essential ingredient of successful Web design. Elliot touches on a number of important aspect of aesthetics in Web design including contrast, consistency, volume, depth, pattern and texture. Imagery, illustration, and iconography are also discussed in applicable detail and Elliot saved the best for last, one of my favorite topics; type. The remaining pages of this chapter apply everything just covered to the existing pseudo project we’ve been “working on” throughout the book. Many images are provided as reference, visualizing exactly the changes made to comps with each iteration.

Chapter 6: Deliverables focuses entirely on comp preparation concerning longevity and maintenance. Elliot shares how he organizes his Photoshop files, and walks through the front end development of the project website, giving a few of his personal tips along the way. Some details are discussed which apply only to Web design, and there’s something for everyone to learn.

Recommended?

I’m a fan of SitePoint. As a company, they put out a quality product, paying attention to publishing authors with a known credibility and for good reason. As with all SitePoint books, I am a big fan of Sexy Web Design by Elliot Jay Stocks, and I would absolutely recommend it to any Web designer, no matter what his or her skill level. Just reading the book is inspiration to sit down and create something. There is definitely quite a bit of information to be learned from this book, and I’m sure even the veterans can pick up at least a pointer or two.

On top of that, SitePoint books are put together extremely well. They’re printed in full color, and the visualizations used in this book are exceptionally supportive. I’m not sure if it was intentional, but more times than not, the images referenced by Elliot fell on the next page. While that may prove to be irritating to some people, by the end of the book I had embraced it because it allowed me to retain focus on the words I was reading instead of glancing back and forth at the imagery. I would absolutely recommend this book to just about anyone with an interest in Web design.

If you’re interested, SitePoint is offering some sample content straight from the book.

Book Giveaway

I’m going to try something a bit different with this book review. At random, I’m going to choose one person from the comment thread below at random, and mail them my copy of Sexy Web Design. If you’d like to enter your name in the drawing, simply leave a comment below and one week from today, April 6, 2009, I will pick a winner and contact you for your shipping information. You can comment more than once, but I’ll remove any duplicates prior to getting a random name from the thread.