I’ve been thinking a lot about browser compatibility as I’ve been working on Today’s Meet. My CSS is valid, but it doesn’t work quite right in IE6. The interface is completely JavaScript-based, and will only become moreso in the future. How much time should I put into making it all work with IE6?

None.

I know lots of people, usually in government offices or schools, who are stuck with IE6. For some reason, their IT departments have neglected to update their systems for over two years.

(Sure, some of these systems are running Windows 2000. This is a real minority at this point, though, and the rest have no excuse. If you’re running Windows 2000, and absolutely cannot afford to get new systems, get Firefox.)

I used to think I needed to support IE6 because this group is frighteningly large. But now I’ve come to realize—especially in the wake of this week’s news—that by supporting IE6, all I’m really doing is enabling these lazy IT departments to keep running dangerously out-of-date software.

IE6 is the Vicodin to lazy IT’s Dr. House. As developers we’re Drs. Wilson and Cuddy. Just keep handing it out.

How up-to-date is the rest of the software on a system that (apparently) hasn’t run Windows Update in 2 years? What other major security holes, accessibility issues, and compatibility problems would be solved by updating?

Not only is supporting IE6 annoying, it enables people to run software that is out-of-date and easily exploited. Are we really helping users, or are we just helping them get hacked?

So from now on, no more.

My personal projects will no longer support IE6. I won’t test in IE6.

IE7, Firefox 3, Safari 3, provisionally Opera (really, if it works in the first 3, it should work in Opera).  Keep your software up-to-date.

If you’re still using IE6, go get 7. (Then don’t use it until after the Windows Update patch.)

If you can’t run updates, but can install software, go get Firefox.

If you can’t do any of that, tell your IT department that running software 2 years out of date is unacceptable. Tell your boss to tell them. It’s a performance/security/accessibility/compatibility/etc issue.

And if you’re a developer, stop and think. Are you actually doing your visitors any good by supporting IE6? Or should you take all the time and effort you put into backwards compatibility and put it someplace more valuable?

Chrome certainly looks like a modern browser, with tabs along the top and an address bar and a “Most visited” home screen, it will seem familiar to anyone who’s moved past Internet Explorer 6.

And yet, my Twittersphere has been full of comments like “Nice, but not nice enough to make me drop Firefox/Safari.”

While there are some visual improvements, such as an extremely small “chrome” (the parts of the browser around the page area) footprint, the big changes are “under the hood.” Chrome is built for tabs—each tab is an isolated process; no one tab can take down the whole browser—and is built for JavaScript-heavy “web 2.0″ apps—Chrome’s new V8 JavaScript engine executes a full order of magnitude faster than the current browsers, in my experience.

And all of those “under the hood” changes are open source.

Chrome is not a browser.

Chrome is Google’s way of making a point: modern web browsers have not kept up with the web itself.

More and more, the web is becoming an interactive application, and most browsers are not built for it. They display pages, and running applications is an afterthought. While we’ve seen huge improvements in JavaScript execution in the past few years, speed is still a limitation for developers. Applications are also much more likely to crash than static pages (go ahead, just try to crash a browser with just malformed HTML) and isolating tabs will give necessary boosts to speed, stability, and security.

Kris Abel of CTV.ca said it best: “Google’s entire business takes place throughout the internet itself and so they see their interests served regardless of which company takes web browsing to the next level, in fact they see their interests served if all companies do exactly that.”

I’m not switching to Chrome. I doubt very many people will find it useful as a primary browser. I don’t expect many user-interface improvements, like Firefox’s vast add-on library or the accessibility features of Firefox 3, Opera or IE8.

I do expect any future version to have more “under the hood” improvements, and I hope that the makers of Firefox, Opera, Internet Explorer, and any new browsers that spring from this, will re-evaluate their own products and move in this direction.

Because when the browsers get better, the web gets better.

Some themes waste kilobytes of HTML source on something that could be achieved with 75% less markup. Some use blatantly non-compliant code. Almost none use semantic names.

