As a Typekit user, you’ll have access to our library of high-quality fonts. Just add a line of JavaScript to your markup, tell us what fonts you want to use, and then craft your pages the way you always have. Except now you’ll be able to use real fonts. This really is going to change web design.

Also worth checking out, Jeff posted a preview of the Typekit home page yesterday. Looking forward to how this will change typography and design for the web. link

After grabbing a screenshot of the message, I dismissed the error and was allowed to view the horribly broken page of jumbled content. Upon seeing the page, it felt like the JavaScript message was more a confession of the site author’s incompetence rather than a warning about my browser’s state of compatibility.

Should you ever consider something similar, I would suggest a more favorable message:

Tweaks that should have worked had no effect, prompting me to try things that made absolutely no sense to try.

This bug was no exception. It took a lot of isolating and trying remote possibilities to come up with the solution that fixed it. I also mentioned different combinations of IE’s can drive a CSS author mad. This bug shows up in IE5.5, but not in IE5.0 (Win). IE5.5 certainly renders CSS a little better than its predecessor, but with IE5.5′s release and improvements, new bugs — which did not previously exist in IE5.0 — suddenly appeared. Some of those same bugs were carried into IE6.0.

The problem: A simple series of content boxes (I call them “modules”) appearing in succession within a 200-pixel wide sidebar. Nothing out of the ordinary, certainly nothing complex. Each module started with a title marked up with the <h2> tag. Each module’s title was followed by two generic paragraphs of text.

The example file I’ll provide is stripped down, with almost all design details removed. Titles were given a bit of style to reduce font size and top and bottom margins. For what I was creating, borders for each module only existed on the sides. I’ve exaggerated them to make this bug more obvious. To see it misbehaving, view this example of the bug in IE5.5 or IE6.0, then view it in any other browser to see the correct behavior. For those not fortunate enough to have either of those two Windows browsers, here’s a screenshot of the first and last modules, as rendered by IE6.0:

Notice how the text gradually slips further to the left for each module. The bug only begins to appear in the second module, then gets progressively worse for each module below. Until the last module’s text slips so far to the left, it gets clipped by the module’s container. The problem gets infinitely worse as more modules are added. No other browsers have problems rendering the text correctly.

Obviously, this problem wasn’t acceptable. I had no idea how many modules the client might need to stack together in the sidebar. I tried every trick in the book I knew to prevent the text from slowly slipping over. The problem was seemingly incomprehensible, as each module was completely independent of the next. The code was completely valid, and no containers overlapped each other. I tried it with the 200-pixel sidebar, and without. I removed padding, applied margins, removed the titles. No luck.

I walked away, went to lunch, then came back to find the root of the problem. I discovered the text was slipping to the left by four pixels from one module to the next. At the time, each of my side borders were only 2-pixels wide. So the text slippage between each module was equivalent to the width of left and right borders combined. I removed the side borders, the bug disappeared. (See example)

Ok, so it was the border. But the effect I was going for required the side borders. At one point I tried adding top and bottom borders to the module: Bam! problem solved. Turns out it’s actually the presence of a bottom border (any width) which fixes the bug. It makes no sense why a missing bottom border on one element would affect another element on the page. But in IE5.5/6.0, it does.

So the bug could ultimately be described as this: If left and right borders are applied to one container element without a bottom border, the side borders on the first container will adversely affect the text position in the next successive container element.

To fix my instance of the problem, I added a 1-pixel bottom border for each module, making it the same color as the module background to keep it mostly invisible. (In the example, background and bottom border are white.) Since the border isn’t necessary in all other browsers, I really didn’t want it there when it wasn’t needed. So I added one more rule to turn off the bottom border for them:

.module {
  margin:0 0 15px;
  border:4px solid #666;
  border-width:0 4px;
  border-bottom:1px solid #fff;
  padding:2px 10px;
  }
html>body .module {
  border-bottom-width:0;
  }

By using a child selector, that final zero-width border rule is hidden from all versions of IE/Win. (View the final solution) I also discovered that applying a width to each module also solves the text-slippage problem. But IE5/Win’s broken box model needs to be dealt with if the modules use left or right padding. And widths should not be necessary for individual modules, given that a width is already specified for the parent #sidebar. So I stuck with the add/remove bottom border trick to avoid the need to re-specify module widths.

