• Skip to main content
  • Select language
  • Skip to search
MDN Web Docs
  • Technologies
    • HTML
    • CSS
    • JavaScript
    • Graphics
    • HTTP
    • APIs / DOM
    • WebExtensions
    • MathML
  • References & Guides
    • Learn web development
    • Tutorials
    • References
    • Developer Guides
    • Accessibility
    • Game development
    • ...more docs
Archive of obsolete content
  1. MDN
  2. Archive of obsolete content
  3. An Interview With Douglas Bowman of Wired News

An Interview With Douglas Bowman of Wired News

In This Article
    1. Wired News Redesign in a Nutshell
    2. Why did you pursue a standards-based redesign of Wired News?
    3. How is the site styled now that you've ripped out all the HTML-based presentation?
    4. How much did the size of a typical Wired News page shrink?
    5. What made you decide to drop tables as a layout mechanism? It seems like most designers think that you have to have at least some tables for layout.
    6. Are you setting up your columns with floats or positioning?
    7. Why did you choose positioning over floats?
    8. How does the new design perform when the pages are printed?
    9. So what advantages does this redesign give you as a site administrator?
    10. What disadvantages did you encounter?
    11. Were there any other lessons you learned during the conversion process?
    12. What would you say to a site developer considering a similar conversion to standards-based layout, either with simple tables or no tables at all?
  1. Original Document Information

One of the Web's oldest news sites, Wired News draws between 20 and 25 million page views every month. On October 11, 2002, Wired launched a brand-new site design that uses validating XHTML for its structure and a small collection of CSS files for its layout. The new design clearly shows what some experts have been saying: that standards-based design can be visually compelling and preserve the interface conventions we've come to expect from Web pages.

The brains and primary driving force behind this compelling new design is Douglas Bowman, Network Design Manager for Terra Lycos, who graciously agreed to an interview and in the process shed a lot of light on what goes into a standards-based redesign.

Wired News Redesign in a Nutshell

  • Driven by XHTML 1.0 Transitional and CSS;
  • Allows centralized control over layout and appearance for thousands of pages;
  • Simple markup allows for rapid changes to templates;
  • Average page weight dropped by almost half;
  • Page layout accomplished with simple CSS positioning;
  • Vastly increased accessibility without special coding or user agent detection.

Why did you pursue a standards-based redesign of Wired News?

As Network Design Manager at Lycos for the last two years, I've been creating and documenting design standards for our network of sites. This includes rules and guidelines applying to everything from headers, footers, page hierarchy, titles, typography, iconography, navigation, and others. So I'm very familiar with standards and the benefits of using them. With the Wired News design process, the scenario was reversed. As I was designing the product, I began discovering a broader set of Web standards, and was quickly swayed by the advantages I could see if we were to adopt them.

It was a no-brainer to us that Wired News was a perfect candidate for the total conversion to XHTML and CSS. The content of the site tells the story of how technology affects our daily lives, especially in the realms of business, culture, and politics. Why not attempt to use technology standards for the Web to live out that story? The visual design of Wired News and the Vignette templates were all sorely stale, and we had no significant effort invested into either for more than two years. I think that fact played a critical role in our team's willingness to try out something completely new. Our engineering team actually needed the least convincing to convert over to a standards-based design, because they could also immediately envision the benefits to their workload and maintenance of the site.

How is the site styled now that you've ripped out all the HTML-based presentation?

Technically, there are 13 total stylesheets used at any one time. The breakdown:

  • 1 master screen media file which imports 4 files:
    • a base file (bulk of formatting)
    • a file for finance/table formatting
    • color file (override colors and background images for specific color scheme)
    • temp file (used for styles associated with temporary features and ad-related pages)
  • 1 print media file
  • 1 aural media file
  • 3 master alternate style sheets which import 1 file each
    • the 3 imported files set alternate font sizes (small, large, larger)

How much did the size of a typical Wired News page shrink?

The HTML went from 32 KB down to 19 KB, but images increased from 8 to 13 KB. We've noted that some of the file size comparison's aren't necessarily fair, because we're not comparing apples to apples-- we're comparing an old design using html, tables, and spacer GIFs to a new design much richer in imagery and style.

