Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

To continue the discussion on the design of this blog, I’m going to take a moment and step onto my soapbox. But first, a brief introduction to the topic at hand.

I think I noticed this whole grid revolution back in December 2006 when Cameron Moll mentioned it in his article Gridding the 960, based on the optimal layout width for a 1024px wide screen. I was interested, and sites designed using a grid seemed pretty sharp, so I added it to ma.gnolia and moved on. A few months later I caught an article on ALA about the baseline grid, a post to 24-ways about vertical rhythm, and after that a nice 7-step guide to creating a grid-based design, and a great piece on incremental leading. Between these five articles, (and about a year’s worth of time) the concept finally clicked in my mind.

Enter the frameworks. Sometime in the last few years a number of CSS frameworks have emerged, including frameworks from giants like Yahoo, and brand-new frameworks like the 960 Grid System. The most popular, as far as blogosphere-based chatter is concerned, is probably Blueprint, which recently released version 0.7, giving you a pretty good idea of how young this technology is. So, with (at least) three frameworks out there you must be saying. “Surely one is a suitable fit for EricDeLabar.com?” That’s exactly incorrect, at least for Blueprint, but not for 960.gs and here is my reason why.

Semantics. Please, put the pitchforks and torches down, I’m not saying that Blueprint and 960.gs are is un-semantic, I’m saying they it could be more semantic. I’m a strong believer in separation of content from presentation, and IMHO, this is the reason why CSS is as amazing as it is. If you’re not 100% sold on this concept, check out Zen Garden and order yourself a copy of Dave Shea and Molly Holzschlag’s book The Zen of CSS Design. For today’s post I’m going to ignore YUI, mainly because it’s too huge for my taste, and concentrate only on Blueprint and 960.gs.

Both Blueprint and 960.gs use HTML class names to specify the width of the grid, these class names are specifically named with the number of columns the content block is supposed to span. This violates the separation of content from presentation because now the HTML contains instructions on how to render the page. That’s it, my two-sentance, semantic-web-purist’s argument against the current batch of CSS frameworks. Can it be fixed? Of course it can! The easiest way to do this is probably with some sort of script-based solution that provides CSS post-processing. Initially I thought of CleverCSS, but then I realized that the newest version of Blueprint already does this! Imagine my surprise when I discovered this wonderful fact a half hour into writing my post! Oh well, I’ve learned something, and the web is a better place, so I’m going to post this anyway, send you over to the details on the Blueprint Compress ruby script on jdclayton.com, and formally state that I stand corrected and I will probably be using Blueprint for this site’s layout.

By my definition of Web 2.0, one of the key requirements for any application is cross-browser compatibility. As a company, my employer defines this as IE 6+, Firefox 2+, and Safari 3 beta; all tested on Windows. It’s not ideal, but it covers a huge chunk of the market. This stack is pretty easy to test, but occasionally one of the browsers will throw a curve-ball and that’s where a typical the members of my team, or J2EE developers in general, get lost.

When somebody comes across some weird client-side error and they come looking for my help, I start with three questions:

1. Does it validate? (Is it a strict doctype?)
2. Is it in quirks mode?
3. Did you separate content from presentation from behavior?

I think one and two are pretty obvious, if you’re not following the standards the browser can (and will) do what it wants with your page. Follow the rules and your playing field becomes a lot more level. Number three is a design choice that I prefer for keeping things clean; if your layers are separated, you know what behavior is coming from where. What does this mean? It means style is always stored in an external StyleSheet, JavaScript is always stored in an external JS file, and your HTML markup has no inline event handlers, script blocks, or style attributes. Not only does this make things easier to find and debug it also encourages progressive enhancement and accessible design.

Now that you’ve made sure those three cases are taken care of, do you still have the problem? I’d say 50% of the time the problem is solved, for the rest, here’s what I do. (First things first, make sure your toolbox is in order.)

For debugging CSS, use Firebug’s Inspect tool to make sure the correct CSS rules are applying to your element, this will show you which rules are applying and more importantly, which one is winning in the case of a conflict. If the problem is not showing up in Firefox, I’m guessing it also works in Safari, so it has be an IE issue. Check your floats, check your widths, and make sure you’re not relying on anything IE doesn’t support, like min-height or max-height. If you’re still not sure what’s going on, checkout the Microsoft Developer Toolbar. To get it, go to Microsoft.com and search for “Developer Toolbar,” I’d post a link, but every time I try bookmarking the page it moves, so it’s probably just easier to search for it. The Developer Toolbar works similarly to Firebug, but is definitely lacking. If your problem is in Safari, get a copy of the Webkit Nightly and enable the Web Inspector. It’s definitely better than the IE Developer Toolbar, but still not Firebug. In a pinch, try out the WestCiv XRAY and MRI bookmarklets which are easy enough to install and uninstall on a workstation that is not your own.

If you’re debugging JavaScript, the Firebug console is definitely the way to go for tracing, and you can even make it work on other browsers with their handy JavaScript-based utility. For IE specific errors you can try your luck with the Microsoft Script Debugger (again, search for it), but I find it to be a little bloated. At the time of this writing Webkit offers its own debugger in the form of Drosera, but it’s Mac-only, so unless you’ve got one you’re out of luck there. Finally, you can try out Aptana Studio which offers JavaScript debugging in Firefox (also in IE if you’re willing to pay for it), but I haven’t had a chance to really give it a test drive and at initial glance it seems a little clunky when working with J2EE.

There’s a ton of tools out there for debugging client-side problems, and with a little practice you’ll be debugging like a pro in no time at all. But please, remember one thing, the best offense is a good defense, separate your layers, avoid CSS hacks, and do things the right way the first time.