This is just one example of the inexplicable bugs which caused delay for my latest project. If anyone else encounters the same bug, hopefully this example will save some of their hair, and prevent them from facing the same frustration.

Such is often the case when designing with CSS. When working with semi-complex layouts, I frequently encounter challenges that end up slowing me down. I’m getting familiar with these road blocks, and can often predict where I’ll find them. Having patience, or knowing what to try to get around them prevents head from going through monitor.

Without a doubt, the biggest challenge I encounter each time is in wrangling Microsoft’s Internet Explorer browser. This devil does not play fair. It often follows no rules, and its behavior defies all common logic. It will double margins for no apparent reason. Borders disappear, 62 pixels magically turn into 143 pixels. It dodges left when other browsers go right. I’ve decided to call this phenomenon “the IE Factor“. (Those familiar with authoring DHTML four or five years ago already know where I’m headed with this.)

While working on the final stretch of a client project last week, I got stuck in a patch of quicksand. Design was finalized long ago. The bulk of CSS was authored over the holidays. Mozilla, Firebird, Safari, and Opera were all rendering the design beautifully, give or take a few small hiccups. But the design still had a few major quirks in IE (both Windows and Mac versions). “Ok, no problem — I need to spend an hour or so squashing bugs in IE.” That hour turned into two full days. Days filled with head-scratching and mind-numbing deconstruction and isolation of declaration blocks and properties. Progress came to a screeching halt while I tried every trick in my book. Solving one problem revealed another. Making a fix for IE would throw off the other browsers. Tweaks that should have worked had no effect, prompting me to try things that made absolutely no sense to try. And lucky me, IE/Win and IE/Mac have completely different bugs.

To be fair, IE/Mac has a predictable set of bugs which have known workarounds. But as I stated above, IE/Win will defy all common logic. Which makes it such a difficult browser to troubleshoot. I don’t dwell on the box model problems in version 5.x. Those can be dealt with. It’s the idiosyncrasies of IE5.0, IE5.5, and IE6.0 together (or in different combinations) that will drive a CSS author mad.

At times, I thought about writing every one of my style sheet rules using child selectors, filtering IE/Win out completely and serving it the same unstyled version as Netscape 4. But of course, IE possesses too much market share to turn off a design for every person using it. My client couldn’t — and wouldn’t — agree with that type of decision. So I had to compromise on each bug. If I couldn’t find an acceptable solution, or beat IE into submission, I’d decide to turn off that feature or design attribute just for IE/Win. Nice hover effects over those icons? Sorry IE, you won’t get them. A nice little bottom border on this box, like EVERY OTHER BROWSER renders correctly without going into convulsions? Sorry IE, you don’t get that either. You’re too fragile for a simple border. What kills me is the extra markup I’ll sometimes give in and add, just to get IE to render a critical part of the design correctly.

On numerous occasions, I’ve been bogged down by Internet Explorer’s incomplete support of CSS. I spent an extra 2 weeks trying to figure out why IE was bungling the Wired News layout. I should have known that I’d encounter difficulty with my project last week. But those two days of lost time hit me hard. I was over-confident that I could catch anything IE threw at me, thinking I could solve it quickly and easily. Silly rabbit. In reality, I’ve now calculated the IE Factor can add upwards of an additional 10% in time and cost for each project, distorting the estimating process if it’s not figured in.

So, you could say I’m becoming familiar with the route. I’m learning the best paths to tread when constructing designs with CSS. I know the interesting segments, the boring stretches. Most importantly, I’ve started to recognize patterns, and can predict the areas that will slow me down. Specifically, I know about the IE Factor. I don’t like it one bit, but at least I can prepare, and expect to encounter it for each project. And I’m building up an arsenal of weapons for use against IE when it misbehaves in the future.

The browser wars are supposedly over. We’re supposed to be at peace now. Everyone is supposedly cooperating. We’re supposed to be living in an era where we don’t need to alter code and make unique design decisions for each browser. We’re close, but I don’t think we’re there yet.