But what really irks me—I’ll cop to using meaningless code to make it look good—is the style of CSS that seems to be spreading: breaking up definitions into a half-dozen chunks, no line breaks, lack of organization. I think their heart is in the right place (a section for colors, so don’t have to worry about layout; a section for typography, so the precious padding is protected) but the result is a horrid mess.

I blame Michael Heilemann, the designer behind the bland and semantic-free default WordPress theme. I imagine theme developers, many just starting with HTML and CSS, started by looking at his code, and thought that was the way to do it. Then it spread like a virus.

Here’s an example from “Autumn Concept 1.0″:

#topbar {background-color: #4b7c44;}
#footer {background-color: #4b7c44;}
#mainpicinner {height: 250px; background: «
  url(images/mainpic01.jpg) top left «
  no-repeat #fff; border: 1px solid #fff;}
/* typography */
#logo a {color: #3a4032;}
.textbkg {border-left: 4px solid #ebf0cf;}

(« is an inserted linebreak.)

Wow. Line breaks? Readability? Was this passed through a bad version of JSMin?

This is from the “Color Scheme” section, but the first directive for #mainpicinner is height. It also has a border, not just border-color but the whole thing. What’s the point of having sections if you proceed to ignore them immediately?

The rest is filled with classes like cols01 and box01 (while there are other cols##, there is no box02).

But that isn’t my real problem. My real problem is about 20 lines further down:

body {position: relative; background: #1f1f1f; «
  font: 70% Verdana, Arial, Helvetica, «
  sans-serif; text-align: center; letter-spacing: 0;}
#container {float: left; display: block; width: 100%;}
#topbar {float: left; display: block; width: «
  100%; background-image: url(images/topbar.png); «
  background-position: top; background-repeat: «
  repeat-x; text-align: left; padding: 13px 0 6px 0;}
#topbar div {padding-bottom: 0;}

#container is back. (As are backgrounds. Pick a spot, already!)

This kind of CSS is hard to read, hard to maintain, and hard to customize. Even if the initial version is perfect—which doesn’t exist—things will start to break as soon as someone opens the file. Even in this published style sheet, the author couldn’t decide if background images and borders belonged in “Color Scheme” or “General Styles.” What chance does a maintainer have?

I am, admittedly, obsessively strict with my style sheets. I like to make very sure that every style affects only what I intend it to affect. But I never let the styles for one element single get broken into two places. Instead, what I try to do is keep similar styles in a similar order inside those blocks:

blockquote.dropquote {
  float: right;  font-family: Arial, «
    Helvetica, sans-serif;
  font-size: 130%;

color: #662020;
  background-color: #ddd;
}

div.login {
  position: absolute;
  top: 0;
  left: 0;

  font-size: 80%;

  color: #fff;
}

Get the idea? Within each selector, I try to keep things in the same order. I almost always keep positioning styles first and then do either typography or color. To me, this is much more readable and maintainable. If my header div is 3 pixels too wide, I don’t have to comb through all the #header sections. I go to one place and fix it.

I like to extract the CSS order from the document order. This doesn’t necessarily stay complete or strict, especially when you have classes that can be used anywhere or you’re controlling tags directly. The header styles do come before the content styles, though, which come before the footer styles. That just makes sense.

Am I the only one who can’t stand this “style” of CSS? Do you use it? Why?

Elements and Outline

My first step is usually to create an un-styled outline of a “typical” page. I fire up my editor, fill in the basic XHTML, and then go to work inside the <body> tag.

Most sites have this fairly common structure: header, content, footer. And just for fun, let’s throw in navigation between the header and the content. It’s pretty easy to represent this in XHTML:

<div id="header">
</div>

<div id="navigation">
</div>

<div id="content">
</div>

<div id="footer">
</div>

This is my first skeleton for >90% of the sites I design. It’s a very standard document. Sometimes navigation will be inside the header, but most often it goes like this.

Now you have to start thinking about what elements will be on the page. On this site, a blog, I used “articles” instead of “content” for the main div. I also added two side bars, and I knew that inside the articles div I’d want, well, articles.

<div id="header">
  <h1>Page Title</h1>
</div>

<div id="navigation">
  <ul>
    <li>Link 1</li>
    <li>Link 2</li>
  </ul>
</div>

<div id="articles">
  <h2>Recent Articles</h2>
  <div class="article">
    <h3>Article Title</h3>
  </div>
</div>

<div id="theblog">
  <h2>Sidebar heading</h2>
  <p>Sidebar paragraph</p>
</div>

<div id="theworld">
  <h2>Sidebar heading</h2>
  <ul>
    <li>Sidebar</li>
    <li>list</li>
  </ul>
</div>

<div id="footer">
</div>

I won’t bore you with more code examples; I think you get the idea. I make an outline. I know at this point that my source is nice and valid, and that it will make sense when I turn off the stylesheet. I use semantic names for everything.

It’s not very pretty, but I now have a workable XHTML document, with a properly-nested outline, and most of the important elements. Good for me, because now I can start to style them.

Layout and Style

Now, I know what visual elements will need to go on the page. I know what page elements I need to style. Now I’ll start creating a style sheet.

My first style sheet will contain a few basic HTML tags and the elements of my document. I could probably write an XML-to-CSS generator with how strict I am with this step.

Ok, one more code example:

body {}

h1,
h2,
h3,
h4,
h5,
h6 {}

a:link {}
a:visited {}
a:hover {}

#header {}
#header h1 {}

#navigation {}
#navigation ul {}
#navigation ul li {}

#articles {}
#articles h2 {}
#articles div.article {}
#articles div.article h2 {}

#theblog {}
#theblog h2 {}

#theworld {}
#theworld h2 {}
#theworld ul {}
#theworld ul li {}

#footer {}

One of my favorite things about this is it’s almost impossible for a mistake in one section to mess up anything else.

But obviously there’s a lot in there I can combine, can shorten. Almost anything that’s true for #theblog will also be true for #theworld in this case, so DRY, and keep things together as much as you can. But, when you’re just starting the style sheet, this is a good place to start.

As I’m going, I add a lot to the style sheet. I also add a lot to the XHTML template. Pixels get tweaked left and right and I swear at IE6, of course.

Building Templates

Once I have a complete, or near-complete, mock up, it’s time to start building templates for your CMS of choice. This is mostly copy-and-paste work at this point. Your #header and #navigation go into the header template. #footer goes into footer. #content goes in the content template.

See how easy that is?

Then you get to go through and actually add the template mark up. Whether it’s Smarty or PHP or ASP doesn’t really matter, you just replace your dummy text with the right tags.

Starting Out

I love this process, but there is one thing you really need for it to go smoothly:

You need to know what kind of content you’ll have. When you’re redesigning your blog, or building an in-house site, it’s pretty easy to know. When you’re working for a client, you may need to twist some arms to get this information. (I love this A List Apart article for advice on communicating with clients.)

One final thought: use comments. Any time I create a div, I wrap it in comments like this:

<!--begin #articles -->
<div id="articles">
</div>
<!-- end #articles -->

I usually use the CSS selector because it’s specific, so #articles, .article, and so on. These comments—which I left out here to save space—have saved me so much time and effort compared to relying on indentation that I can’t imagine working without them.

I didn’t set out this process as a way to streamline my work, but rather, as I started noticing patterns that worked well, I started thinking about the process. Much like Rails, which was already running Basecamp before it was a framework, I’ve been using more-and-more-polished versions of this work flow for months.

Maybe you’ll find it helpful, maybe not. Maybe you already have a “system” in place. If you do, what is it?

If you want to remain the standard-setting body for the web, promise new recommendations, never deliver.

A decade ago, the W3C was actively working to improve the standards we designers and developers use every day. Sure there were some controversial things (HTML 3.0, XML 1.1) that never caught on, but at least there was discussion, thought, and sometimes even action.

The W3C started work on the CSS3 specification the same year they published CSS2—1998. Ten years later, CSS2.1 is still not technically a published recommendation.

Between 1995, when the W3C was founded, and 1999, HTML went from version 2, an RFC, to version 4.01. Where is 5? In January of this year it became a Working Draft.

When was XHTML last updated? 2001. The DOM? 2004. MathML? 2003.

What happened?

When did “do nothing group” replace “working group” over there? (Probably around 2004.)

I realize that implementing new standards is not trivial. I also realize that standards are crucial to the continued growth of the web—this site is valid XHTML and uses valid CSS.

However, without updates, these “standards” will get old and die. Something else, or someone else, will replace them. We’ve already used CSS2 for a decade. Will we use it for another? (I want my drop shadows! I want my opacity! I want my rounded corners!)

I lead with a quote from Napoleon, so I’ll finish with the French Revolution: Off with their heads. The W3C needs a change in leadership or a vigorous shakedown to get off their asses and do something.

If they’re not willing to put forth the effort, then let them eat cake while someone else does.

This design is a hybrid, pulling elements from some of better-looking sites and blogs. The three-column layout was inspired by Felicia Day’s “Flog” and Problogger, the thin header comes from a post on Chris Brogan’s blog, the heading style is cribbed from The Guardian.

There are two things I learned here that I want to pass along.

Theft is not wrong. Just because a design element exists on another site does not mean you can’t use it. I don’t mean you should steal the entire layout, images and all, or steal code (unless it’s under a free license, then steal away). But if you like the way your favorite blog does headings, there’s no shame in modeling your headings the same way.

Unfinished is wrong. I regret leaving the blog unfinished for so long. I would have been better served by using the Kubrick theme until I was really ready to switch. If you’re starting a blog and want to get to writing right away, go ahead and use some free templates. It’s much better than starting a theme and leaving it unfinished.

A corollary to that is “while incremental changes are fine in testing, only big, complete changes are OK in production.” In other words, don’t edit your live site, except small tweaks and bug fixes. When you upload new templates they should be tested and ready to deploy.

That being said, there are a few small things that aren’t quite finished. I need to write a short paragraph about myself and decide if I want to add a Problogger-/Chris Brogan-style link to the feed right at the top.

Well, what do you think?

Obviously, this is good news for all forward-looking, standards-aware, progressively-enhancing developers out there.

But even more important is the action from Microsoft: the community voiced an opinion and Microsoft listened and responded. To see any major corporation rethink their position because of community pressure is rare enough, but to see a complete reversal is truly an occasion to celebrate.

Hopefully this is indicative of a new attitude at Microsoft, one that supports or even embraces standards and the goals of progressive enhancement.

Now that we’ve seen what community outrage can do, we should turn our attention to the closed platforms of the iPhone and PSP. It’s a long shot but we can try!

The key issue is the default behavior: if I never change my server configuration or every page on my site, they will “forever” be locked in IE7 mode. This is a blow to the heart of the idea of progressive enhancement, or even graceful degradation, and will certainly not encourage developers to make their sites IE8—and thus Acid2—compatible.

Why worry about learning the rules when you have a broken version “forever?”

And what of this “forever?” How long can Microsoft reasonably include every previous version of IE in their new releases? Five years? Say to IE 9? 10 years to IE 10 or 11? At that point there will be 5 separate rendering engines, IE 6 and up, embedded in that increasingly large, increasingly slow program.

Of course, there is also the issue of implementation: Microsoft has said unto us that this shall be. If they really want to get on the standards bandwagon, shouldn’t this have been brought to the W3C, at least for advice?

I have a much more radical suggestion they may not like. Microsoft should abandon “Internet Explorer.” Not the product, but the name, and specifically the abbreviation “MSIE” in the browser string.

They’ll also need to dump the window.ActiveXObject class, perhaps replacing it with a window.ActiveXControl or window.AXObject class. These are the most common ways of identifying IE. If IE shows up like any other standards-compliant browser, there should be no problems for older pages.

I tried to find something good to say about this, but I can’t. It’s a bad idea from the bottom up. Unfortunately, we’re stuck with it.

So I will take Microsoft’s built-in cheat—a not-so-tacit admission that this idea is not viable in the long-term—and adjust my server to send IE=edge with every page. That way I get to keep the progressive enhancement that has served me so well.

HTML, of course, was originally written to define the structure of a web page, never it’s design. In essence, HTML was intended to be much like XML today. But, when HTML was created, there were no style-sheets, so HTML was forced to include some design information, like <font> tags and the bgcolor attribute. Developers quickly turned to images, JavaScript, frames, and Flash to make their lives easier, but in the process made everyone else’s life harder.

Images and Flash will both suck bandwidth, so why would you use them to display text or a navigation bar? Save images and Flash for what they’re supposed to be: pictures and animations. Frames reek havoc on text-only browsers and screen-readers (hence the rarely-used <noframes> tag) and have been considered blase web-design for years.

So how can you save bandwidth, insure accessibility, and still get all the effects you want? CSS. Let’s go over a few of the quick-and-easy ways to use CSS to replace the bandwidth-heavy, inaccessible design you’re using now:

1) Frames: Fixed Sidebars
Perhaps the most common use of frames was the sidebar, a window on the left (or right) that contained anything from helpful information to your site’s navigation, appeared on every page, and didn’t scroll with the rest of the site.

