I’m now advocating to my clients (and to you), that where feasible, not to waste hours in time and a client’s money on lengthy workarounds in an unnecessary attempt at cross-browser perfection. Instead, you and I should provide simple but effectively designed HTML elements. This means just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.

This will work well for content-focused web sites. And then maybe it’s officially time to completely drop support of IE6 for web apps. link

… this is why the old “only use tables for layout” argument keeps coming up over and over: strip away the overheated rhetoric and obvious link-baiting, and you find the core of a real need. Because as powerful as CSS can be, table cells do certain things very easily that CSS makes very, very hard. Cells stretch vertically, keeping equal heights as a matter of their intrinsic nature. They stay out of each others’ way, while still being allowed to sit next to each other and use any sizing dimensions. They tie their layout to their parent elements, and vice versa. 

link

I thought it would be interesting to provide a portion of the background on our buttons here, and discuss some of the iterations we’ve been through so far to get to the current state.

Background

Today’s web apps allow increasingly complex interactions. Users can view, create, manage, and manipulate all kinds of data, from email messages to feeds to photos to blog posts, or even choosing what their DVR records on any given night. We’re at the point where these apps need something beyond standard HTML form controls and basic hypertext links to represent the actions a user can take.

A basic <input type="submit"> could be used for single actions, a <select> element could be used for a compact menu of actions, and <input type="radio"> could be used for selecting mutually exclusive options. But we’re left with no way to represent other interactions common in desktop apps. Such as a checkbox that represents more than just on or off. Or the use of auto-complete to refine or narrow the options in a drop-down menu. On top of this, the controls we can render have significantly different appearances across browsers and platforms. Even within a single browser, buttons and select menus have quite different designs.

Enter: the concept of custom buttons.

The first iteration

Not long after I started at Google, I remember seeing mockups for a new product that eventually become Google Spreadsheets. The mockups I saw used simple buttons that looked similar to default HTML buttons in certain browsers. But they were subtly different than any default buttons I had ever seen before. The giveaway was seeing three buttons sandwiched together to make a pill button:

At first, I thought they were just generic browser-agnostic representations — and wishful thinking for the appearance — of actual HTML buttons. But once we started using an internal-only version of the product, I realized this button design actually got built into the product. That was fine. But I cringed when I realized how the buttons had been implemented. Each button was set up with a nine-cell table so they could place each corner image, and still allow the button to expand in all four directions according to the width and height of the text inside:

Eliminating the table and corner images

I knew there had to be a better way to render these buttons than using tables, and especially nine-cell tables just for the tiny little corners. So I tried creating a few prototypes to improve our button code. My first button attempt, which I named Custom Buttons 2.0, (version 1.0 would be the nine-cell tabled version done by one of our engineers) used a similar trick that I used for event chips in Google Calendar: the top border was one element with 1px left and right margins, the middle of the button was another element with left and right borders, and the bottom border recycled the styles of the top border with 1px left and right margins. This created a one-pixel notch in each of the four corners, giving the subtle illusion of a small rounded corner.

That 2.0 attempt was fine, and worked pretty well (as I expected) in almost all browsers. But it required that each button as a whole either be floated or positioned absolutely with a width. I wanted a set of buttons that could be treated as inline elements, and that would take up as much horizontal space as the text inside each button needed.

Going inline

My 3.0 attempt relied on treating the buttons and everything inside them as inline elements. The top/bottom borders still needed to be rendered separately from the left/right borders to get 1px-notched corners. The left/right borders were rendered on the outer element. The top/bottom borders were rendered on the inner element. Because borders don’t compound and add to the width or height of an inline element, we get the 1px notches in each corner. I ran into a lot of frustration with this inline approach until I remembered display: inline-block. That seemed to solve everything at once.

A demo page for Custom Buttons 3.0 shows my progress to this point. As you can see there, I built in affordances for changing the border color on hover, and for reversing the gradient direction for the active/click state to make it feel like the button is actually pressable. I also attempted to show how we could sandwich multiple buttons together to form a pill button. The pill button wasn’t perfect — I didn’t want gaps in the top/bottom borders between each button. But it was a start.

The magical inline-block solved everything, except in IE. That’s where the genius of Google engineers came in. They knew how to get tricks working in all browsers, and this technique interested a couple of them enough that they dedicated the time to make it work.

So 3.0 buttons were fine. After some modifications by our engineers, they made it into live production code. I believe 3.0 buttons are currently still in use for edit buttons in Google Sites, and in editor modes for Google Docs. (As of this writing. Expect those to change in the near future to buttons described below.) But I was still bothered by the requirement of a background gradient image. Not only was this an extra request to the server, but if anyone wanted to change the colors of a button, they’d be required to create a new gradient image. This wasn’t flexible enough, in my opinion, and I thought we could push further.

Eliminating the gradient image

Instead of rendering the gradient with an image, I thought we might be able to simulate a gradient with a few bands of color. With a few light grays laid beside each other that were close enough in value, we’d get something that looked like a gradient. With only two bands of color, I got a glossy-looking button with a sharp division between the two bands of color. Not what I wanted. Adding a third band of color between the first two colors blended each color together better. So three color bands it had to be.

To get that band of color and fake the gradient, I had to insert one more element in the button code. I chose <b> because it was short, and semantically, it didn’t mean anything. That element was absolutely positioned, so it could live inside the button and behind the text without affecting anything else. For the button itself, I used the almost-white #f9f9f9. For the <b> element I used #e3e3e3. The <b> element was absolutely positioned to the bottom of the button, and given a height of 40%. To get the middle band of color, I added a top border of #eee to the <b> element.

Another demo page for Custom Buttons 3.1 shows my attempt at getting this pseudo-gradient to work. It works in Firefox and Safari, and probably a few other modern browsers. But not everywhere. It was never perfect, and I don’t recommend using it in production code. Again, I couldn’t get this working right in IE. Google eng to the rescue again. To see the final code we ended up using in Gmail and Reader, you’ll have to reverse engineer the button code in one of those products.

Sweating the details

If we were going to undertake the task of recreating basic HTML form controls, we knew there were a lot of details that need to be accounted for and thought through. Like all the possible states of a button: resting, hover, focus, active, toggled-on, and disabled. There are also the accessibility ramifications of creating non-standard controls. I’m sure we haven’t factored in or solved every access issue yet. But engineers are working on that. Here’s a glimpse of the many states and types of buttons, along with the visual specs we had to think about and create if we were really going to replace default buttons and menus:

Major credit

I certainly didn’t create the concept of custom buttons at Google. Nor did I write the final code that made it into production. I merely initiated a couple steps to improve the methods we use to render custom buttons. My portion of the iteration is what’s documented here. There were many other steps in making these buttons a reality.

These buttons never would have made it into production code without the help of several Google engineers. One of the primary aids, Emil Eklund, helped fix a lot of my code for these custom buttons, and got it working in the browsers Gmail supports. He just posted an entry on the Official Gmail Blog yesterday about the label and folder-like functionality behind the new buttons in Gmail. Two developers (no longer at Google) also contributed heavily to the original button code: Ryan Carver and Greg Veen. They deserve huge props too.