Update: See one example of a bug which contributes to the IE Factor, described in detail in this entry.

Switch off the style sheets — as Cameron allows you to do via a link in the header — and note that all of those presentation effects slip away, leaving a structured document. OK, so if you look under the hood, you might notice some extraneous HTML that has no purpose other than to act as a hook for style (ala, the Zen Garden‘s markup). Cameron is up front about this, and even laments the lack of full standards support in certain browsers:

“… pages must still be littered with redundant mark-up in order to achieve graphical effects beyond your standard two-column, black-and-white blog.”

In conjunction with the release, Mozilla announces a nicely designed beta version of the upcoming Mozilla.org web site with heavy design contributions from our well-known garden proprietor, Dave Shea. Well done, Dave and Mozilla team. An excellent idea to put the site out in front of users as a beta, let people respond with praise, criticism, and suggestions, then make improvements before official launch.

About two months ago, I switched from IE6 over to Firebird as my default browser, and haven’t looked back. I’m ashamed it took me that long to switch. Firebird is an excellent, powerful standalone browser, free of the extras loaded into the larger Mozilla application. The base install alone has enough features to win over converts. And if those aren’t enough, a boat-load of extensions are available as add-ons. The new Firebird site (Update: front page has since been replaced with original design) presents a product tour complete with lots of screenshots, as well as a chart (Update: link removed, as chart no longer exists) comparing Firebird with IE6, Opera, Mozilla, and Netscape. The Firebird site design is a little over the top with the flame theme. But I like seeing the Foundation take these steps with the Mozilla.org beta site and the Firebird product site. They’re pushing toward a simpler, yet more complete sell of their product line. It will help spread the word and let many more know of these fine alternatives.

If you don’t already have Firebird installed, you should go download it today and give it a whirl. I highly recommend it.

The world of dynamic, database-driven content and conditional server-side scripting brings significant advantages to site owners and content producers. Personal publishing systems and large-scale Content Management Systems add layers of abstraction, allowing the content (or data) to live outside the scripts which assemble content, and the XML or HTML which provides its structure.

These tools allow us to take a large step in the right direction. But they’re only one piece of the mantra above. Technically, we could split this separation concept into two parts. “Keep content separate from structure” and “keep structure separate from presentation“. The first part can be handled by almost any CMS or publishing system, as I’ve already mentioned. The second part is possible with the use of a style sheet language, such as CSS.

Reality?

But can presentation rules exist entirely separate from structure? CSS selectors build conditional rules which depend on document structure. Selectors specify conditions such as where an element appears in the document, or they hone in on an element based on a pre-existing application of classes and/or IDs. Subconsciously, we may realize our style sheet is a one-off, inherently bound to the document or site it defines. But a document is not at all bound to one style sheet, as the CSS Zen Garden competently demonstrates.

Design changes often require manipulation of more than just the style sheet. This is a reality. Content needs to shift places, or new content needs to be added. We’re constantly learning better ways to mark up our content with leaner HTML, replacing old hacks with better methods. But we need to remind ourselves that we won’t — and in some cases, shouldn’t — always have the luxury of markup control when changing or applying new styles. In some cases, final markup output might be controlled by a deeply embedded CMS under the dominion of stubborn engineers. In other cases, portions of markup might be served by third-party ad vendors and content partners.

In the spirit of keeping structure separate from presentation, ideally, the markup shouldn’t need to change if written correctly the first time. But we might not have power to change existing markup to better suit our purposes. We need to break ourselves of relying on the ability to affect markup in order to change design. When we talk about redesigning a CSS-based site in a matter of hours or days, compared with weeks or months, we’re implying the changes occur in the CSS alone, leaving the markup (mostly) untouched.

Old Habits Die Hard

Unfortunately, some of us have become accustomed to changing markup structure at will. Publishing systems controlled by templates allow endless manipulation of front-end code. We tweak templates, instantly distributing changes throughout hundreds or thousands of web pages with the click of a button or two. Personal sites and weblogs are often controlled by one person or a small group, providing a distinct advantage over larger commercial sites. Changes to markup structure and design happen any time, without need to consult producers or engineering teams.

