Coding to standards

Zeldman‘s article in the Digital Web Magazine, 99.9% of websites are obsolete has already generated a fair bit of discussion, but because I’m so self-important, I thought I’d pitch in my $0.02.

Yahoo’s front page is served millions of times per day. Each byte wasted on outdated HTML design hacks is multiplied by an astronomical number of page views, resulting in gigabytes of traffic that tax Yahoo’s servers and add Pentagon-like costs to its overhead.

The idea that inefficient code is expensive has never really crossed my mind before. I’ve never worked on a site where an extra tag would have any effect on the cost of the website. However, blow that up to Yahoo-scale hits, and I can see how it would. I have, for a long time, when writing Cold Fusion, minimized the output from it. I read, back in the days of Cold Fusion 2.0 that extra white-space created by Cold Fusion can add to processing time, so I quickly learned all the tricks to minimize the whitespace created by CFML.
Until I delved into CSS, I’d never realised how much extra space ‘traditional’ HTML took up. Writing the Oak Bay Soft Trends website, I wrote the first version in tables & spacers (or traditional layout). I’d already moved from using font tags, so that reduced some space used. However, when I decided to take the leap and generate a fully table-less layout, while my stylesheets grew by 20 or 30 lines, I probably lost 100 lines of code, along with at least 10 spacer images per page. Yes, the spacer was less than 1 Kb in size, but blown up and multiplied, it all adds up.

What do developers mean by “backward compatibility?” They mean using non-standard, proprietary (or deprecated) markup and code to ensure that every visitor has the same experience, whether they’re sporting Netscape Navigator 1.0 or IE6. Held up as a Holy Grail of professional development practice, “backward compatibility” sounds good in theory. But the cost is too high and the practice has always been based on a lie.

Another project I’ve been working on, Bookbuffet, has gone through some of this. Originally, this site was purely CSS-2, no tables or anything. However, it uses 3-columns that are divided by a 1-pixel border. It is, as far as I can tell, impossible to achieve this in CSS. In it is easy to do with tables. And so I made the call to use tables for the skeleton of the code, and use CSS for all positioning, formatting within the tables. Which seems like a decent compromise. It was all looking fine and dandy across the version 6 browsers on the PC (Mozilla included). In older PC browsers, it looked pretty horrible, but there was a big header up top telling people to upgrade, which is as intended. However, I’d yet to test it on a Mac. The mozillas and netscapes were fine. IE 4 Mac, however, was horrible. First, it passed the standards-compliant browser test, even though it isn’t. So I added some javascript to counter that. Then in IE 5, there was all sorts of goofy layout things. It seems to have some nesting issues, and it was compounded by my inability to add & subtract (for the ‘Ç’ hack for floating elements). So I fixed that. However, this seems to have done some serious damage to how the site displays in Opera. For now, I’ve made the command decision to ignore Opera, hoping that Opera 7, rewritten with better DOM support will make it better (as things that make the site display properly in Opera seem to break it in IE 5 Mac) (second aside – every other browser appears pretty consisten across platforms, except for IE PC vs IE Mac. Grrrrr).

But now, I’ve discovered that the client, and possibly a fair percentage of the target audience uses AOL. I don’t know what versions. What I do know is that the site appears to break in whichever version of AOL the client is looking at it in. I’ve heard horror stories about AOL’s browser, but not having an AOL account, I’ve currently no way of testing this myself. But if AOL’s browser doesn’t support these standards, and they can’t upgrade to a ‘normal’ browser (or can they? how AOL works is a mystery to me), I may be forced to write a ‘backwards compatible’ version of this site, just to satisfy the percentage of users (not to mention the client) that uses AOL. Which I really, really hope I don’t have to do.

