CSSnewbie

An Argument Against Faux Absolute Positioning

A week or so ago, Netherlands-based Eric Sol published an article on A List Apart titled “Faux Absolute Positioning,” where he outlines a new system of element positioning that he has developed. Shortly afterwards, a reader wrote to me and asked my opinions on the technique. In the spirit of continuing the fantastic conversations we’ve been having on CSSnewbie recently, I thought I would respond publicly so that others might have the option of offering their opinions as well. But if you haven’t read Eric’s article yet, please do so before responding, so you have the full picture and not just my interpretation of things.

Mr. Sol’s development of the Faux Absolute Positioning technique was born of frustration in trying to use the two dominant positioning techniques: absolute positioning elements, and floating elements. His argument against using absolute positioning for page layout is that it causes any containing elements to collapse (because the element is pulled out of the document flow), which can cause all sorts of problems. This, I will entirely agree with.

However, his argument against using floated elements is that content changes can cause the width of the element to change, which can in turn wreak havoc on float-based layouts. This is partially true. Left to its own devices, for example, a 500 pixel wide column containing a 550 pixel wide image will probably ruin a float-based layout. However, in practice simply applying a rule of “overflow: hidden” to that column would have eliminated any column-resizing problems in nearly all cases, simply cutting off the side of the image when it reached the edge of the column. And considering that using Faux Absolute Positioning relies on an understanding that “the content of the boxes may overlap,” but that “it’s better to risk overlap than risk breaking the whole layout,” I don’t understand what makes using “overflow: hidden” on floated elements so detrimental or different.

But that isn’t my real concern with Eric’s argument for the technique. I’m most concerned with the XHTML structure required to actually implement the technique. As I’ve mentioned before, I’m a bit of a code purist. I believe in using the least amount of code to the greatest effect, and this is especially true when it comes to XHTML. A CSS file can be cached and reused by the browser over an entire website, reducing the strain on a user’s bandwidth. However, each new page a user visits requires them to download an entirely new XHTML page, regardless of how similar that page is to the previous one they visited. In my mind, this is the strongest argument behind switching from presentation-heavy HTML (tables, font tags, etc) to semantic XHTML (and using CSS for presentation) in the first place.

Because of that, I wince when I see the XHTML used to implement the Faux Absolute Positioning technique. Take a look at the sample offered:

<div id="canvas">
  <div class="line">
    <div class="item" id="item1">
      <div class="sap-content">content here</div>
    </div>
  </div>
</div>

Does that structure look strangely familiar? It should – it’s a table, converted into divs. The “canvas” div functions as the table container, while the “line” class of divs acts as rows and the “item” divs behave as table cells. In fact, this technique actually uses an additional div (“sap-content”) inside of each “cell,” bloating the code even further. Compare it to this table-based reimplementation:

<table id="canvas">
  <tr class="line">
    <td class="item" id="item1">
      <div class="sap-content">content here</div>
    </td>
  </tr>
</table>

Now, I understand that there is a semantics argument to be made here. Mr. Sol probably didn’t want to use a table because, semantically speaking, a table should contain tabular data and nothing more. But the problem is, the Faux Absolute Positioning technique simply reimagines tables using divs and classes rather than “tr” and “td” tags.

The real benefit of the technique, Eric states, is that “we can align every item to a predefined position on the grid […] but items still affect the normal flow,” and his insistence on thinking of elements in a page as “cells in [a] grid” is telling: the author really just wants to use a table, but can’t justify it semantically. Thus, he develops a “semantic” alternative that, instead of suffering from non-semantic code, suffers from divitis, classitis, and code bloat instead.

I wrote an article a couple of weeks back on building a calendar using lists instead of tables that ended up sparking a great deal of thoughtful debate of the nature of calendars, the semantic meaning of tables, and the overuse of lists in modern web design. I plan to respond to that debate more fully next week in a separate article, but one point I plan to make then is worth mentioning now: I believe in using semantic code wherever possible, but I also believe in minimizing code wherever possible. One of the (several) reasons I was so intrigued by the possibility of a list-based calendar is that I knew I could create it with less XHTML than a table-based calendar would require, reducing the bandwidth costs of whatever website it was implemented on.

The Faux Absolute Positioning technique, by contrast, requires at least as much XHTML as an equally complex table would require, and may actually require significantly more code because of the additional div inside each “cell.” Depending on the complexity of the site using this technique, we could be talking about 15% greater bandwidth costs on every single page of the website, compared to an identical site using a table for layout. Admittedly, the website could still tout a “table-less” design, at least in the narrowest definition of the phrase. But because of its insistence on rows, columns, and a clearly defined grid, it is at least a table in spirit, and may in fact be more complex and weighty than a table would be in practice. And if a designer is utterly committed to having the rows, columns, and cell-based grid that this technique permits, I would argue that the table tag deserves a second look, if for no other reason that to reduce page size.