Even more credit for the launch of these buttons in Gmail goes to one of the Gmail designers, Michael Leggett, who dreamed up all the fancy new functionality and interactions behind applying labels. Michael gave me lots of feedback and suggestions as we were building the original specs for 3.0 and 3.1 buttons. He also created countless iterations of the button interactions for Gmail, and endured numerous reviews and feedback cycles to finally get them launched in the product. If you like the new labeling menus in Gmail, Michael is the one to thank. The menus are especially slick if you use the new v and l keyboard shortcuts, along with auto-complete to apply labels (and even archive at the same time) without ever touching your mouse.

There are numerous other designers, developers, and engineers at Google who touched these buttons at one point or another. They all deserve credit too. I’ve only given props to four of the most prolific people who made these buttons a reality.

These buttons don’t permeate the entire Gmail or Reader interfaces yet for all browsers. (e.g. Compose view is still using default buttons for older WebKit browsers.) But now that these buttons are reusable components, expect to see us using them in more places throughout Google as we find good uses for them.

Permanent link to the working version of this design.

When I published that article last year, the words and advice contained within were welcomed warmly by large numbers of people. The article was translated into at least eight different languages, and continues to be referenced in other writings and in academic curricula. On the flip side, the same article was also the cause of flaming, accusations of ignorance, and general vitriol thrown my way, claiming I was over-hyping CSS and deceiving the multitudes of its capabilities. Those claims were voiced more loudly when readers couldn’t find any proving example code whatsoever. Those who refused to let go of their old ways assumed that I fabricated the entire case study.

I still stand behind that article. And I promise the example code is real, and still resides in the same location where it has been for the past year. You just had to know where to look for it.

I intentionally omitted any links or references to my working code examples in that article because the point was not to get hung up on details or to demonstrate the methods used. I wanted to step back and look at the overall picture. After experience with recoding Yahoo Search, I no longer believe in reworking (in CSS) some other organization’s site, then publicly rubbing anyone’s nose in it by posting the code for all to see. I wasn’t trying to target Microsoft for bad CSS support in IE, nor make a fool of its home page code. Rather, last year’s home page of Microsoft.com was chosen as an example because it was a high-profile representation of a very common design model used on thousands of sites: header across the top, three columns of content, and footer across the bottom. If a site doesn’t use a three-column content model, it may simplify the same model down to two columns:

I gave this presentation for the first time in Seattle, right around the corner from Redmond. So I thought the selection of reworking Microsoft would turn a few more heads. Those who attended my talk at Digital Design World had full access to the Microsoft example code during and after my presentation. It was never hidden from them, because it was used as a tool to aid in learning the methods and benefits of tableless design.

In an odd bundle of circumstances, Microsoft ended up redesigning its home page just one month after my Seattle presentation, significantly reducing the file size of its code. The design was simplified and the amount of text on the page was significantly reduced as well, so this wasn’t solely a reduction due to leaner code. However, all spacer gifs seem to be gone from the markup, and only eight tables remain in the current version, so that points to progress from last year’s 40-table version.

Fast-forward to today

Now that a full year has passed since the article was published, and because Microsoft no longer uses the design I made an example, I also moved on and now use another design for my tableless presentations. Because of these factors, it now seems appropriate to share more broadly the final example code I used, and the full set of slides I used during my Seattle presentation to cover the reworking of Microsoft.com.

• Example code: 2004 Microsoft home page using CSS
• Seattle presentation: No More Tables

The portion covering the recoding of Microsoft.com doesn’t start until somewhere around page 32 of the presentation. Once the presentation gets to Step #3, small links at the bottom of the page point to in-progress files representing the work done up to that step.

By sharing even more information surrounding this case study, I hope having everything in context to this case study helps enlighten others to the means and the power in using CSS to implement and control layout and all other details of design.

In reality, there are many more people who aren’t blind but experience some form of vision loss or impairment. These people would never have need for a screen reader, and wouldn’t necessarily benefit from the typical measures we’ve taken to ensure our pages are accessible to blind people.

To some extent, we’ve been ignoring this large group of low-vision users, assuming their browser controls for resizing text are enough to enable reading of our pages. Or that their own screen magnification software does the job well enough, so we don’t need to bother.

Some designs I’ve seen easily handle quite a few bumps up in text size. Others start to fall apart more quickly than they should because of narrow, fixed-width columns. Many of you probably know how difficult it is to read text when you’re forced to scroll both vertically and horizontally. This can parallel the experience of using a screen magnifier to read most multi-column pages.

Enter the Zoom layout

Another means of giving your visitors control over the content on your website. If a site already takes advantage of CSS for layout, offering a Zoom layout option is trivial.

Case in point: While Joe was giving his presentation in London, I thought, “Implementing a single-column layout with larger sans-serif type isn’t rocket science. Why don’t I already have one? I’ll just create one right now.”

So I opened up my laptop and cranked out a quick style sheet for a Zoom layout. I had it mostly complete by the end of his presentation. I’ll admit that I was already familiar with Joe’s concept, having seen his article, Big, Stark & Chunky, on A List Apart. And I had seen his referenced examples from Cameron Adams and Sergio Villareal. Stopdesign already had a Preferences page for switching styles and font sizes. So I was at a slight advantage when Joe gave us his homework assignment of creating and tweaking our own Zoom layouts.

I’ll save you from any further description of a Zoom layout, and instead, encourage you to read through Joe’s detailed notes from his presentation.

Making it real

Once I got back to the States, I spent time polishing the style sheet I had pulled together in London, and split my work into two versions for Stopdesign’s Zoom layout: a positive version with dark text on a light beige background, and a contrast version using an inverted color scheme of light-color text on a dark blue background.

Zoom (positive)

Zoom2 (contrast/inverted)

Both are available as permanent settings on the Preferences page, which appears as the fourth link at the top of this site for any non-Zoom style. (Those first four links actually exist toward the end of the markup, just before the footer.) Base text size can also be changed to one of four values on the same page.

The heavy lifting for both Zoom layouts is done only once (zoom.css). For the high-contrast/inverted color scheme, the background, text, and border colors are changed via a secondary style sheet (zoom2.css) linked in addition to zoom.css.

Users of browsers other than IE will notice a nice scaling effect on the width of the layout as the text size gets bumped up. The single-column is given a max-width in em values, with no physical width defined. This allows the layout to remain confined to readable line-lengths at smaller text sizes. Yet it also allows the layout to expand as text size is increased. The layout will expand to the width of the browser, then stop expanding, preventing the appearance of any horizontal scrollbars — unlike the new Yahoo!, though nice because its layout expands with the text size, it quickly expands beyond the browser window width as text size increases, necessitating all kinds of scrolling.

A few more tips