While there’s no substitute for learning something by first making all of the mistakes, it doesn’t hurt to learn from somebody else’s. In today’s issue, we’re going to talk about absolute positioning.

absolute
The element’s box is laid out in relation to its containing block, and is entirely removed from the normal flow of the document. The containing block of the absolutely positioned element is the nearest ancestor element with a position other than static. If no such ancestor exists, then the containing block is the root element of the document.

Eric A. Meyer. Cascading Style Sheets 2.0 Programmer’s Reference. California: Osborne/McGraw-Hill, 2001.

In truth, the solution was in front of my face the entire time, I just never understood it! (Or possibly I just skimmed the paragraph and only read the first sentence, but that’s a different issue altogether!) The problem I was seeing was that my absolutely positioned (position: absolute; top: 0; left: 0;) element was appearing in the upper left of the viewport, not the upper left of its containing element.

The simple solution was just to set the position property of my containing element to relative. This is a valid solution because a relatively positioned element behaves exactly like a statically positioned element, except that the position properties (top, right, bottom, and left) are used to offset the element by the specified amount. So, as long as the position properties are left with their default values, to make a container element, all you need is position: relative.

Alright, in the beginning there wasn’t DOCTYPE, it didn’t come along until about the time XHTML was released; however, if you want to do the Web 2.0 thing right, it helps to start on a solid base.

My goal here is to get a brand-new HTML document up and running as a good base for designing a Web 2.0 application. Today, we’ll look at the parts of a document that the typical user doesn’t actually see, but play a huge role in how a user finds your site and how it’s actually rendered on their screen.

First things first; make your DOCTYPE the first line of the file. That’s right, line number one, no XML definition, no spaces, no server-side code, the first line of the file. This ensures that you don’t end up in quirks mode accidentally. Now, as far as DOCTYPE’s go, I really only see two options, HTML 4.01 Strict and XHTML 1.0 Strict. There are theoretically valid arguments for not using XHTML, most of which have to do with the simple fact that most web servers don’t serve it as XML and most browsers don’t read it as XML, but that’s a different article for a different day. Today, we’re using XHTML 1.0 Strict because the client insists that we use the latest technology regardless of whether or not it’s appropriate; so this is what the DOCTYPE definition for XHTML 1.0 Strict looks like:

1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Remember, that’s the very first line of your file!

Next, let’s get the basic xhtml in there:

1
2
3
4
5
6
7
8
9
10

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
 <head>
  <meta http-equiv="Content-Type"
        content="text/html; charset=UTF-8"/>
 </head>
 <body>
 ...
 </body>
</html>

Next, let’s get some very basic SEO framework in there and add some meta elements. Meta elements are sometimes called meta tags, but since we’re working in an XHTML document we’ll use the XML terminology. We’ll use description and keywords, and throw author in the for good taste.

5
6
7

<meta name="keywords" content="page, site, title, keyword, doctype"/>
<meta name="author" content="Eric DeLabar"/>
<meta name="description" content="A short description of the page content."/>

Great, now there’s a place for keywords and a description, but why do we need them? Keywords are old-school, I don’t even know if modern crawlers still look at them, but I do know that like all meta elements they should be specific for the page you’re writing them for. So, as a means of guiding my SEO, I usually choose the 5-10 keywords that I want to apply to my current page, then make sure that as I’m writing the page copy I use those keywords.

The description meta element is slightly different, because it’s visibly used. It is displayed by some search engines as a description of your page when it occurs as a result. As a guide to writing a description, keep it short, around 128-256 characters. Keep in mind that if it’s too long it will most likely by truncated, so just write a sentence describing the current page.

Now, we’ll have a look at the page title:

8

<title> Descriptive Page Title - EricDeLabar.com</title>

Like the meta description, the title element is displayed as part of a search result list, so a descriptive title can be very helpful for drawing users into your site. Some SEO experts also believe that keywords in your title are more heavily weighted in search rankings. Keep the title shorter than your description, and maybe consider including your branding at the end. I like the branding at the end because if it does get truncated by the search engine more of my more important descriptive title is displayed.

Finally, let’s add the stylesheets:

9
10
11
12

<link rel="stylesheet" type="text/css" href="/style/screen.css" media="screen"/>
<!-- [if lte IE 6]>
  <link rel="stylesheet" type="text/css" href="/style/iefix_screen.css" media="screen"/>
<![endif]-->

Now I’m a bit of a purist, and I’ll have a later post describing my process for styling a page, but notice for now, I usually have a minimum of two stylesheets. The first being a clean stylesheet (as in NO Hacks/Filters/Whatever you like to call them) that handles all of the (mostly) standards complaint browsers, then an Internet Explorer conditional comment for handling older versions of IE. In this case, my iefix stylesheet is for lte IE 6 which translates to Less than or equal to Internet Explorer 6. Notice that the iefix stylesheet comes after the other stylesheet(s), this is so that any rules in the iefix stylesheet with equal or greater CSS specificity will overwrite the rules in the standard stylesheet. (More on specificity in a later post.)

That’s it! Congratulations, you have a nice, clean base to start your web 2.0 website on! If you’re curious, the finished product looks something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
 <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
  <meta name="keywords" content="page, site, title, keyword, doctype"/>
  <meta name="author" content="Eric DeLabar"/>
  <meta name="description" content="A short description of the page content."/>
  <title>Descriptive Page Title - EricDeLabar.com</title>
  <link rel="stylesheet" type="text/css" href="/style/screen.css" media="screen"/>
  <!--[if lte IE 6]>
    <link rel="stylesheet" type="text/css" href="/style/iefix_screen.css" media="screen"/>
  <![endif]-->
 </head>
 <body>
 ...
 </body>
</html>