At the end of the article, the author does admit that this technique is probably only sufficiently rewarding to be used on rather complex page layouts. But if a site’s layout has reached the level of complexity wherein the only viable options are to use a table to create a grid or reinvent a table to the same end, perhaps it’s the design of the site, and not the code behind the site, that should be reconsidered.

Now, I don’t want to be seen as attacking Mr. Sol’s person or work. I respect the amount of time it must have taken to develop the Faux Absolute Positioning technique and the ingenuity that went into the CSS. My goal here is to simply encourage a debate on the subject. And now that I’ve had my say, I would love to hear what you think about all this.

Great Resources Elsewhere: June 20 to June 26

Great Resources Elsewhere: June 13 to June 19

5 Web Design Books That Have Inspired Me

I learned web development the good old-fashioned way: through peering at the source code of those who came before me and testing out new ideas through trial and error. But that isn’t to say I haven’t ever picked up a book on web design in my decade-plus of web work (good gracious, has it been that long already?). In fact, I’ve read quite a few web-related books in my time, and many of them have inspired me to look at my job in entirely new ways. And in spirit of sharing, here are five of the books that have most inspired me (click the images to get your own copy!).

Designing With Web Standards – Jeffrey Zeldman

Jeffrey Zeldman’s webzine A List Apart was one of the first places where I ever began to grasp the fundamentals of (and the fundamental need for) web standards. Thus, when I heard that Zeldman was going to be coming out with a book on the subject, I could barely wait to get hold of a copy. In fact, I’m currently on my second copy of the book, as I wore out my first copy while working on my Master’s thesis. The book is a treasure trove of information on how to design websites the right way – with standards in mind. Designing With Web Standards is in its second edition now, and while I’ve only ever read the first edition, I’m more than willing to recommend you pick up a copy.

Don’t Make Me Think – Steve Krug

Web usability needn’t be a scary or complicated topic – just pick up a copy of Steve Krug’s Don’t Make Me Think for all the evidence you’ll ever need. If you’re one of those designers who still thinks that usability is a great idea – for those companies that have seven-figure design budgets, that is – then this book can be a real eye-opener. Web usability doesn’t require a million-dollar lab or a fancy-dancy study. It just requires an understanding of how people really use the web. And Krug will set you down that path of understanding. My copy is riddled with bookmarks and notes in the margin – a sign that it has earned its place on my bookshelf.

Information Architecture: Blueprints for the Web – Christina Wodtke

Before I picked up a copy of Christina Wodtke’s book, my web design process looked a little like this: Concept –> Development –> Redevelopment –> Re-redevelopment. Then I saw a copy of Information Architecture in my college’s new media lab, skimmed a few chapters, and liked it enough to pick up a copy of my own. Wodtke’s book was the first real look I got at the process of developing a website the right way – the idea of sitting down and planning out what the customer needed, what the users wanted, and how I would negotiate the path between the two. This is a great read if you’re just starting out on your own.

Bulletproof Web Design – Dan Cederholm

Dan Cederholm’s Bulletproof Web Design is a must-have for any modern web designer. In it Cederholm proves, chapter by chapter, that having a site built using web standards doesn’t mean you have to give up on your site behaving itself properly. His techniques allow you to develop websites that look just as good in IE as they do in Firefox – and in the cases where some functionality simply doesn’t translate from one to the other, how to ensure your website degrades nicely. I have no fewer than eighteen bookmarks stuck throughout this book, and turn to them often when I’m trying to remember precisely how to pull of certain techniques.

The Zen of CSS Design – Dave Shea and Molly E. Holzschlag

Is there really any better resource on the web for learning to push the CSS envelope than the CSS Zen Garden? Well, the book version of the Garden takes those fantastic visual examples and breaks them down, discusses their various techniques, and explains how some of the fancier footwork was accomplished. This book has been a great resource for me over the last couple of years, seeing as how I’m much more of a developer than a designer. Sometimes it helps to be able to analyze the work of others to understand how I might apply such techniques to my own work.

Those of you with an astute eye might have noticed that all five of these books have something in common – they were all published by New Riders. As far as I’m concerned New Riders is the go-to publisher when I’m looking for a new web design book. Their topics are interesting, their writers entertaining, and their quality is always top-notch. And if anyone from New Riders happens to read this, keep me in mind, eh? :)

A Semantic List-Based CSS Calendar