If you’re considering offering such a layout to your visitors, first, make sure you read through Big, Stark & Chunky and Joe’s presentation notes to understand the purpose and suggestions for creating a Zoom layout. Follow most of his advice, and you’ll be well on your way.

From my own experience, I’ll add a few tips to consider in the process:

• Re-examine your markup: Going to a single-column forces you to take a look at the order of your content within the markup. Try to keep your most important content — and the content which changes from page to page — toward the beginning of the document. Use common sense in determining order.
• Simplify navigation: Too many choices at the top of the page will be confusing, and may push the content completely off-screen when the text is bumped to a larger size. Keep the list as short as possible, and consider making the list inline, or float each navigation element. Do this in a way that it doesn’t look broken if the navigation wraps to more than one line. If long lists of navigation must be present, consider moving them toward the end of the document, then reposition them for your default style in your original style sheet.
• Avoid pixels: I’m not talking about type here — Joe covers that in his notes. Don’t use pixel values for width or height measurements of content containers (columns, etc.) And as much as possible, avoid the temptation to use pixel values for any margin/padding and line-height values. Use percentages, or even better, ems, which scale gracefully with the text size, retaining chosen proportions. If appropriate, use pixel values sparingly around fixed objects that won’t be changing in size anyway, such as the logo. You may also want to use a fixed-pixel value for the outer (body) margin or padding, to avoid those values getting too large as the text size increases.
• Remember form elements: Just as you bump up text size in general, don’t forget to do the same for form elements. Not all browsers allow every form element to resize with the text (shame on them), but do your best to make form elements as easy to use as possible for your low-vision users by bumping up their default size as well.
• Good and bad insets: Even though you’re striving to keep all content in a single column, it’s still OK to float the occasional image, as long as said image is not overly wide or tall. As long as text can flow freely around the image, the low-vision user still gets the benefit of seeing the image in context. The image won’t be scaling up preventing the flow of text around itself. That said, insets of text-based (non-image) content can be a bad thing, because that inset text needs to scale too. This can be distracting as different lines of large text compete for attention.
• Start from scratch: If at all possible, wipe out any existing site styles before applying new Zoom styles. In my opinion, it’s much easier to build a single-column design from scratch, rather than needing to go back and make sure you’re overriding all original style sheet values. This requires some server-side scripting to change the default style sheets that are linked or imported in the <head> of each document, and may not be possible for everyone.

Zoom style sheet availability

You may need to apply a few tweaks for use on your own site, but feel free to grab Stopdesign’s zoom.css file, or both that file and the zoom2.css file to use as a base/starter for your own Zoom layout. Both style sheets are licensed under a Creative Commons Attribution-ShareAlike 2.5 License. Creating a single-column style sheet isn’t difficult, but if these two files give you a jump on the action, be my guest. Cheers.

(It should go without saying, but this does not grant permission to freely copy and use any other Stopdesign style sheets verbatim for any purpose other than studying and learning how they function. Thanks.)

Update: Joe is now building a repository of information about zoom layouts, including links, references, and examples.

Grouping your CSS rules

I briefly touched on CSS organization a couple months ago. As a bit of background, if you’ve ever taken a look at any of my style sheets, you’ve probably noticed that I always divide them into key sections. In every project I create, I typically have sections in the CSS broken out for the following:

• Header
• Structure
• Nav
• Search
• Headings
• Lists
• Forms
• Links
• Misc

When I was learning CSS in 2002 before the Wired News redesign, I devised my own means of using commented text and a series of dashes as headings to make these sections easily distinguishable:

/* Navigation
----------------------------------------------- */

This makes it fairly easy for me — or a client who takes over the files — to find certain rules, or to know which rules affect a relevant portion of the design. Even more importantly, this method of organization saves a lot of time when troubleshooting any style sheets I’ve written, especially for older projects where memory of how a project was built might be fading.

Finding those sections quickly

So how to find rules quickly when you’re working? Some apps allow you to set markers in documents, allowing quick key-command access to that section. Great if you’re into that kind of thing, but it can get tedious to do with every new CSS file.

You could also do what I’ve been doing for the last few years: use your text editor’s FIND command to do a quick search for a certain block of text. But if your style sheets are anything like mine, a generic search like “nav” or “h2″ might point to several places in the document, requiring several FIND NEXTs (or many) to actually find what you’re looking for.

A fictitious, but even better example of FIND not finding what you want immediately: Say you have a section of your site you’ve abbreviated with the acronym “RDE”. So you label a portion of your CSS with:

/* RDE
----------------------------------------------- */

Great. So you can easily see the rules that apply to the RDE section. Except that if you want to use FIND to zoom to that section, you quickly notice that your text editor finds every instance of the following property:

#nav {
  float:left;
  width:182px;
  border-top:1px solid #911;
  }

A simple fix: Flags

As I discovered yesterday, if I add a simple flag immediately before the commented header text — like the “=” character, one that’s not used in CSS or class/id syntax — I have a simple text-based hook for finding (and zooming to) that section header immediately. So a quick FIND for “=rde” yields the following:

/* =RDE
----------------------------------------------- */

And I’m right where I want to be with a few keystrokes. No more finding redundant instances of that string. The “=” flag doesn’t even need to be placed before the first word. On a current project, I have several sections whose label begins with “MISC:”. So I place the flag next to a more unique word in the label:

/* MISC: =Lists
----------------------------------------------- */

…which allows me to quickly zoom to that section for generic/default list styles by doing a FIND for “=list”.

Of course, this tip is only helpful if you’re diligent about keeping rules organized into discrete sections when working with large style sheets.

Next tip will center around how I choose to break out my sections, the order of those sections in the entire document, and how to decide which rules get placed in which sections when there’s more than one choice.

Last year’s thinking and this year’s festival was no exception. As the plans started to come together for this year’s event, it was obvious there were going to be lots of people converging in Austin from all over the globe. Friends from previous years returning again. And people I’ve gotten to know virtually over the past year whom I was looking forward to finally meeting in person.

This year’s audience saw a redux of our “HiFi Design with CSS” panel moderated by Christopher Schmitt. Despite the fact that we each prepared separately, the topics we each covered and the order in which we each presented (Molly, Dan, Dave, ending with me) appeared to be a highly-coordinated logical progression through the story of design and CSS.

In last year’s panel on “CSS, the good, the bad, and the ugly,” I went over my alloted time, and had to stop my presentation before getting to the concept of Double Rollovers used for the Adaptive Path partner photos. I’ve used that same technique in several other places since then. Because it can be used for changing more than just two objects on mouseover at a time, I renamed the technique Remote Rollovers. For the first few minutes, I walked through how it works, and reviewed a few examples of its use. A companion article is already in the works which reviews the same examples and provides more detail on implementing the technique.