4 Replies to “Coding to standards”

  1. I’m facing up to the fact that I’ve been designing websites for ten years now.

    Part of me is getting grumpy about all this CSS/XML/etc stuff. Change is bad! I’ve thrived in this environment of sloppy standards and loose goals for a decade. Harumph!

    Anyway, I realize it’s time to update my coding skills. Part of me was hoping that I would just be working in Photoshop and Flash making pretty pictures and living off the technical fat I’ve been storing over the years. Alas, the dream is over.

    Maybe I’ll just retreat into print 🙂

    Or, um, become an instructor at a local Internet school, and, well, write a book. Or something.

    I may as well buy my porch swing now, eh? So I can sit on my stoop in Yaletown, drink rum and watch the whippersnappers going about everything wrong and ruining the neighborhood.

  2. I’m facing up to the fact that I’ve been designing websites for ten years now.

    Part of me is getting grumpy about all this CSS/XML/etc stuff. Change is bad! I’ve thrived in this environment of sloppy standards and loose goals for a decade. Harumph!

    Anyway, I realize it’s time to update my coding skills. Part of me was hoping that I would just be working in Photoshop and Flash making pretty pictures and living off the technical fat I’ve been storing over the years. Alas, the dream is over.

    Maybe I’ll just retreat into print 🙂

    Or, um, become an instructor at a local Internet school, and, well, write a book. Or something.

    I may as well buy my porch swing now, eh? So I can sit on my stoop in Yaletown, drink rum and watch the whippersnappers going about everything wrong and ruining the neighborhood.

  3. I’ve also been having fits developing for AOL. The most frustrating thing about AOL is not just that their browser doesn’t support many conventional functions, such as Javascript onBlur() and onFocus(), but that there is virtually zero support for developers provided by AOL. They do maintain a joke of a developers’ support site, but it says nothing about common problems faced by developers.

    For example, my site depends on popup windows for functionality, including an instant messaging system. The instant messaging system requires that a minimized popup window remains open and refreshing in the background to check for messages in the database. When a message is found the popup window uses Javascript onFocus() function to bring itself to the front of the screen where the user can see it. Works great in all recent versions of IE and NS, but guess what? AOL treats their “browser” as the one and only window, so onFocus() or onBlur() doesn’t affect the popup windows, only the main window. So, for example, onBlur() doesn’t hide the instant monitoring popup, it hides the entire AOL browser. And the AOL development site has no info on this whatever, nor is there any way to contact AOL for technical support to what must be a common problem for developers.

    I have been unable to find any Javascript work around that correctly manages the popups, including one forum suggestion which was to use onLoad = self.blur() instead of window.blur(). So I have had write a completely different instant messaging script for AOL that involves refreshing an empty graphic that is created by a PHP script. This was not a simple process and took several days to figure out. Ughhh.

    Another issue is that AOL (at least version 8.0 that I’m testing now) caches pages so that PHP or whatever server side script you’re using parses an old version of the page. This was driving me crazy because the identical script would work great on IE or NS but on AOL would fail to query the database correctly. I finally figured out that caching was taking place and tricked it by using a random number generator to put a name-value pair in the URL like random_number=25 (or whatever the random number for that page generation is). Do you think AOL puts this info on their developer’s site. No!

    Another major bummer for those who use popups is that AOL automatically resizes your main window to approximately 3/4 width whenever a popup opens. This requires either that a) you design your main window contents to be narrow (i.e. use only 3/4 of your screen real estate) or b) ask that your users repeatedly maximize the screen after a popup window opens. Does AOL talk about this issue on their developers’ site. No! After many efforts to penetrate the AOL tech support thicket, I was able to email someone who was involved in writing code for AOL. He told me that there is no work around for the 3/4 screen issue and said it was “another case of AOL thinking they know what’s best for their users.”

    Yet another bummer, which amazingly IS discussed by AOL, is that AOL 8.0 gives users the ability to turn off popup windows, apparently to combat advertising popups. However, AOL kindly instructs you how to design your site without popups. Thanks, but no thanks. You can also instruct your users how to choose to allow popups from your site in specific. So a designer needs to do a sniff for AOL and then (without using a popup!) tell the user how to enable popups for your site.

    Bottom line, AOL creates many barriers to what I consider basic site functionality. The developer’s options are to a) ignore AOL, which is not smart for a commercial site, b) design a bare-bones single-window website, or c) be really really creative in coding. I would suggest starting writing and testing Javascript code for AOL first, since if it works in AOL, it will generally work in the more compliant browsers. If you design something elegant in IE or even NS and then test it in AOL, you are destined for heartbreak. Do I loath AOL? You betcha!

    What’s really wierd to me, given the commercial importance of AOL, is that there is apparently no place to get good info on how to code for AOL. I’ve done repeated exhaustive web searches for topics and found almost nothing useful (except on the famous AOL graphics compression issue). It’s possible to find plaintive requests for help, but rarely a helpful response. AOL won’t help. The developers’ forums I belong to can’t help, because most developers seem to shun AOL. But I and many other developers can’t afford to ignore the AOL audience. I tried to pay webguru.com for help, and their was to refund my credit card charge and say “Unfortunately we do not have any Gurus that are willing to tackle an AOL
    browser problem. We try and avoid the AOL browser at all cost.” Honest but frustrating.

    I’m starting to think that there’s a wide-open niche for someone to start an online consulting business for helping guide optimization for AOL. Anyone want to join me? 🙂

  4. I’ve also been having fits developing for AOL. The most frustrating thing about AOL is not just that their browser doesn’t support many conventional functions, such as Javascript onBlur() and onFocus(), but that there is virtually zero support for developers provided by AOL. They do maintain a joke of a developers’ support site, but it says nothing about common problems faced by developers.

    For example, my site depends on popup windows for functionality, including an instant messaging system. The instant messaging system requires that a minimized popup window remains open and refreshing in the background to check for messages in the database. When a message is found the popup window uses Javascript onFocus() function to bring itself to the front of the screen where the user can see it. Works great in all recent versions of IE and NS, but guess what? AOL treats their “browser” as the one and only window, so onFocus() or onBlur() doesn’t affect the popup windows, only the main window. So, for example, onBlur() doesn’t hide the instant monitoring popup, it hides the entire AOL browser. And the AOL development site has no info on this whatever, nor is there any way to contact AOL for technical support to what must be a common problem for developers.

    I have been unable to find any Javascript work around that correctly manages the popups, including one forum suggestion which was to use onLoad = self.blur() instead of window.blur(). So I have had write a completely different instant messaging script for AOL that involves refreshing an empty graphic that is created by a PHP script. This was not a simple process and took several days to figure out. Ughhh.

    Another issue is that AOL (at least version 8.0 that I’m testing now) caches pages so that PHP or whatever server side script you’re using parses an old version of the page. This was driving me crazy because the identical script would work great on IE or NS but on AOL would fail to query the database correctly. I finally figured out that caching was taking place and tricked it by using a random number generator to put a name-value pair in the URL like random_number=25 (or whatever the random number for that page generation is). Do you think AOL puts this info on their developer’s site. No!

    Another major bummer for those who use popups is that AOL automatically resizes your main window to approximately 3/4 width whenever a popup opens. This requires either that a) you design your main window contents to be narrow (i.e. use only 3/4 of your screen real estate) or b) ask that your users repeatedly maximize the screen after a popup window opens. Does AOL talk about this issue on their developers’ site. No! After many efforts to penetrate the AOL tech support thicket, I was able to email someone who was involved in writing code for AOL. He told me that there is no work around for the 3/4 screen issue and said it was “another case of AOL thinking they know what’s best for their users.”

    Yet another bummer, which amazingly IS discussed by AOL, is that AOL 8.0 gives users the ability to turn off popup windows, apparently to combat advertising popups. However, AOL kindly instructs you how to design your site without popups. Thanks, but no thanks. You can also instruct your users how to choose to allow popups from your site in specific. So a designer needs to do a sniff for AOL and then (without using a popup!) tell the user how to enable popups for your site.

    Bottom line, AOL creates many barriers to what I consider basic site functionality. The developer’s options are to a) ignore AOL, which is not smart for a commercial site, b) design a bare-bones single-window website, or c) be really really creative in coding. I would suggest starting writing and testing Javascript code for AOL first, since if it works in AOL, it will generally work in the more compliant browsers. If you design something elegant in IE or even NS and then test it in AOL, you are destined for heartbreak. Do I loath AOL? You betcha!

    What’s really wierd to me, given the commercial importance of AOL, is that there is apparently no place to get good info on how to code for AOL. I’ve done repeated exhaustive web searches for topics and found almost nothing useful (except on the famous AOL graphics compression issue). It’s possible to find plaintive requests for help, but rarely a helpful response. AOL won’t help. The developers’ forums I belong to can’t help, because most developers seem to shun AOL. But I and many other developers can’t afford to ignore the AOL audience. I tried to pay webguru.com for help, and their was to refund my credit card charge and say “Unfortunately we do not have any Gurus that are willing to tackle an AOL
    browser problem. We try and avoid the AOL browser at all cost.” Honest but frustrating.

    I’m starting to think that there’s a wide-open niche for someone to start an online consulting business for helping guide optimization for AOL. Anyone want to join me? 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.