Most calendars on the web these days are built using large, complex tables. And while an argument could possibly be made that stuff in a calendar is a form of tablular data, it seems to me that in most cases a calendar is really just a list of events happening on specific dates. And that makes a table overkill for most situations in my book.

So my goal for this tutorial was this: I wanted to create a list-based calendar that used CSS for its layout, that also had the ability to display notes on specific dates (because a calendar without notes isn’t all that useful, in my mind).

I started out with the XHTML:

<ol id="calendar">
	<li>
		<ul>
			<li>Rent due!</li>
		</ul>
	</li>
	<li></li>
	<li></li>
	<li>
		<ul>
			<li>Vet Appointment at 3pm with Fuzzy.</li>
		</ul>
	</li>
	<li></li>
	...and so on...
</ol>

I tried to keep the XHTML as simple as possible. The entire calendar is just a big ordered list. I used an ordered list because dates on a calendar tend to occur in a pretty specific order every month, so an OL was the semantically correct choice. Also, because ordered lists are numbered by default, an OL saves me from having to manually add the date. Each date is a list item within the ordered list. If a date has a note associated with it, the note is nested within the list item as an unordered list, keeping things semantic.

Next, we start structuring the calendar list:

#calendar {
	margin: 0;
	padding: 0;
	width: 700px;
	border: 2px solid #333;
	background-color: #ddd; }

Specifying the width of the calendar gives us a firm area to work with. I chose 700 pixels just to make it easier on myself – that gives me 100 pixels for every day of the week. You could put any size you wanted in here, or even use a proportional size such as ems if you’d like.

However, I ran into my first snag at this point. I knew I was going to be floating the list items, which would effectively collapse my calendar OL – the contained LIs wouldn’t be taking up any space. Originally, I got around this problem by specifying a height on the calendar, but that isn’t ideal, because not all months have the same number of weeks. So to improve the flexibility of the calendar, I added an unsemantic div to the end:

.clear {
	clear: both; }

Next up, I created the basic layout for the individual calendar dates:

#calendar li {
	list-style-position: inside;
	font-weight: bold;
	width: 88px;
	height: 88px;
	border: 1px solid #999;
	float: left;
	background-color: #fff;
	padding: 5px;
	overflow: hidden; }

The list-style-position property moves the list item’s number to the inside of our box. Then, all I have to do is specify a size (88px for content, plus 5px padding and 1px border on all sides = 100-by-100 pixel box) on our elements and float the elements left. Now, exactly seven list items fit in every row. To ensure our notes don’t interfere with our calendar’s layout, I’ve set the overflow of the list item to “hidden.”

We’ve gotten our dates to line up in a row, but there’s still one problem: not all months start on the first day of the week. So how do we get the first day to where it’s supposed to be? For that, I set up seven special classes:

#calendar li.sunday {
	margin-left: 0; }
#calendar li.monday {
	margin-left: 100px; }
#calendar li.tuesday {
	margin-left: 200px; }
#calendar li.wednesday {
	margin-left: 300px; }
#calendar li.thursday {
	margin-left: 400px; }
#calendar li.friday {
	margin-left: 500px; }
#calendar li.saturday {
	margin-left: 600px; }

One of these classes gets applied to the first day of every month, which pushes the day into the proper column. The rest of the dates automatically wrap around the first one, so only one class is needed to get our columns squared away:

<ol id="calendar">
	<li class="monday">
		<ul>
			<li>Rent due!</li>
		</ul>
	</li>

Now that our calendar is aligned properly, we can focus on styling the notes that make our calendar really useful:

#calendar li ul {
	margin: 0;
	padding: 0;
	clear: both; }
#calendar li ul li {
	list-style: none;
	font-weight: normal;
	float: none;
	border: none;
	padding: 5px 0;
	margin: 0; }

Most of this is pretty simple stuff: we’re just removing the margins, padding, and list styles from the unordered list to conserve space, then adding a few styles to the list item to make it look nice.

Of course, there’s still one problem with our notes: because of our “overflow: hidden” rule earlier, longer notes are going to get truncated. It’s a necessary evil to keep our calendar formatted correctly. So to get around that, let’s add a hover state to our notes:

#calendar li:hover ul li, #calendar li.hover ul li {
	position: absolute;
	width: 150px;
	margin-left: -38px;
	height: auto;
	background-color: #8cf;
	border: 1px solid #069;
	padding: 10px;
	z-index: 10; } 

This rule pulls our notes out of the normal document flow (with “position: absolute”), makes them a little wider, and creates a box around them. The automatic height ensures that the box we’ve created is always big enough for our note, and the z-index ensures that the note is on top of our calendar. The negative margin helps center the note over the date it came from.