The concept of keeping structure separate from presentation becomes obfuscated when we make design changes by manipulating both markup and CSS at the same time. Learning the effects of CSS by tweaking markup is one thing. So is stripping out old table hacks and font tags during a massive conversion. However, when we make small design adjustments by adding extra <div> tags or class attributes, then alter the CSS to take advantage of those markup changes, we confuse the concept of independent structure and presentation. We may even continue bad habits and form inappropriate expectations along the way. I write from my own experience. What’s yours?

Unsuspecting news organizations are reporting this as a (ahem) helpful service which “provide some clues to help you find the sites you were looking for“. But ultimately, this appears to be nothing more than another land-grabbing, money-making scam. The page to which all unregistered domains redirect also provides a search form and a short list of categories pointing to results. Many of the first few results are all paid, sponsored links apparently coming from Overture. VeriSign themselves have estimated that .com and .net domains get mistyped approximately 20 million times per day. You can imagine the traffic VeriSign is suddenly forcing their way as a result of this change.

See Site Finder yourself by trying any non-existent domain, like blipvip.com or veribadsign.com.

Understandably, network administrators and web geeks everywhere are furious about all kinds of concerns this raises: privacy, failed anti-spam measures, and others which go beyond my understanding. What I find interesting, is that many ISPs and backbone providers are fighting back by blocking the IP address(es) associated with VeriSign’s Site Finder. The nonprofit Internet Software Consortium is already writing an urgent patch for BIND, a service used by many ISPs to help resolve domain names to the IP addresses of the servers which host each site. The patch will allow ISPs and other DNS admins “to restore control by identifying and then ignoring data from Site Finder“.

With so many people, companies, and organizations upset at VeriSign for such an unethical move, we’ll see how long this scam lasts. Stay up-to-date on the issue by checking Google News or following the huge Slashdot thread on the subject.

Update: Wired News posted the Associated Press version of the story: VeriSign Takes Sting out of Typos, and Declan McCullagh just wrote a good piece for News.com: VeriSign redirects error pages.

Update 2: Since writing this entry, someone snatched up the domain veribadsign.com, so the link above no longer redirects to Site Finder.

In discussion following the post, Sunny effectively sums the past couple days posts (1, 2, 3, 4) on standards and semantics in one simple sentence: “B is the semantically correct approach although A will be valid mark-up.” (Noted that C would also be valid using a Transitional DTD.) Other interesting perspectives already exist in the comments.

Here’s to hoping Dan continues the series, probing deeper into the issues with more complex questions. And that he somehow aggregates the questions and some of the resulting discussion into a thoughtful resource.

Jason makes some valid points in his post. In particular, I agree that the idea of “standards-compliance” often borders on religious zealotry. Sought for no other reason than to attain a simple badge which supposedly “validates” the effort taken to get there. It’s as if some designers/developers strive to follow all the rules just to see those magic words when they get to the pearly gates: “Well done thou good and faithful coder. This page is valid ____!“

As a community, we’ve placed too much emphasis on the “valid” part of standards-compliant design. Some may even claim I did so just yesterday when I pointed out a few small errors on Macromedia’s pages as I closed out the entry. (It wasn’t intended as such, but rather, to quell naysayers about any “lack of compliance” based only on minor technicalities.)

As designers, we’ve danced around the idea of “semantics”, because we know the reality of browser support for CSS. We’re not willing to sacrifice all form for the sake of semantic purity. We don’t live in a world of perfect CSS support in all browsers yet. This means we insert plenty of generic divs or spans as hooks to add style to our pages. I think I can speak for everyone on Jason’s list in saying we’ve all made huge efforts to improve the semantic quality of our sites and those we design for our own companies and clients. But I know semantic purists could pin me to the mat if they picked apart the markup I’ve produced.

Where we succeed in achieving standards-compliance and semantic richness at the same time, we could certainly do a better job of highlighting the structure of our markup and why certain elements were chosen over others. But in doing so, we need to be prepared for the criticism that comes from those who expect absolutism. Once we start pointing out how we’ve made portions of our pages more meaningful, the portions which aren’t will get ripped apart. I’ve witnessed debates on semantics — they’re often endless spirals, leading tortuously to black holes of confusion and disagreement.