The second panel I sat on, “Web Design 2010,” produced lots of conversation and thought on where we might be in five years or more. Each of us on the panel (John, Dave, Jon, Eris, and me) had lots of opinions on what the web might look like five years from now, and what technologies we might be using. Some of the most interesting discussion to me (both before and during our panel) centered around the sociological implications of change on the web, how change will come about, how we’ll interact with the web and other people because of the web, and how and what we’ll be designing in the future. Many of our pre-panel and mid-panel notes are available in a Future of Web Design blog we started a few weeks before heading to Austin. Comments and discussion on that blog are now open to anyone.

Finally, my wrap-up wouldn’t be complete without pointing to a few of the photos I captured for SXSW Interactive 2005. I didn’t shoot as many as I would have liked, simply because I was caught up in so many good conversations and having too much fun to remember to pull the camera out of my pocket.

As the photos show, from my perspective, SXSW is definitely about people. The people who speak and present their ideas, the people who attend, the people who ask provocative questions and challenge the panelists, the people with whom you get to spend an hour or two eating around a large table, discussing everything relevant to our worlds. It was a pleasure to spend time with so many friends this year, and to make acquaintances with quite a few new faces as well. I’m already looking forward to next year. Except that this time, I don’t think I’ll underestimate how big SXSW 2006 might be.

Now, bear in mind, (in my opinion) the new visual design of MSN is quite uninspired. It’s drab and boxy. (No offense to the designer, if there even was one.) Looks like it may have gone directly from a Product Manager’s sketch to the developer who coded it. The design certainly offers nothing new or innovative, and looks like it’s following Google and Yahoo, obviously trying to play catch-up. (Perhaps some would say the MSN design, particularly the very top portion of the page, is a little too inspired. Looking like a confused mix of Yahoo’s pointy tabs combined with a poor Google-simplicity imitation.) The search page’s simplicity is so simple, it looks unfinished.

Despite a lack of interest in the visual design, I see several interesting things going on here worthy of mention, and to which we should pay attention:

XHTML 1.0 Strict

Not only do the new MSN pages unashamedly boast the XHTML 1.0 Strict doctype, the home page comes through with — at the time of this writing — only 28 validation errors, and the search page comes through with only 1 error. Not perfect, but so much closer than many other high-profile sites that have launched in the past couple years. Most of the validation errors are simple, easily fixable problems. The iframe for the ads will be a problem though: it’s not allowed in XHTML 1.0 Strict.

CSS for layout; improved semantics

The new site is also significant for its use of CSS for page layout and improved semantics. Lots of headings and unordered lists. A table used appropriately for the stock market summary; another probably part of a legacy ad system.

Upgrade message

A somewhat fair-minded (read: not entirely IE-centric) interestingly-worded upgrade message is displayed at the top of the home page when CSS is toggled off:

Why does MSN look like this?
Your browser cannot find our style and presentation information. You’re welcome to use the page as is, or upgrade your browser to its latest version. If you’re using Microsoft Internet Explorer, go to the Microsoft Internet Explorer website to install the latest version. If you are using another browser, see your browser’s website for more information.

Style switcher

A fairly prominent use of a simple client-side style switcher on the home page, allowing the user to toggle between blue and white body backgrounds.

Handheld media type

Look through the imported style sheet on the home page, and you’ll see several uses of @media handheld {} to target certain rules for handheld devices. Rules like this:

@media handheld {
  #sitenav,#content1,#content2,... {float:none;}
}

which turn off many of the floats. It’s encouraging to see a large site like this finally thinking about the handheld media type. Makes sense, with platforms like the PocketPC gaining popularity. Hope this is a sign that the PocketPC team is solidly behind the handheld media type.

However, I note lots of individual uses of @media handheld {}, containing only one rule each, rather than one use which groups and contains all handheld rules. Odd. See next point.

Dynamic style sheets

The use of query strings to point to their style sheets obviously indicates dynamic scripting is in play here. One of the byproducts of dynamically-assembled CSS is the ability to eliminate almost all whitespace in the style sheet. This makes it difficult for us to read, but easy for them to update (and possibly alter based on variable factors like browser). This potentially explains why the @media container wraps around single rules. Rules are probably flagged as being for a particular media type, and there’s currently no logic in the style sheet that groups rules together based on shared media types.

Input button outlines

Don’t assume all browsers allow full manipulation of input buttons. If you do, and I’ve been bitten by this one before, your buttons could end up looking like this (taken from Safari):

IE5/Mac left in the dust

I’m not sure what MSN.com looks like in the updated and much improved MSN for Mac browser (only available to MSN subscribers) that Tantek helped complete while he was still at Microsoft. But take one look at the new MSN home page in IE5/Mac, and one thing is clear: Microsoft seemingly paid no attention at all to what the new MSN site looked like in IE5/Mac. Ouch.

Microsoft links to an explanation of benefits of the new MSN where they list the top (first) feature as being “Faster load time“. Not sure what the old HTML file size was, but it would be interesting to have as a comparison.

Update: Some of you may be interested to know that folks from the MSN team have definitely seen this page, and are aware of the feedback, compliments, and criticism. See Venkat’s comment below for more info, and a link to a new MSDN blog where Venkat provides a few thoughts and asks for feedback.

However, I got to field a few questions from those who came up after each session. All questions were good, and quite relevant to what many of us do every day. Considering this, I thought I’d start sharing some of the questions people are asking after these conferences, along with my extemporaneous responses — sometimes informed, sometimes not so well-informed.

I don’t always have the answers on the spot, but I like to help find the answers when I can. And I think it’s helpful to know what our peers are asking about. If anything, these questions form the base for interesting discussion, and they pull in other people who can help provide answers or steer you and me in the right direction.

One question in Boston dealt with how to address portable devices (like phones and PDAs). Specifically, [my own paraphrased version] this gentleman was frustrated over certain devices, like the Pocket PC, which ignores style sheets linked with a handheld media type, but tries to apply any screen media type style sheets. It badly bungles portions of CSS, breaking the display of a style sheet intended for larger desktop browser windows. He would be fine if there was a way to hide screen media type style sheets from mobile browsers like we typically do with Netscape 4. But Pocket PC’s weakened support of CSS, along with trying to fit a larger desktop browser design into a small window, left him wondering what choices he had.

I’ve heard similar complaints in the past about the browser on Danger’s Hiptop.

First, my thoughts on why most mobile browsers don’t currently support the handheld media type. Then a potential solution for the short-term until they do. (I should state that these are completely my own observations and theories, and I’m an outsider to the entire mobile industry.)

Show of hands for handheld support?

So why isn’t the handheld media type supported more widely by now? Why aren’t mobile browser software companies doing the right thing from the start?

We’ve seen an explosion in the last year of mobile phones and PDAs that support web browsing (to some capacity). They’re doing a better and better job of it. Companies who make the browsing software for these devices want everyone using them to have the “richest” possible experience when they attempt to browse the web. If mobile browsers rendered a web page like it was 1996 without any styles applied — as would be the case with most sites that don’t offer a handheld style sheet — there would be a harsh disconnect between what people knew a certain site looked like viewed with their desktop or laptop computer, versus what it looked like on their phone or PDA. Some of the branding and familiar design elements of the site might be lost if mobile browsers didn’t attempt to render everything they could. These browsers render as much of the style for each site as they can. This often leads to problems for developers who try to do the right thing by supplying a handheld media type style sheet.