And you’ll also notice we’ve specified a hover pseudo-class and a hover class above. This is because IE doesn’t respect hover states on anything other than anchors. So to get around that, we borrow our hover class JavaScript from the Easy CSS Dropdown Menus article, which allows us to use hover classes just just as easily as our pseudo-class.

And that’s all it takes to create a semantic, CSS-only calendar! At least, for as far as Firefox and Safari are concerned. Opera and Internet Explorer still present a bit of a problem: neither are displaying the numbers on our ordered list. However, both browsers are displaying the same behavior for different reasons.

Opera’s problem is simple: it doesn’t display the number whenever the list item is blank. So to fix this problem for Opera, all you need to do is fill your empty list items (those without notes) with a non-breaking space ( ).

Internet Explorer’s problem is, as usual, more complicated. IE is ignoring our “list-style-position: inside” rule from earlier and is displaying the list numbers to the left (outside) of our date box… rendering them essentially invisible. It’s a hasLayout problem, and you can read more about that here if you’d like. Unfortunately, I haven’t been able to find a real fix for this problem yet. The only viable alternative that I can find would be to include the date inside the list item (<1>, <2>, and so on), and apply a “list-style: none;” rule to the ordered list. I don’t like this solution as much, because it’s not making effective use of the ordered list, but if you need your calendar to work in IE, this is probably the best alternative.

And that’s that. You can see this calendar in action here. Let me know if you have any suggestions for workarounds on that IE bug!

Update: I’ve responded to a lot of the fantastic comments, concerns, and articles of debate in a separate article. You can read it here.

A Brief Reprieve

Dear Constant Reader,

I apologize for the lack of new articles so far this week. It seems I have what doctors are calling “Strep Throat,” and that’s taking a lot out of me physically and, due to the fever I’m guessing, also mentally. I’m hoping to get back to a regular writing schedule by the end of this week.

In the meantime, I thought I would share a bit of good news. As of late last week, CSSnewbie has over 1,000 RSS feed subscribers! I truly and deeply appreciate all of you who have taken the time to subscribe to my feed and come back week after week. Without you, I’d be just another crazy in the park, shouting at the pigeons about web development. And the world does not need another one of those crazies.

If you aren’t a subscriber yet, please consider becoming one. There are links in the right sidebar, and at the bottom of this post, that would love to take your call. Operators are standing by.

Sincerely,
-Rob

Great Resources Elsewhere: May 30 to June 05

A Default Print Stylesheet Template

A print style sheet is an extremely useful thing to have around. Most modern websites don’t look all that attractive when printed using the site’s default CSS: overly-large widths, screen-friendly fonts, and creative color choices all work together to make most sites less than useful on the printed page. But with a print CSS file, you can alleviate those problems and present your users with a useable, useful print alternative to your digital masterpiece.

There can probably never be a true “boilerplate” print style sheet, something you can just apply to every website you create and be done — believe me, I’ve been trying to develop one for quite some time! However, this tutorial and accompanying downloadable template should help you on your way to building your own personally customized print CSS. And for some sites, it may not require any customization at all!

To start out, we’ll set some default widths, margins, floats, and backgrounds on our major elements:

body, #content, #container {
	width: 100%;
	margin: 0;
	float: none;
	background: #fff url(none);
}

How many times have you printed a website only to find the right third of the page was missing? Setting the width to 100% on these elements ensures they’ll never extend beyond the confines of the printed page. Setting a margin of zero ensures that our content hugs the default page margins – you can add more space here if you’d like. Setting our float to “none” helps get around some old-school print bugs, wherein floated objects weren’t printed beyond the first page. And setting our background to a default white with no image is just good printing karma – why waste your users’ ink on screen-centric niceties?

Next, we’ll remove any elements that aren’t needed on the printed page:

#topnav, #navbar, #nav, #sidebar, .ad, .noprint {
	display: none;
}

Here, I’m suggesting that navigation, sidebars, and ads needn’t be printed. You can add to and remove from this list as your needs require. It also wouldn’t hurt to create a catch-all class (like .noprint) for individual elements you’d rather not be rendered on the printed page.

We should also set some default body font faces, sizes, and colors:

body {
	font: 1em Georgia, "Times New Roman", Times, serif;
	color: #000;
}

I’m setting the font-size here to 1em in order to keep the font size flexible. If you specify a point size (say, 12pt) or a pixel size, users won’t be able to use the “scale” functionality built into most modern browsers, which would make your pages less usable overall.