A prevailing concept in Jason’s post is something I couldn’t easily accept at face value:

[...] what I feel like is being implied in the effort to get more people to embrace standards compliancy is that coding a page in valid XHTML with valid CSS involves improving the semantic meaning of the content…which is just not true.

It is true that developers can potentially produce valid XHTML/CSS pages which end up semantically equivalent to a pile of junk. But it seems Jason is trying to separate web standards and semantics too far apart:

Coding web documents in valid XHTML doesn’t make them semantically useful nor does coding semantically correct documents mean the documents are standards-compliant

As developers learn and begin to work in XHTML and CSS, I believe they do often begin to automatically generate more meaningful markup. As the power of CSS unfolds, developers realize they can actually use numbered headings (<hn>) as heads and subheads, and gain even more control over them using CSS than using the old table and a few font/bold tags to affect style. Also notice how lists (ordered, unordered, and definition) are being used much more often in XHTML/CSS sites, as opposed to the old way of generating groups of items:


item<br>

or even:


<div>item</div>

I believe we’ve seen big improvements in semantics as XHTML and CSS have grown in popularity. Granted, semantic richness isn’t always the first direction people go when they start learning XHTML/CSS. However, it’s a fairly natural tendency for someone to discover what it means to use more meaningful markup as it gets stripped down to the basics. A page full of nothing more than divs, spans, and br’s might be perfectly compliant in its use of standards. But generic markup like this will appear anemic in comparison to well-structured documents. It’s a learning curve which comes in small bits and pieces at first, but then rapidly accelerates as familiarity with the potential increases.

There’s a challenge in the last sentence of Jason’s post which should not go unheard. We do need to demonstrate more often how standards-compliance and semantics work together. And why one without the other won’t get us much further than where we’ve been in the not-so-distant past.

With only a 480×320 resolution screen and 29MB of memory, this handheld will be a far cry from even the most sub-compact full-featured notebooks. But we would certainly be remiss if we don’t keep an eye on the effect these devices will have on the way users will see and experience the Web of tomorrow. Micro-technology which fits in palm-sized computers is here. Just look at Apple’s 30GB hard drive used in the latest iPod. A 512MB DDR memory module which fits in my new laptop is half the size of the standard SODIMM. Subnotebooks slightly larger than the UX50 handheld, with computing power equal to low-end laptop computers, have already hit the mainstream in Japan, and are available in the U.S. from small-quantity importers. North American markets may adopt micro-technology more slowly, but it will certainly be here eventually. The real challenge falls on industrial designers tasked with designing tiny computers which remain usable, efficient, and attractive to a typical consumer.

Some subnotebooks will support 800×600 resolution and higher. Other devices like these handheld-wanna-be-notebooks won’t. Along with these devices, a whole new crop of web browsing apps will surface in addition to the ones we already have. Hopefully, they’ll support the CSS handheld media type, and encourage the use of leaner, structured XHTML. However, once devices like this begin to fill breast-pockets of executives and shoulder bags of early-adopting gadgeteers, kiss goodbye the assumption that one “minimum resolution” exists to which we can design any interface.

Of particular note, once again, is Dan’s report that the Inc.com home page file size dropped from 52KB to 24KB, down by 54%. Almost the exact same percentage as the Adaptive Path and Wired News redesigns. See a viable trend emerging here?

Chalk up another huge media site (17+ years and 11,000 pages of content) which successfully made the transition to XHTML for markup and CSS for tableless layout.

As the market for standalone browsers shrinks even smaller, it leaves me wondering how much longer we’ll continue to see completely free browser distribution and innovation if the application is not already developed by a major OS company. Both Microsoft and Apple can market the heck out of IE and Safari, respectively, effectively lumping the browser in as a benefit of using a particular OS. Opera Software already charges a small fee for the ad-free version of their browser. Several other small browser makers do something similar. Even with a couple million streaming in from AOL over the next two years, and possibly more from Red Hat and Sun Microsystems, is it possible for Mozilla to continue to exist without starting to charge even nominal amounts for key product upgrades? The mainstream public will never [be reluctant to] pay for a browser upgrade as long as larger companies are still tossing in browsers for free, or as long as the Web continues to “work” in the free browser they already have.

