Chrome Is Not A Browser

If you somehow haven’t heard of it, Google’s Chrome is a neat, quick, Acid2-compliant “browser” designed to work with web applications, not web pages.

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.

Organizing CSS

Looking at WordPress themes usually makes me cringe. It’s as if there was a memo on semantic markup and the community of WP developers didn’t get it.

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?

Work Pattern: Designing Web Sites

The premise of Design Patterns is that similar problems have similar solutions. In the same vein, I propose this Work Pattern a set of common steps I use when I create a web site, and maybe you can use, too.

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>

An Un-Styled Skeleton

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?

The W3C Sucks

“If you wish to be a success in the world, promise everything, deliver nothing.”

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

The New Blog

I made myself sit down today and finish work on the blog design. I am very happy with how it came out. (more…)