I’m also specifying a serif font for my print pages. Some argue that you should stick to whatever font you use on the screen for the sake of brand consistency, but I’d argue that you can develop screen brand consistency, and a separate print brand consistency. And if you’d like to interweave the two, consider using a serif font for your screen headlines and a sans-serif font for your body text, then simply reversing the font families on the printed page.

And finally, I’m setting the default text color to black. Your low-contrast design may look killer on the screen (who am I to judge?), but contrast is the name of the game on the page if you want your text to be legible.

Next up, we’ll style our headings:

h1,h2,h3,h4,h5,h6 {
	font-family: Helvetica, Arial, sans-serif;
	color: #000;
}
h1 { font-size: 250%; }
h2 { font-size: 175%; }
h3 { font-size: 135%; }
h4 { font-size: 100%; font-variant: small-caps; }
h5 { font-size: 100%; }
h6 { font-size: 90%; font-style: italic; }

I’m specifying a default font-family as well as a color (black again) for all of my headlines. Then, I’m styling each headline uniquely so that they stand out hierarchically on the printed page. Most websites don’t actually use six levels of headings, so you can change these around and eliminate lines to suit your needs.

And finally, we need to ensure that hyperlinks are usable in print:

a:link, a:visited {
	color: #00c;
	font-weight: bold;
	text-decoration: underline; }
#content a:link:after, #content a:visited:after {
	content: " (" attr(href) ") ";
}

The first set of rules sets our links to be dark blue, so they show up as blue on color printers and a dark grey (but not black) in grayscale. We’ve also made them bold and underlined them to ensure they stand out from the rest of the page.

But what good is highlighting your hyperlinks on the page? It’s not like anyone can follow them, right? Well, that’s mostly true. But by using a little advanced CSS magic, we can make the anchor tags on your page a lot more useful. Using the :after pseudo-class and the content property, we can actually append the achor’s href to our hyperlink text. Now your users will be able to distinguish your links from the rest of your text, and even “follow” them (albeit manually) if they’d like. This trick doesn’t work in Internet Explorer, sadly… but it doesn’t do any harm to have the rule in there for the browsers who can use it.

And there you have it! A default print stylesheet template. If you’d like to download a copy to use, just click here (right-click and save as). Of course, this solution would work a lot better with a bit of customization, so feel free to change it up as you see fit.

Bug Fix: IE Double Margin Float Bug

The double-margin float bug has been a source of irritation for CSS-loving web designers for years. The bug first became a major problem in IE5, when CSS started to become increasingly popular, and persisted through IE6. And, while an easy (if mysterious) fix has been known for quite some time now, it occurs to me that perhaps not everyone knows about it. So I thought it couldn’t hurt to toss another explanation out there.

So what is the double-margin float bug? It’s an Internet Explorer-exclusive bug wherein an element that is floated – and given a margin in the same direction as the float – ends up with twice the specified margin size. In other words, if you were to float an element to the left and give it a 20-pixel left margin, in IE the margin would actually be 40 pixels wide. It only happens when the margin is in the same direction as the float, but it happens to both left and right floats. At least IE is consistent in its inconsistency.

Obviously, this can be a pretty annoying problem. If, for example, you use floats to create columns (as I tend to do), this little bug can throw off your entire layout in Internet Explorer. Let’s say you create a wrapper div 800px wide, and then create two columns inside. You decide to float your columns left to get them next to one another, and then you give your leftmost column a margin to push it away from the edge of the wrapper. Assuming you’ve done your math right, this should work perfectly in every browser but IE. The ol’ blue beast, however, has doubled your left margin and thrown your columns completely out of whack.

Happily, the fix is extremely simple. All you have to do is apply a display: inline rule to your floated element. Seriously: that’s it. So you simply go from something like this:

#content {
	float: left;
	width: 500px;
	padding: 10px 15px;
	margin-left: 20px; }

To something like this:

#content {
	float: left;
	width: 500px;
	padding: 10px 15px;
	margin-left: 20px;
	display: inline; }

And why does a display property fix our margin problem? Really, your guess is as good as mine. In all truthfulness, applying a display property to a float should do exactly nothing (unless it’s display: none, that is). Floats are by definition block-level elements, and cannot become inline elements. And even IE knows this – after you apply this rule all browsers including Internet Explorer will continue to treat your floats like block-level elements. But now IE will also start behaving itself when it comes to your margins.

However, that’s also what makes this fix so nice: you can apply it to your element and not have to worry about what other problems that might cause down the line. Floats can’t be inline elements, so the property does nothing harmful.

As I said previously, this fix has really been around for some time. You can read more about it at Position Is Everything, which also gives a bit of the history of the bug and some of the old-school workarounds web designers used before this little fix was discovered.