It would also be great to see some technical details about the programming side — MT plugins used, tricks, etc. I’m doing development with MT, so such details can be very helpful.

To reiterate from Wednesday’s entry, Jay played a major role in building out most of the pages and PHP scripts for the new Adaptive Path site, and also customized AP’s Movable Type setup to generate and publish key portions of the site. He didn’t start out intending to write a long response. But as tends to happen when someone is passionate and knowledgeable about a subject, a lot can be said or written. Whether you use Movable Type or not, the information Jay revealed in his response is too valuable to be left buried in one of the many comments on that entry. So I asked him if I could at least pull it up to it’s own entry, potentially exposing it to a wider audience. He agreed. So here it is, in its entirety:

###

Hey Leonya, most of the backend for Adaptive path is pretty simple right now. The whole site is controlled by four Movable Type blogs: Appearances, Essays, News and static content.

The appearances blog outputs team appearance content on http://www.adaptivepath.com/team/ and http://www.adaptivepath.com/team/appearances.php.

The Essays blog controls output of the individual essays as well as the essays index and the essays archive index. It also produces a listing of the latest essay by each team member on each of their individual pages. Each entry in the blog is a full essay with excerpt and is categorized by author and subject which makes for easy indexing down the road as well as the conditional output to the team members’ pages.

The most exotic wrestling with Movable Type on the AP site is the news blog which contains all of the other dynamic content on the site (including Articles Elsewhere, Essay Announcement, Interview and News). These seemingly disparate types of information are output differentially using categories (as with the team members essays).