It’s a chicken and egg thing. Mobile browser software companies aren’t building in support for the handheld media type because virtually no sites are authored with a handheld media type style sheet — yet. However, designers and developers won’t start using the handheld media type until they know there are at least a few mobile browsers that reliably support handheld style sheets, and can immediately see the benefits of providing these additional style sheets.

Clearly, this mobile browsing thing isn’t another flash in the pan. It’s here to stay and it’s only getting more popular. We need to account for the millions of mobile devices attempting to hit our sites. And we need to be designing and building our sites to work everywhere. This includes devices for people with disabilities as well as mobile and all other forms of utility browsers we haven’t even seen come to market yet.

We don’t want to go back to 1997, where we had to build different versions of our sites for each new browser that entered the market. True, in some cases, sites may need to be customized for the best mobile experience, and this may mean a completely different architecture, let alone HTML structure. But when we have the chance, we want to optimize the design or presentation of content based on what type of device is used to view that content.

Things needs to change. It requires action from both browser makers and the designers and developers creating the leading-edge sites. Those sites set examples for everyone else. Neither side needs to think whether or not to go first, they just need to go.

Before I continue, I should note at least one company whose browser correctly supports the handheld media type. Opera has taken considerable steps toward dealing with the challenges of rendering web pages on mobile devices with its Small-Screen Rendering technology. For the majority of web pages that aren’t yet using handheld style sheets, Opera will optimize the page using its SSR technology. However, when Opera detects a page with an existing handheld media type style sheet, Opera assumes the author optimized the page for small screens, correctly applies the handheld style sheet, and disables SSR so as not to interfere with the author’s intentions. So in Opera, pages styled with handheld style sheets render as the author intends. But pages without a handheld style sheet get the SSR treatment. A brilliant fallback solution.

Until that day…

Even as Opera sets a good example, what about other browsers that aren’t yet supporting the handheld media type? How do we design and author our sites with robust style sheets applied to the same basic HTML, forming an attractive, usable site no matter what type of browser or device is used to access the site?

My response to this gentleman involved using JavaScript to force support for handheld style sheets and detect a screen size smaller than X. Some of you may not prefer to use JavaScript for browser type or window-width detection. But until more mobile browsers support the handheld media type, we need some type of proactive fallback solution so we can effectively target small screens and optimize designs for them.

I first suggested he go ahead and add a secondary handheld media style sheet. Then use JavaScript to detect smaller screen sizes. If detected, change the secondary style sheet to both screen and handheld, adding to (and overriding) the default screen media type style sheet. The secondary style sheet (intended for mobile browsers) might contain rules that eliminate floats and absolute positioning used for page layout, and remove any fixed widths for columns and containers. Ideally, a handheld style sheet allows the design to shift to a one-column flexible-width layout that shrinks or expands to fit available screen width.

The problem with my first suggested approach? Many of these new mobile browsers don’t completely support JavaScript yet — if at all. Others disable JavaScript by default for security or “user convenience” purposes. Bah humbug!

Take two

So how about the inverse of that approach?

What if we started by applying a very basic style sheet as both screen and handheld media types. The basic style sheet would only apply simple rules for color, typography, link treatment, and simple list styling. No complex floated columns or absolute positioning. This style sheet would take care of all CSS-supporting devices, whether or not they support the handheld media type.

Then, we use JavaScript to detect wider browser widths — those that might typically imply a desktop browser. If JavaScript is supported, and a wide width is detected (say 620px or greater — or maybe even 750 if your design only works at 750 or greater), then we assume not only a desktop browser, but that enough window real estate exists to render a multi-column design as intended. In this case, we add the main style sheet that divides the page into our standard multi-column layout. Browsers that either don’t support JavaScript (or where it’s been disabled) or browsers that don’t report wide enough screen size only get the basic style sheet.

Seems like that would work. Of course I only know enough JavaScript to hack my way through existing code, not enough to write my own from scratch. So I’m not even going to attempt to write something or create a test example. Others should feel free to suggest or create code, or test this approach however possible.

I’ll note that this is a very similar idea to the solution Cameron Adams recently devised for the opposite problem: how to provide more content or more design when the browser window is extra-wide. (See his Resolution dependent layout, 21 Sep 2004.) In this case, I’m simply recommending going back one step before what Cameron is doing. A simple, basic style sheet is applied as both screen and handheld media types, and takes care of the lowest common denominator that still supports CSS. Then detection of wider window widths results in the application of a more advanced style sheet that breaks the page into multiple columns. Then Cameron’s idea enters in for applying yet more styles for ultra-wide window widths.

Killing the FOUC

One important note if all the above is possible. I might also suggest setting a cookie with JavaScript if a wider window width is detected. Once a cookie is set, server-side code could check for the cookie on subsequent page views, and determine whether or not to add the main style sheet (or not) before resulting HTML is streamed to the client. This way, we avoid the FOUC for any page beyond the first page view.

Feedback, expansions, modifications, pitfalls? Code samples, examples, or other ideas?

“More power to the people!”

… the crowds shout from all around. And just like that, their wish was granted.

Here’s your chance to play Backseat Design Director for Stopdesign, and enforce your decisions. Prefer the stark whiteness and simplicity of Bleached? Want to demand that Liquid Bleach remain on the shelves? I want color! The type is too small! The type is too big! And on and on…

You can now play with configurations until your heart is content. And this little preferences page is your interface for orchestrating any changes you desire… within reason, of course. (Note: The preferences page is also accessible from that little prefs link at the top of the page next to contact, and from any of the About pages.) Choose between three site-wide styles, and/or set text to a base size of small (the default), medium, large, or extra large. Your preferences will hold throughout the entire site, until you change them again.

The preferences page uses a server-side style switcher utilizing a cookie, written in PHP, with very few lines of code. They key (and most of the work done before the release of Liquid Bleach) was separating out the style sheets so that additional color or liquid style sheets could be laid over top of (read: added after) the basic stripped-down version, overriding the stark-white fixed-width design of Bleached.

The text size change is a simple matter of altering the base font-size keyword of the body element with an extra style sheet, since that’s the only place I set font size with an absolute value. All other size changes happen throughout the rest of the style sheet via percentages of that base keyword size. A few adjustments in the background position of certain icons, and the large and extra large text size style sheets were good to go.

As noted at the bottom of the page, Comment Preview and Error pages will not pick up any preferences you change. Those pages are rendered by static Movable Type template code, thus they’ll remain Bleached for simplicity’s sake.

Select the version that makes you happiest. Change your mind tomorrow? Set it back. I’m still partial to Technicolor at the small text size. But on larger screens, Liquid Bleach with the text size bumped up to medium or large doesn’t look too bad either. You make the final call — it’s your experience.