If you want to do the same thing, use the CSS “position: fixed” definition. For instance:

#sidebar {
position: fixed;
top: 0;
left: 0;
width: 160px;
height: 100%;
background: #00f;
}

This will make a non-scrolling, 160-pixel wide sidebar on the left of the screen. (You could always use “right” and “bottom,” too.) Now, in your HTML file, create a <div> with the id="sidebar" attribute:

<div id="sidebar">
...all your links go here...
</div>

You can put this anywhere in the HTML source, and it will appear in the correct place. In a good screen-reader, if you put this toward the bottom of the HTML source (for instance, after all the content of the page) then the user would hear the content before having to hear the list of links again.

2) Images: Positioning Text
This is really just poor web-design. Unless it’s desperately important that you use a particular, rare font, you should never use images to display text. If it’s important that the text appear a certain way or in a certain position, make use of the box-model and nested <div>s. For example, let’s say you wanted a 480-pixel wide layout, regardless of the users’ screen resolution, with a right gutter and a title and slogan in the top-left. You might do something like:

#main {
width: 480px;
height: 100%;
margin: 0 auto;
padding: 0;
position: relative;
top:0;
left:0;
}
#gutter {
width: 120px;
height: 100%;
margin: 0;
padding: 0;
border-left: 1px solid #000;
position: absolute;
top: 0;
right: 0;
background: #2c2;
color: #fff;
}
#header {
width: 360px;
margin: 0;
padding: 6px;
position: relative;
top: 0;
left: 0;
font-family: Tahoma, Arial, san-serif;
font-size: 140%;
text-align: center;
}