What made you decide to drop tables as a layout mechanism? It seems like most designers think that you have to have at least some tables for layout.

I've been manually writing sample code for my own design prototypes for 4 or 5 years now. I used to pride myself in knowing how to reproduce any interface design down to a pixel-perfect level. A developer would tell me something wasn't possible, and I could prove otherwise every time. Like other designers and html whizzes, I became a master at manipulating and troubleshooting tables, nesting them in intricate ways to produce any layout or effect that could be imagined.

I remember one project for Lycos where we had nested tables 10 levels deep. I counted them myself. It wasn't that every level was absolutely necessary to reproduce the intended design effects. But each table ensured the flexibility we needed if certain modules and pieces of content appeared or disappeared. When you get to that point, the amount of markup you have to sift through to find anything becomes ridiculous. Until this redesign, Wired News wasn't even using CSS to style the content inside tables. The sheer amount [sic] of redundant <font> tags inside every cell was probably enough to double file size.

My initial attempts at the markup and CSS for the Wired News design eliminated the majority of our tables, but left one master table to control the primary columns of each page. That approach meant that the content of every column would have to be loaded and calculated before it would be rendered in the browser window. That wasn't good enough. Around that time, I started discovering great sites like glish.com and bluerobot.com. Both presented and documented viable means of producing multi-column layouts without a single table. Despite some initial setbacks with those approaches due to our own unique scenarios, it wasn't long before I discovered a variation of one of their methods that worked for the Wired News design.

By eliminating tables that were strictly used for layout, we significantly cut back on the amount of markup and useless tags in our html, and gained a structure that is much easier to maintain. Now that the content is not locked into a specific table structure, we have much more flexibility in how we present that content. A few changes to the CSS can completely alter the presentation of thousands of pages. As a very welcome side benefit, we also believe the accessibility of Wired News will dramatically improve without the clutter of nested layout tables.

Are you setting up your columns with floats or positioning?

In trying to eliminate that last table I was using to set the column structure of our pages, I took a close look at both floated divs and positioned divs. I went back and forth between each one for two weeks, and finally narrowed in on positioned divs as the choice for Wired News.

Why did you choose positioning over floats?

Floats had a few disadvantages from my perspective. One was the required order of content within generic markup. For Wired News, the center (or main) column usually contains the most important content for each page. I wanted center column content to appear first in browsers that got the un-styled version. With floats, either the left column or the right column always had to be drawn first. For sites that rely on a left or right column for primary navigation, this content order requirement of float usage may produce desired and advantageous behavior.

I also found a lot of trouble ensuring a consistent vertical start position of columns using floats. Two column layouts using floats seemed easy. But adding a third column to the mix created too many width variables for some browsers to dynamically calculate a total. Resizing the browser window often resulted in one column getting pushed to the bottom of another.

Using absolute positioning for left and right columns allowed the markup for each column to fall in any order. There are some technicalities in the order of our markup and some ad units that would require too much to cover here. But positioning did allow the center column to fall first in the markup. It also guarantees each column will start in the same vertical position.

To be fair, I did note two disadvantages of positioning. When one or more columns is positioned absolutely, there is no way to ensure a footer would always appear at the bottom of the longest column. We ended up confining the footer to the width of the center column to avoid any possible overlap. The other disadvantage comes into play at small browser window sizes. While floats automatically reconfigure if they don't fit within the window width, absolute positioned columns always remain in the same place, even if it means content in one column begins to overlap another column. Both of these put together weren't enough to dissuade me from the advantages of positioning over floats.

How does the new design perform when the pages are printed?

We have one CSS file specifically set up to cover most of the content throughout our pages for print media. By default, all links to screen media CSS files are explicitly declared as "screen" media instead of "all" media. By doing this, we don't have to override any of the screen styles, giving us a blank slate to start with for print styles. The print styles present the page content in one column, rather than splitting content up into two or three columns. It also eliminates most of the background colors and images to save on printer ink. Fonts are sized in point (pt) units and use serif faces for improved legibility on a printed page.