The static content blog is something I started doing recently with Jad Fair (http://www.jadfair.com). Essentially the blog contains no entries, but only templates and template modules. In a perfect world (which AP will reach when we finish up later this year), every single piece of static text and all image tags will be editable through the Movable Type interface obviating the need for anyone to go in an edit files on the file system or to hunt through hundreds of Movable Type templates.

With Jad Fair, I made a gateway page with direct links into every part of the system that Jad would have to use (screenshot). This was important because Jad’s system is even more complicated than the Adaptive Path site is currently and Jad is a novice when it comes to web design so I didn’t want to present him with a very steep learning curve.

If you look at the screen shot, you’ll notice that from that page, Jad can not only access every part of his site, but can also get many different views of all of the entries in the system in every blog. There are also links to create new entries and, in the static content section, links to each template module containing static text. This is essentially what will happen later with Adaptive Path.

We also strived to keep repeating elements out of the templates so every page sets a certain number of variables (main/sub page flag, layout type, and title) and includes the header, footer, announcement box and mailing list box via PHP.

The header file is not static HTML but in fact a full-blown PHP script which sets up functions for use throughout the site and handles differential HTML output between sections as well as top-level pages vs. subpages (e.g. /team vs /team/veen.php) and more…

Lastly the announcement box is a nice piece of coding which essentially dynamically outputs the most important announcement relevant to the current section being viewed. The script initially searches for the top-level (site-wide) announcement file in the web document root directory. If it exists, the contents are read and displayed as the PHP include on a site-wide basis.

If the top-level announcement file does not exist then the top-level section directory is searched next. For instance, if you are loading this essay, then the script would look in the /publications directory for an announcement box relevant to the publications section and that would be displayed regardless of how deeply you descend in that section.

In this way, each section can have its own custom announcement box, or, if there is really big news, they can all be overridden by the main announcement box file.

Needless to say, all of these files can be edited via the static content blog described above.

There are many other things in store for Adaptive Path later in the year, but I’m not going to give away any surprises at the moment. Eventually, as soon as I get some time NOT developing sites, I’ll write up a lot of these things that I do with each client in an article in an online web design zine to be named. I will also explain how, with my most recent client, I pulled together the Movable Type and phpBB user authentication systems for a universal login and seamless integration on the site. Fun stuff!

In closing, I will say that a large part of making PHP and Movable Type work for clients is customizing the MT interface for their needs and making things drop dead simple. After development has ended, my account becomes the administrator account and can be used to control everything and anything but is rarely accessed. All user accounts are set up with permissions to do only the things that are necessary for each blog. On a blog with no categories, no one has permission to edit categories. On the static blog, the only two actions available to people are template editing and rebuilding. This strips down the interface to the bare essentials. Of course, in the case that a gateway page exists, it’s hardly necessary to even navigate with the MT system itself since all links are direct links to the parts of the system needed.

That’s all folks!

[Originally posted by Jay Allen as Comment #80 on a July 9 entry.]

One consistent HTML document serves as the foundation for multiple design iterations of the description page. New versions are created simply by importing different CSS files. Each of the five themes use basic and advanced styling techniques to create noteworthily unique effects. Each theme should be carefully studied and examined.

Anyone is welcome to browse and enjoy that which already exists. In the true spirit of a communal garden, experienced practitioners (graphic artists) are invited to make their own contributions, helping to grow, enhance, and cultivate the ideas and examples contained within.

Dave noted in an email response that he’s tired of seeing such a huge gap between the talented and artful design crowd and the web-standards-based structure crowd. I couldn’t agree with him more. I’ve said it once, I’ll say it again: sites built with web standards need not be ugly. We need more examples which show the integration of beautiful design and solid structure. Mezzoblue’s Zen Garden is certainly one of them. It’s this kind of stuff which inspires me to the core and makes me want to contribute.

The Good: Looks pretty. Navigation is rendered as an unordered list, and uses JavaScript to pop-down transparent submenus, also created with unordered lists. In addition to the conversion and redesign, the Cingular team successfully abandoned the HTML table element on just about every page. Tables are appropriately pulled out of pocket only for pages which display tabular data, like Rate Plans for the San Francisco Bay Area.

The Bad: The site takes forever to load. Not typical of sites which make a conversion to lean XHTML+CSS. A friend had trouble accessing the site from his IE5/Mac browser. The front page also crashed my version of Netscape 4, possibly because of the large amount of JavaScript used. Crashing or choking browsers — no matter how old or obscure — is not something we like to see in sites which move toward standards-compliance. Despite Cingular’s ambitious use of the XHTML 1.0 Strict doctype for their pages, the front page is filled with multiple validation errors. Inside pages appeared to be a bit cleaner after a brief glance through the site. Speaking from experience, I know how difficult Vignette (the Content Management System used by both Wired News and Cingular) can be to wrangle in the errors that keep a site from validating. But there are many simple mistakes which should be easy to knock off the list. Hopefully the team is already seeking to do so, if not just for their own assurance that code will behave and display in browsers as intended.

Accessibility: Notwithstanding major improvements gained in the conversion, basic accessibility problems still plague the site. For instance, without stylesheets, multiple navigation links and header information fill the top of the page, yet no means of skipping over these elements to main content exists. Alt texts in <img> elements do not always match the visible text embedded within the image, and in certain places where it could be helpful, does not exist at all. Because of the simple, mostly tactile (and now, voice-activated) interfaces, mobile phones can easily be used by blind customers with little more than simple memorization of functions and button placement. Companies like Cingular can’t afford to have inaccessible web sites. They have a product and service which transcends visual impairment. Now that they’ve come this far with the site (and a good ways they’ve come), Cingular should spend the money, hire an Accessibility expert, (disclaimer: that’s not me) and go the full distance.

When we launched Wired News five months ago, it felt like we were jumping off a huge cliff, not knowing for sure what would happen to development costs, traffic, and revenue. As more commercial sites realize and demonstrate the benefits of moving to web standards, the leap of faith other sites will need to make gets smaller and smaller. When sites like ESPN — with 40 million page views per day — make the conversion and can talk about mind-boggling numbers of bandwidth savings, what was once a leap of faith eventually shifts to pure business logic.

So hats off to Daigo Fujiwara, Dan Cederholm, and the rest of the Fast Company web team. Not only have they joined ranks with other leading sites who have made the leap. But they also charge out of the gates on their first day with completely valid XHTML 1.0 Transitional markup.