Choose wisely.

The parent container for Liquid Bleach is set to 95% of the browser window width. 2-column proportions are basically set at 65%/35%, while 3-column proportions adjust those numbers to keep the middle column slightly wider by a small percentage. A min-width for the parent container is set at 750px for 3-column layouts, and at 600px for 2-column layouts, in attempt to prevent any weirdness caused by fixed-width images that live in the liquid-width columns. (IE users beware: min-width is — yet — unsupported in your browser, so it is possible for you to drag your window so small that the layout might break.)

Liquid layouts are easy to create in theory, but can be difficult to implement effectively. I’ve seen many liquid layouts that fall apart with hardly any browser resizing. I don’t even think this version comes close to achieving perfection. With liquid layout, columns constantly change widths, text reflows freely, objects reposition on the page without warning. More challenges ensue when relying on CSS for layout, rather than the easy-to-fall-back-on table-based layout.

Doubling margins, subtractive padding, nested percentages, and differing box models, oh my! Enough to make anyone shake their fist at the monitor a time or two. It’s hard to keep everything straight in liquid design. Which is my guess why we’re seeing so many fixed-width CSS layouts emerge. With fixed-width, everything Just Works™ a lot more often. Liquid? Well, creating a flexible-width design might take just a little more care and experimentation. Pulled off well, they can be a pleasant wonder the user never needs to think about or notice, because the design adapts to whatever size their browser window happens to be.

At this point, I’m not arguing for either. I’ve written before about fixed vs. liquid before, but I always dodge the debate. Apply whichever one makes sense given needs, goals, and the environment you intend to create. Given the success of the liquid-based version 2 of Stopdesign, I thought it important to eventually go back and create a liquid version of this new design, even if it were devoid of most color.

When creating liquid layouts using CSS, here are a few considerations I keep in mind:

• Double-div columns: As much as I hate to use extra markup, there’s no easier way to ensure maximum compatibility across multiple browsers than to use two divs for each column. The outer divs are used for setting widths. Inner divs are used to set padding to create gutters of white space between each column.
• Use fixed-width gutters (or gutter widths based on type size): When column width gets applied independently of column padding, as above, percentages can be used for widths, and pixels or ems can be used for padding. This, without worrying about one column getting bumped to the bottom of another, or without purposely under-sizing columns so they always fit on the page. Even though column widths change as the browser gets wider or narrower, the text on the page generally stays the same size. The amount of white space required to make the text feel comfortable is dependent more on the size of the type, rather than the size of the column containing that text.
• Avoid fixed-width columns: As much as possible, make all columns a percentage width. It’s tempting to think of sidebars and navigation columns as being one static width, and let the main or middle column do all the expanding. This quickly destroys any proportions that may have been carefully chosen, as the fixed width columns can look puny and weak at large resolutions. Or wide fixed-width sidebars can become daunting, over-powering the main column at narrower browser widths.

These aren’t, by any means, rules of the road. They’re simply my own formulas for making liquid layouts as pleasing to the eye as possible. Given the first point, some of the markup had to change here to enable greater flexibility for different types of layouts and future style-switching of the design. As more flexibility is built into a design, the markup slowly gets more complex to account for different scenarios.

One small point of interest I’ll quickly point out: I’m using a new technique for liquid layouts that I’ve been wondering about for a while. Eric Meyer helped hammer it out last week as we batted ideas back and forth. It combines my Sliding Doors method with Dan Cederholm’s Faux Columns to create some sort of Sliding Faux Columns effect. Each of the floated columns vary in width and height, depending on browser width, and the column separators move with them, sliding together or apart as necessary. The separators also span all the way from header to footer, regardless of which column is longest.

This bleached version of Stopdesign only requires column dividers, since it eliminates the original tinted columns. But this same technique could also be used for columns filled with background colors or patterns, as might be shown in a future version of Stopdesign.

The trick is to create an ultra-wide background image (or two images for 3-column layouts, thus the Sliding-Doors-nature of the technique). The image is partially opaque, and partially transparent. It gets tiled vertically inside the parent container, just like Dan’s Faux Columns technique. The opaque portion of the image should match percentages of the column it helps create, so that it can be positioned with an identical background-position value. This allows the transition from opaque to transparent to become the axis point for the background’s position. The opaque portion’s position within the image could be altered based on order of content within the HTML to produce almost any effect desired.

Since this bleached version only uses dividers, and not fully filled columns, I’m only using one image for all column dividers, cut down to 1px by 20px. It’s still positioned the same way as above, it just doesn’t need to be as wide since it’s not creating a fill color or pattern.

I’ll restate again: this noodling with the layout is only temporary. Those of you harassing me to change it back, please stop. I’ll eventually default back to the full technicolor fixed-width version of Stopdesign. But it is my intent to make the changes I’ve been testing here available via a server-side style switcher. That’s next on the agenda, after other more pressing work is completed.

Ahem. Let’s try that again.

Ever wondered what your site would look like devoid of most of its color and imagery? Bleach the entire design, remove the saturation and leave behind the basic visual structure on a stark white background? Sure, some sites already use a white background for their design. But Stopdesign has been filled with deep colors and prominent header images since I launched this design a few months ago.

How ’bout we strip away all that decoration and atmosphere? Temporarily. There’s something about looking at a design without all the extra layering of color and fancy graphic work. It allows one to see how much the basic form, structure, and proportions speak for themselves.

Or not, in some cases. Often, color and imagery is overtly used to disguise bad design. Take away color and images, and some designs fall apart. I wanted to prove to myself that this wasn’t the case with Stopdesign.

Nothing about the design changed position — aside from the slight adjustment I snuck in on the home page yesterday, giving more emphasis to the latest entry. Those who remember and liked v2.5 of Stopdesign, where I really did “start over” will note some similarities with this version.

(Ooh, hey, what was that little 2.5 link he just slipped in there? What? An archived version of a prior design? I didn’t know that existed. Hey, wonder what happens if I change the URL to see if v2 works? Whoah, he kept that one too! So, did he actually have a v1 design? Ouch, nice table-based layout!)

Bleached was a small challenge for me, and an excuse to further separate the function of different style sheets. One to control the basic layout, visual structure, and common design elements. Another to pump in color and imagery. With the advance prep work in place, the only change needed to switch to Bleached was to yank the @import for the color style sheet. When I want to return to the full-color design, I’ll simply add it back in.

I’ve been using a separate color.css file to control section-based colors for a while now (something I started playing with on Wired News).

But unlike Wired, until today, if you pulled out Stopdesign’s color style sheet, you would have been left with a color scheme that looked like the home page color scheme, since that’s the page I used to start authoring the CSS for this design. For Wired, I actually created a grayscale version of the design as a base. Then alternative color style sheets are added to create each day’s color scheme. They’ve never used the grayscale version. But it’s there, just in case.