With the corresponding HTML:

<div id="main">
<div id="gutter">
...gutter code here...
</div>
<div id="header">
<p>Page Title</p>
<p>Page Slogan</p>
</div>
</div>

Which gives something like (borders added to show box model):

Now, of course, with just a little editing of the CSS file (and none of the HTML) you can move the gutter, change the background, change the page width, change the font, and it’s all in text-format, that will display correctly to text-only or visually-impaired browsers, and save huge percentages of bandwidth.

3) Flash: Cool Navigation Bars
This gets a little more complicated. In general, it’s hard to define the box around <a> tags, so you’ll probably want to do something like this:

#nav
{   margin: 4px auto 0 auto;
 position: relative;
 top: 0;
 left: 0;
}
#nav ul
{   display: inline;
 list-style-type: none;
}
#nav li
{   display: inline;
 border: 1px solid #000;
 padding: 2px 4px 0 4px;
 margin: auto 4px 0 4px;
}
#nav li.here
{   border-bottom: 1px solid #FFF;
}
#nav li:HOVER
{   border-bottom: 1px solid #FFF;
 font-weight: bold;
}

Now in each <li> tag you’ll make a link to the page you want. This particular set of code gives you a horizontal list. I use a version of this on my projects page, so you can see it in action. If you remove the display: inline parts, you’ll get the vertical list you need for a column. Of course, the margin, padding, and all the colors can be customized however you want, to make it look right. (I got this from the AListApart article “Taming Lists“, which you should read for more information.)

So there you go…
It’s not all the info you’ll ever need, but it solves three of the most heinous wastes of bandwidth I’ve seen on the web, as well as all the problems people have with accessibility. These methods can both look great, and be completely usable by everyone, something Flash, frames, and images can’t.