Our stories are logically the most printed pages of the site. Technically, with the print media CSS file, we didn't have to generate a separate print template for stories. However, since some of our stories are broken up into 2 or 3 pages, we created a slightly altered template for print versions which pulls the entire text of the story into one (Web) page. Since we had a separate template to work with, we changed the media attribute of the linked print style sheet to "all", and eliminated the links to normal screen media files. This allows us to temporarily display on screen the same formatting to be used for printing that page.

So what advantages does this redesign give you as a site administrator?

You mean besides the fact that as designer, I can control design details on thousands of news pages with just a few files? Besides the fact that the engineers can finally focus on building out the working functionality of the site rather than worrying about appearance or where the next spacer.gif is supposed to go? Besides the five minutes it recently took for one of our developers to rearrange a module when he thought it would take him an hour or two? Besides the idea that we're changing our entire color scheme every day of the week by merely pointing to a different CSS file and altering an image variable? Hmmm. I'm having a tough time thinking of any advantages...

What disadvantages did you encounter?

Honestly, there were several challenges and glitches we ran into along the way. First of all, since Wired News is a heavily ad-supported site, our advertising units were the cause of several important decisions. Our ad-serving partner basically requires that we use iframes to dynamically pull in ads from available inventory. Because of the iframe, we backed off of the idea that we'd be able to adhere to XHTML Strict rules, and settled for using the XHTML Transitional DTD. We were hoping to go all the way with the XHTML conversion, but our ad units and some other third-party content prevent us from doing so.

Our engineers also faced a huge archive of content that wasn't entered into our CMS with XHTML in mind. It's true that our stories exist in a database, separated from page templates and peripheral formatting. But writers, editors, and producers have been inserting stories into Vignette for years sans closing paragraph (</p>) tags. Unquoted attributes and uppercase html tags? We've got them in spades, and they're embedded in all past stories of the database. Fortunately, our chief engineer was able to write some code that scraped through the database looking for errors like this which would invalidate our markup. We don't make any claims about past archived content, but we've taken many efforts to make sure even stories from a few years ago are as valid as possible.

While conversion to XHTML and CSS definitely shaved off development time that would have normally been spent manipulating the code, it didn't come entirely easy or without cost. Our engineer, Aaron Jones, actually ended up rebuilding the majority of our Vignette templates from scratch. I ran into a steep learning curve, not with the Web standards themselves, but with the quirky rendering behaviors and inconsistencies in various browsers. Our writers and editors must get used to some new rules when generating the day's stories. Our management also has to accept the fact that some older or smaller browsers may be getting an un-styled version of our content. We know that some users may prefer getting an un-styled version, because they'll finally be able to read our content in the browser they use. But some users may write in, frustrated and complaining about the horrible design decisions we've made. Those feedback loops will have to be managed appropriately.

For Wired News, we analyzed the traffic reports to get a picture of our user base. From looking at our data, we predict there could be as much as 14% of our users who will get the un-styled version of our content. That's a significant percentage when we're used to our pages looking the same in every browser.

Were there any other lessons you learned during the conversion process?

As many times as I heard the message that design of content should be addressable separately from the content itself, I don't think I realized the full benefits of doing so until we actually went through the process of separating them. We're now set up to propagate small design changes instantly across the entire site, without touching one bit of html markup. And if we need to make a template change, or add in a piece of content, our data is now structured in a way that surprises our developers in how easy it is to make a change.

Wired News is also dramatically more accessible, without much concentrated effort at making it so. Sure, we now pay more attention to our image alt attributes, and try to use heading tags appropriately. But a huge decrease in the amount [sic] of presentation markup tags also plays a big role too. Since all of our content is also completely accessible sans style sheets, I think we get the best of both worlds: a well-designed, highly stylized, true-to-our-brand website which adapts in different browsing environments.

What would you say to a site developer considering a similar conversion to standards-based layout, either with simple tables or no tables at all?

I think the conversion is a matter of taking into account several considerations. Are you tired of the maintenance headaches caused by the glut of extra tables and presentation tags in your markup? Can you see an advantage to reducing file size and speeding up download time? Do you have the resources to invest in making some significant changes up front which can save time and money in the long run? Is it important that your documents be backward-compatible with older or specialized browsing environments? And forward-compatible with browser applications of the future? Are you comfortable with the idea that your documents may not look exactly the same in every browser?