And now, a bleached version of Stopdesign exists as a base. So poke around a little. Explore the untainted space. And if you miss the color and pretty pictures of the unbleached design, don’t worry. This isn’t a permanent change. If you do like it, don’t worry about it’s lack of permanence. A style-switcher will make it’s way onto Stopdesign soon, allowing you to choose whether you want the full technicolor experience or not.

The real fun will be my next challenge with this site: Liquid Bleach.

Turns out I underestimated. By just a little.

Olivier Vanbiervliet pointed me to a public Microsoft page titled “Inside Microsoft“. The page provides a bit of “backstage” information about microsoft.com, including some detailed stats for the month of May 2004.

Their published traffic numbers actually state that microsoft.com got 1.2 billion page views in May 2004. Divide that by 31, and we’re not just looking at 1 million page views per day, but more like 38.7 million page views per day.

Which, if you do the math, with a potential average savings of 25 KB per page, works out to numbers a little higher that what I originally projected. More accurate savings could actually be closer to:

924 GB per day.

329 terabytes per year.

I updated the article to reflect these more accurate projections.

Half way through the presentation, I switched gears and announced we’d be converting a real-world example from tables and spacer gifs to a pure CSS layout. I could have created a fictitious example to work with in the presentation. But that idea would have seemed too contrived. If I created my own example, it would have been nice and tidy. Everything would have rendered exactly as I wanted it to, staying free and clear of any “trouble spots” I already knew to avoid.

Fictitious wasn’t good enough. I wanted a real challenge. So I chose the site of a small, local-to-the-Seattle-area company I thought a few of the attendees in the audience might be familiar with: Microsoft

Ok, maybe more than just a few attendees were familiar with this not-so-small company. Many users arrive at Microsoft’s home page every day. Microsoft’s literal home page may or may not be as well-known and oft-used as search giants Google and Yahoo! But microsoft.com in general gets tons of traffic, and the people which pass through its domain every day quite likely number in the millions.

The shame is that Microsoft’s site isn’t as optimized as it could be. They haven’t taken the plunge yet. Users download unnecessarily larger pages, and servers waste extra bandwidth to keep up. At 40 KB, the HTML for Microsoft’s home page is not exactly a bloated beast. But it is burdened with inaccessible, kludgy, table-based markup filled with proprietary attributes and some awkward JavaScript. Notice I didn’t mention whether it was valid markup or not. Despite using the flavor of XHTML, Microsoft omits the doctype on their home page.

Why Microsoft?

Is this just another “pick on Microsoft” thing?

Bluntly and honestly… no.

I didn’t choose Microsoft to jump on the bashing bandwagon, or to toss a few more pot shots at a company some people in our industry love to hate. (I didn’t pass up any opportunities to question certain decisions they’ve made, but I avoided passing judgment.)

I admit that I purposely chose and targeted a high-profile company. It’s my nature to go after the top guns. But it’s also an example with which almost everyone is already familiar. Microsoft.com was (and is) a perfect candidate for a standards-compliant CSS makeover.

Here’s why…

Reason #1

Because of the inefficient use of an abundance of tables and spacer gifs used to layout the page. Pages are more locked down when their content is laid out using tables, and can often be less accessible as a result. Microsoft is not alone here. An overwhelming majority of sites on the Web today still use lots of tables for page layout and other purely visual purposes. I chose Microsoft because it could serve as a well-known example (and eventually a model) that relates to the same issues many sites still need to address.

Reason #2

Because the basic structure of Microsoft’s current design is a model that thousands of websites use for their own site design: Header + 3 columns + Footer. Specifically: a Header that spans all the way across the top of the page, a Left column containing mostly navigation, a Main column for content, a Right column for extra “stuff”, and a Footer that sits below all three columns and also spans the entire width of the page. If it’s not a 3-column layout, many sites might use a 2-column variation of this same basic structure with a Sidebar to the left or right of the Main column:

Reason #3

Because Microsoft’s home page uses CSS for little more than FAC (fonts and color). I’d love to see the company that basically invented the concept of style sheets in an application environment, lean more heavily on CSS, and less on old-school methods.

Reason #4

Because Microsoft is currently serving a different version of their home page depending on which browser is used to view it. One version for Internet Explorer for Windows (v5.5 and above). Another somewhat “dumbed-down” version for all other browsers (including IE/Mac) that omits some of the imagery and all product logos. The non-IE/Win version leaves out some of the functionality (e.g. fly-out menus) and renders page elements with different techniques. If you have IE/Win 5.5 or higher, plus another browser available, you can check for yourself. If not, here’s a screenshot of the two versions, with differences circled in red:

The non-IE/Win version is noticeably more anemic than the full version served to IE/Win. We all know it doesn’t need to be this way. If you’re wondering, it’s not just sloppy coding that works in some browsers and not in others. Microsoft intentionally does a JavaScript browser detect, and redirects the browser to a different file if the browser is IE5.5 or higher. Instead, Microsoft could just maintain one version that works in all browsers.

At least Microsoft serves a version of its page to non-IE/Win browsers. Some developers may not even go that far. The frequent reason we hear cited for dropping support for other browsers is that MSIE/Win is THE browser used by a MAJORITY of people, and that it takes TOO LONG to develop for (and render properly in) any other browsers. Others complain that development for browsers other than IE/Win is TOO EXPENSIVE. Both the too long and too expensive claims are false.

Many developers believe these claims because they start by developing for — and checking in — IE. Then they view it in another browser and become frustrated when they see all kinds of supposed “bugs” they think they’ll have to fix.

IE interprets CSS more loosely than other browsers that have been iterating versions over the last couple years (Mozilla, Firefox, Safari, Opera…). Starting with IE means fewer problems with development work will be detected early on. Developing for IE initially, then trying to retrofit for other browsers will increase time and cost in the long run. But there’s a better way to approach development that’s faster and less costly.

Start with the stricter, more compliant browsers that (usually) render things how they’re supposed to render. Get everything working there. Then, double back and create a few “patches” for IE. Development is much faster this way. It may be counter-intuitive to initially avoid the browser that represents the majority of your traffic. But the process is much more fluid and efficient if you don’t become accustomed to — or depend on — IE’s relaxed rendering behavior. Start with IE, and you may start with bad code that takes much longer to fix for other stricter browsers.

Going this route, we still have the IE Factor to contend with. However, as we gain more experience with IE’s CSS misbehavior, the IE Factor eventually starts to minimize. There is hope.

Just the Facts, Please

For the second half of the presentation, we stepped through the entire process of converting Microsoft’s table-based spacer-gif-laden page to a more accessible, purely CSS-driven version that works in all browsers. This is not new. Others have re-coded microsoft.com before. Many regular readers of this site have been creating tableless designs for a year or more by now. But we don’t see everyone else jumping into the water yet, despite the water being fairly thoroughly tested by now. Thus, the presentation at Digital Design World, and this follow-up article.

Continuing the presentation, we broke down each stage of the process into manageable chunks. I highlighted each of the major steps of the process, including the dumping of tables, conversion to more semantic markup, and the CSS techniques used to faithfully reproduce each portion of Microsoft’s home page design.

Throughout the presentation, we examined lots of visuals (diagrams, screenshots, and pictograms) that aided in understanding the techniques used to render each section. I also had the code saved out as separate “pre-baked” files I could refer to for each stage of the process.

One of the reasons for writing this follow-up article is to publish the final results of the Microsoft.com makeover, which are kind of hard to ignore:

Going Further

The numbers get even more interesting when we start doing Meyer/Davidson ESPN-style estimates and projections. According to a public Microsoft page titled “Inside Microsoft“, Microsoft’s published traffic numbers state that microsoft.com got 1.2 billion page views during the month of May 2004. In this presentation, I showed how to decrease the markup from one page by 62%, or 25 KB. I also predicted that about 25 KB is a fair savings estimate per page if Microsoft was to get more aggressive about using CSS site-wide. If multiplied out by an average of 38.7 million page views per day, that 25 KB savings per page could add up to about 924 GB in bandwidth savings per day, or 329 terabytes per year.

These numbers alone should be enough to turn a few heads.

Now, toss in the fact that the makeover is just one version, and supports Microsoft’s more “advanced” design, (as currently seen in IE/Win) and does so in many more modern browsers.

Companies like Microsoft may or may not want to maintain just one version of their home page that works in more browsers, loads faster, and is more accessible to all kinds of users and devices. Regardless, I thought it was worth pointing out that it’s now very possible to demonstrate and walk through how they — or any company — could create one super-powered version that uses leaner markup, works in more browsers, and increases accessibility. All demonstrated within the time span of an hour or two…

Additional Points and Caveats

• If you’re curious, and like to be thorough, the CSS only increased from 3 KB and 5 KB (IE/Win and non-IE/Win versions, respectively) to 8 KB for the makeover version.
• The fly-out menus seen in IE/Win’s version for two options in the left-side navigation are possible to reproduce as well. All done with pure CSS and simple, semantic, accessible markup. The makeover uses the :hover pseudo-class to toggle on/off a nested unordered list when mousing over the parent list item. One consideration: IE doesn’t support :hover on list items, so the JavaScript method Microsoft is already using would still be necessary to support fly-out menus in that browser. Or something like Suckerfish Dropdowns could be used to keep the same semantic nested-list markup the makeover version uses.
• The hefty jump in number of image tags for Microsoft’s current non-IE/Win version is due to heavier spacer-gif usage. The non-IE/Win version also calls every bullet image individually, rather than via one CSS declaration, as the IE/Win and makeover versions do.
• All of the JavaScript found in Microsoft’s markup was removed. As were hundreds of proprietary attributes in anchor elements that were/are apparently used for click-tracking purposes. Microsoft would likely want to add some of this layer back in — though hopefully through a valid means of doing so.
• As mentioned above, the point of this article is to publish the potential results and benefits of using CSS and simpler, more semantic markup to build pages. It merely uses Microsoft as a well-known example. This article intentionally omits linking to the final makeover code. I understand that many people could learn from the work done for this presentation, without seeing the presentation, by studying the changes made to the HTML and CSS. However, I do not want to downplay anyone’s role at Microsoft by publicly releasing modifications to their source code before having a chance to present them directly to Microsoft, and discuss the changes and techniques with appropriate team members, if they ever wish to do so.

Translations

This article is translated into the following languages:

• Brazilian Portuguese: Jogando as Tabelas Pela Janela by Humberto Oliveira
• Simplified Chinese: Throwing Tables Out the Window by Gregory Song
• Dutch: Tabellen uit het raam gooien by Nick Verstappen
• French: Passer les tableaux par la fenêtre by Benjamin David
• German: Tabellen aus dem Fenster werfen by Eric Eggert
• Italian: Gettare le tabelle fuori dalla finestra by Giuseppe Di Carlo
• Japanese: Throwing Tables Out the Window by Kohei Yoshino
• Polish: Wyrzucanie tabel przez okno by Pawel Grzesiak
• Spanish: Tirando las tablas por la ventana by Hermann Kaser
• Turkish: Tablolari Pencereden Disari Atmak by Mehmet Dogan

Update: As of 27 July 2005, the example code and corresponding presentation slides were released and made available to everyone. See Still throwing tables for background information and links to the code and presentation referenced in this article.

Tuesday evening, after arriving late that afternoon on the same flight as Jeff, we met up for dinner with some former colleagues from our Wired/Lycos days, Dave Hendry (who now teaches at U-Dub) and Steve Mulder (in Seattle also to speak at the conference). We also conned a local friend, Tim, into joining us to help pick a place for dinner. We ended up at the Palace Kitchen on Fifth Ave. (Which I heartily recommend, by the way. The food was excellent, and the five of us walked right in without a reservation.) Wednesday evening, Nick and Crystal kindly took me to dinner just a block from my hotel (to save me from needing to walk too far). Later that night, I joined Jason and some local cohorts of his for drinks out on the back patio of Elysian, where we enjoyed the previously-mentioned warm summer night, exchanged stories of working with large companies, then drove nearby to see the oddly non-signed mostly-unidentified building of Amazon.com. Earlier today, after an ever-so-brief visit to Seattle’s new Central Library, just before heading off to the airport for my flight, I met up with Mike Davidson for lunch at Jackrabbit.

The two presentations I gave on Wednesday went over well, generating lots of interest from the audience. The first presentation I gave on Beautiful Interfaces with CSS had lots of new visuals in it. Many of my text-heavy screens from the last time I did this presentation are now replaced with screenshots, diagrams, pictograms, and photos that demonstrated my talking points. I was a little nervous about the second presentation (on tableless design), since I didn’t know how well I could pull off a complete redo of a well-known table-heavy site in under an hour. The second was just as successful as the first. I’ll write a little more about the second presentation in a follow-up entry.

Thought I’d share one of the images I created for the first presentation. Paul Scrivens maintains (and constantly expands) an excellent showcase of recently-launched or redesigned sites that use CSS extensively in the CSS Vault. Obviously the Vault can’t (and doesn’t) document every single CSS layout that launches. But the collection is impressive, nonetheless. After obtaining permission from Scrivs, I grabbed screenshots of the last 144 sites (at the time) that had been added to the Vault over the last four months, and assembled a random mosaic that shows the rapid expansion in the popularity and use of CSS in a broad spectrum of site design.

The images were added to the mosaic in reverse-chronological order, following the order they were added to the Vault. The top-left corner starts just a few days ago with 456 Berea Street, and works backwards in time, ending somewhere in March (2004) with Eview 360 at the bottom-right. Perhaps you can spot a familiar design or two…

(Note: Image above links to a page displaying a much larger 376 KB JPEG image, 1200×900 in dimension, which is still only 50% of the size of my original.)

Update: Steve Smith heard the call and answered: the larger image now uses a complete image map to make every portion of the mosaic clickable to the appropriate site. Thanks Steve!