If the answer to one or more of those questions is "yes," chances are, you could be ripe to make the leap. Keep in mind the last disadvantage I just mentioned. Not every browser will be able to support the CSS used to replace table layouts. In those cases, the browser will either render your documents with many bugs, or you'll have to consciously choose to hide certain bits of style information from browsers that can't support CSS adequately enough. What are the browser percentages of your current user base, and what about your target user base (which may be different)? Will the majority of your users be viewing your pages with a newer, standards-compliant browser?

Going through the initial conversion may take longer for some sites, depending on the organization and complexity of the data. Pages which draw their content from a database will probably require less labor to convert than sorting through hundreds of flat html files that have mixed structures. Whatever the situation, if the conversion is something deemed worthwhile, it's an excellent opportunity to restructure your data the right way, so it can ultimately be as flexible as you need it to be.

Original Document Information

  • Author(s): Eric A. Meyer
  • Last Updated Date: October 11th, 2002
  • Copyright Information: 2001-2003 Netscape

Document Tags and Contributors

Tags: 
  • Web Development
  • Web Standards
 Contributors to this page: kmag, Sheppy, trevorh, George3, kohei.yoshino, Mathieu Deaudelin
 Last updated by: kmag, Apr 27, 2017, 5:39:58 AM

  1. .htaccess ( hypertext access )
  2. <input> archive
  3. Add-ons
    1. Add-ons
    2. Firefox addons developer guide
    3. Interaction between privileged and non-privileged pages
    4. Tabbed browser
    5. bookmarks.export()
    6. bookmarks.import()
  4. Adding preferences to an extension
  5. An Interview With Douglas Bowman of Wired News
  6. Apps
    1. Apps
    2. App Development API Reference
    3. Designing Open Web Apps
    4. Graphics and UX
    5. Open web app architecture
    6. Tools and frameworks
    7. Validating web apps with the App Validator
  7. Archived Mozilla and build documentation
    1. Archived Mozilla and build documentation
    2. ActiveX Control for Hosting Netscape Plug-ins in IE
    3. Archived SpiderMonkey docs
    4. Autodial for Windows NT
    5. Automated testing tips and tricks
    6. Automatic Mozilla Configurator
    7. Automatically Handle Failed Asserts in Debug Builds
    8. BlackConnect
    9. Blackwood
    10. Bonsai
    11. Bookmark Keywords
    12. Building TransforMiiX standalone
    13. Chromeless
    14. Creating a Firefox sidebar extension
    15. Creating a Microsummary
    16. Creating a Mozilla Extension
    17. Creating a Release Tag
    18. Creating a Skin for Firefox/Getting Started
    19. Creating a Skin for Mozilla
    20. Creating a Skin for SeaMonkey 2.x
    21. Creating a hybrid CD
    22. Creating regular expressions for a microsummary generator
    23. DTrace
    24. Dehydra
    25. Developing New Mozilla Features
    26. Devmo 1.0 Launch Roadmap
    27. Download Manager improvements in Firefox 3
    28. Download Manager preferences
    29. Drag and Drop
    30. Embedding FAQ
    31. Embedding Mozilla in a Java Application using JavaXPCOM
    32. Error Console
    33. Exception logging in JavaScript
    34. Existing Content
    35. Extension Frequently Asked Questions
    36. Fighting Junk Mail with Netscape 7.1
    37. Firefox Sync
    38. Force RTL
    39. GRE
    40. Gecko Coding Help Wanted
    41. HTTP Class Overview
    42. Hacking wiki
    43. Help Viewer
    44. Helper Apps (and a bit of Save As)
    45. Hidden prefs
    46. How to Write and Land Nanojit Patches
    47. Introducing the Audio API extension
    48. Java in Firefox Extensions
    49. JavaScript crypto
    50. Jetpack
    51. Litmus tests
    52. Makefile.mozextension.2
    53. Microsummary topics
    54. Migrate apps from Internet Explorer to Mozilla
    55. Monitoring downloads
    56. Mozilla Application Framework
    57. Mozilla Crypto FAQ
    58. Mozilla Modules and Module Ownership
    59. Mozprocess
    60. Mozprofile
    61. Mozrunner
    62. Nanojit
    63. New Skin Notes
    64. Persona
    65. Plug-n-Hack
    66. Plugin Architecture
    67. Porting NSPR to Unix Platforms
    68. Priority Content
    69. Prism
    70. Proxy UI
    71. Remote XUL
    72. SXSW 2007 presentations
    73. Space Manager Detailed Design
    74. Space Manager High Level Design
    75. Standalone XPCOM
    76. Stress testing
    77. Structure of an installable bundle
    78. Supporting private browsing mode
    79. Table Cellmap
    80. Table Cellmap - Border Collapse
    81. Table Layout Regression Tests
    82. Table Layout Strategy
    83. Tamarin
    84. The Download Manager schema
    85. The life of an HTML HTTP request
    86. The new nsString class implementation (1999)
    87. TraceVis
    88. Treehydra
    89. URIScheme
    90. URIs and URLs
    91. Using Monotone With Mozilla CVS
    92. Using SVK With Mozilla CVS
    93. Using addresses of stack variables with NSPR threads on win16
    94. Venkman
    95. Video presentations
    96. Why Embed Gecko
    97. XML in Mozilla
    98. XPInstall
    99. XPJS Components Proposal
    100. XRE
    101. XTech 2005 Presentations
    102. XTech 2006 Presentations
    103. XUL Explorer
    104. XULRunner
    105. ant script to assemble an extension
    106. calICalendarView
    107. calICalendarViewController
    108. calIFileType
    109. xbDesignMode.js
  8. Archived open Web documentation
    1. Archived open Web documentation
    2. Browser Detection and Cross Browser Support
    3. Browser Feature Detection
    4. Displaying notifications (deprecated)
    5. E4X
    6. E4X Tutorial
    7. LiveConnect
    8. MSX Emulator (jsMSX)
    9. Old Proxy API
    10. Properly Using CSS and JavaScript in XHTML Documents
    11. Reference
    12. Scope Cheatsheet
    13. Server-Side JavaScript
    14. Sharp variables in JavaScript
    15. Standards-Compliant Authoring Tools
    16. Using JavaScript Generators in Firefox
    17. Window.importDialog()
    18. Writing JavaScript for XHTML
    19. XForms
    20. background-size
    21. forEach
  9. B2G OS
    1. B2G OS
    2. Automated Testing of B2G OS
    3. B2G OS APIs
    4. B2G OS add-ons
    5. B2G OS architecture
    6. B2G OS build prerequisites
    7. B2G OS phone guide
    8. Building B2G OS
    9. Building and installing B2G OS
    10. Building the B2G OS Simulator
    11. Choosing how to run Gaia or B2G
    12. Customization with the .userconfig file
    13. Debugging on Firefox OS
    14. Developer Mode
    15. Developing Firefox OS
    16. Firefox OS Simulator
    17. Firefox OS apps
    18. Firefox OS board guide
    19. Firefox OS developer release notes
    20. Firefox OS security
    21. Firefox OS usage tips
    22. Gaia
    23. Installing B2G OS on a mobile device
    24. Introduction to Firefox OS
    25. Mulet
    26. Open web apps quickstart
    27. Pandaboard
    28. PasscodeHelper Internals
    29. Porting B2G OS
    30. Preparing for your first B2G build
    31. Resources
    32. Running tests on Firefox OS: A guide for developers
    33. The B2G OS platform
    34. Troubleshooting B2G OS
    35. Using the App Manager
    36. Using the B2G emulators
    37. Web Bluetooth API (Firefox OS)
    38. Web Telephony API
    39. Web applications
  10. Beginner tutorials
    1. Beginner tutorials
    2. Creating reusable content with CSS and XBL
    3. Underscores in class and ID Names
    4. XML data
    5. XUL user interfaces
  11. Case Sensitivity in class and id Names
  12. Creating a dynamic status bar extension
  13. Creating a status bar extension
  14. Gecko Compatibility Handbook
  15. Getting the page URL in NPAPI plugin
  16. Index
  17. Inner-browsing extending the browser navigation paradigm
  18. Install.js
  19. JXON
  20. List of Former Mozilla-Based Applications
  21. List of Mozilla-Based Applications
  22. Localizing an extension
  23. MDN
    1. MDN
    2. Content kits
  24. MDN "meta-documentation" archive
    1. MDN "meta-documentation" archive
    2. Article page layout guide
    3. Blog posts to integrate into documentation
    4. Current events
    5. Custom CSS classes for MDN
    6. Design Document
    7. DevEdge
    8. Developer documentation process
    9. Disambiguation
    10. Documentation Wishlist
    11. Documentation planning and tracking
    12. Editing MDN pages
    13. Examples
    14. Existing Content/DOM in Mozilla
    15. External Redirects
    16. Finding the right place to document bugs
    17. Getting started as a new MDN contributor
    18. Landing page layout guide
    19. MDN content on WebPlatform.org
    20. MDN page layout guide
    21. MDN subproject list
    22. Needs Redirect
    23. Page types
    24. RecRoom documentation plan
    25. Remove in-content iframes
    26. Team status board
    27. Trello
    28. Using the Mozilla Developer Center
    29. Welcome to the Mozilla Developer Network
    30. Writing chrome code documentation plan
    31. Writing content
  25. MMgc
  26. Makefile - .mk files
  27. Marketplace
    1. Marketplace
    2. API
    3. Monetization
    4. Options
    5. Publishing
  28. Mozilla release FAQ
  29. Newsgroup summaries
    1. Newsgroup summaries
    2. Format
    3. Mozilla.dev.apps.firefox-2006-09-29
    4. Mozilla.dev.apps.firefox-2006-10-06
    5. mozilla-dev-accessibility
    6. mozilla-dev-apps-calendar
    7. mozilla-dev-apps-firefox
    8. mozilla-dev-apps-thunderbird
    9. mozilla-dev-builds
    10. mozilla-dev-embedding
    11. mozilla-dev-extensions
    12. mozilla-dev-i18n
    13. mozilla-dev-l10n
    14. mozilla-dev-planning
    15. mozilla-dev-platform
    16. mozilla-dev-quality
    17. mozilla-dev-security
    18. mozilla-dev-tech-js-engine
    19. mozilla-dev-tech-layout
    20. mozilla-dev-tech-xpcom
    21. mozilla-dev-tech-xul
    22. mozilla.dev.apps.calendar
    23. mozilla.dev.tech.js-engine
  30. Obsolete: XPCOM-based scripting for NPAPI plugins
  31. Plugins
    1. Plugins
    2. Adobe Flash
    3. External resources for plugin creation
    4. Logging Multi-Process Plugins
    5. Monitoring plugins
    6. Multi-process plugin architecture
    7. NPAPI plugin developer guide
    8. NPAPI plugin reference
    9. Samples and Test Cases
    10. Shipping a plugin as a Toolkit bundle
    11. Supporting private browsing in plugins
    12. The First Install Problem
    13. Writing a plugin for Mac OS X
    14. XEmbed Extension for Mozilla Plugins
  32. SAX
  33. Security
    1. Security
    2. Digital Signatures
    3. Encryption and Decryption
    4. Introduction to Public-Key Cryptography
    5. Introduction to SSL
    6. NSPR Release Engineering Guide
    7. SSL and TLS
  34. Solaris 10 Build Prerequisites
  35. Sunbird Theme Tutorial
  36. Table Reflow Internals
  37. Tamarin Tracing Build Documentation
  38. The Basics of Web Services
  39. Themes
    1. Themes
    2. Building a Theme
    3. Common Firefox theme issues and solutions
    4. Creating a Skin for Firefox
    5. Making sure your theme works with RTL locales
    6. Theme changes in Firefox 2
    7. Theme changes in Firefox 3
    8. Theme changes in Firefox 3.5
    9. Theme changes in Firefox 4
  40. Updating an extension to support multiple Mozilla applications
  41. Using IO Timeout And Interrupt On NT
  42. Using SSH to connect to CVS
  43. Using workers in extensions
  44. WebVR
    1. WebVR
    2. WebVR environment setup
  45. XQuery
  46. XUL Booster
  47. XUL Parser in Python