bring it all into perspective
the tongue will steer the ship ahoy
spark up a flame
feel the pain of habañero sauce
a word’s forever
when we speak we set `em free
so watch your mouth
and you be careful what you say, Jimmy

—Newsboys, Cup O’ Tea (cf. James)

Every now and then I like to reaffirm my monumental witlessness lest it should fall into doubt. Oh, well. I suppose it could be worse.

Update: fixed that link. Last time I link to Hoosier Times, though.

The problem was that Internet Explorer—all the way up to version 6.0—does not fully support a tag standard that has been around for about five years now, namely: the <q> tag. According to the W3C specification, the browser is required to put quotes around anything surrounded by this tag. Mozilla does it, as does Opera. IE does not.

Mark Pilgrim has addressed this issue before, initially offering a CSS solution, but eventually settling for some server-side scripting that would insert the HTML quote entities en masse throughout his site. While this is probably an ideal solution, server-side scripting—even of the MT-Plugin variety—is not something that I have taken the time to learn.

Today, though, Mark provided links to JavaScript solutions provided by Simon Willison and Stuart Langridge. While the Willison solution involved proprietary IE scripting, Langridge took it one step further to make it more standards-friendly. Both of these implementations got the ball rolling for me and after hacking around for a little under an hour, I came up with this code:

function checkQuotes ()
{
   quotesElements = document.getElementsByTagName(”q”);
   if (quotesElements.length > 0) {
      q=quotesElements[0];
      if (q.currentStyle) {
         s = q.currentStyle;
      } else if (document.defaultView && document.defaultView.getComputedStyle) {
         s = document.defaultView.getComputedStyle(q,”);
      }
      supportsQuotes = false;
      for (prop in s) {
         if (prop.toLowerCase() == ‘quotes’) {
            supportsQuotes = true;
            break;
         }
      }
      if (!supportsQuotes) {
         for (var i=0; i<quotesElements.length; i++) {
            q = quotesElements[i];
            q.innerHTML = ‘&#8220;’+q.innerHTML+’&#8221;’;
         }
      }
   }
}

According to this code, any browser that supports the quotes will simply implement the CSS rules that I got from reading Mark’s article. Those that don’t, like Explorer, will have them dynamically added to each q element in the page.

I’ve tested this in my limited “QA” environment, and it works without error in the Mozilla variants, Opera 7, and Internet Explorer 6.0—which includes quite a chunk of the internet community. Netscape 4.76 did generate an error, however, quietly whining that the document.getElementsByTagName function does not exist.

Thanks to Mark, Simon, and Stuart for their work. Click here to see an article that employs the <q> tag.

On a related note, the Mozilla organization has posted a new page regarding the recent outbreak of new browser technologies.

Mozilla: Browser Innovation. In addition to the Mozilla-based browsers, Apple has recently launched its own browser for Mac OS X, known as Safari. It may be that the majority of Mac end users will end up using Safari because it comes with the OS, just as many people end up using IE because it comes with the Windows distribution. Some see this as traumatic or as a mark of doom. But the Mozilla project understands that almost everyone in the US market (and a substantial percentage of the international market) receives Internet Explorer when they acquire a computer, and our job is to provide an alternative. We would have preferred to have Apple use Gecko or collaborate with us on the development of the Camino browser, but providing an alternative to an OS-sponsored browser is nothing new to us. The key goal of the Mozilla project is to help keep content on the web open and help keep access to that content from being controlled by a single source. Apple’s decision to ship a browser based on an open source rendering engine, with a focus on standards compliance, is a good thing for the big picture goal. The emphasis on the open content standards is mine.

A coworker had joked recently that if Microsoft had gone ahead and taken over the world that browser development would be much easier. Well, yes and no. It might be easier, but can you imagine an Internet based on proprietary standards where one organization—whose good, old-fashioned, capitalist goals are to sustain itself and widen profit margins—dictates the terms of the flow of information? I’m not knocking capitalism, but sometimes what’s best for the user and the industry has to be discussed in a marketplace of ideas, such as the W3C.

But, if this is the case, why are web pages rendered so awfully? Netscape and others would assert that this is actually because of Microsoft’s predatory practices: the very reason we have different browser renderings is because Microsoft a). packaged their browser with every operating system they’ve shipped since Windows 95 and b). that browser, through its iterations, has not followed the W3C rules. Speaking in terms of Adam Smith now, active browser competition would help browsers achieve better standards, just as better products out-do their competitors in the marketplace. But, Microsoft’s monopolistic practices allowed them to squash competition, thereby giving them the power to do whatever they wanted in terms of browser rendering.

That’s why there’s been little innovation since Internet Explorer 4. That’s why it’s a Bad Thing to let Microsoft—or any other one organization for that matter—to determine the means by which information flows. That’s why your web pages render differently.

It’s going to take some time before the market readjusts to a competitive landscape and, until then, we will have to deal with the shoddy implementations of W3C standards. With a little foresight and some patience, though, perhaps we’ll be able to see through the readjustment and design documents that are actually useful to future applications.

What’s weird, though, is that my knee-jerk reaction is to declare that O7 just doesn’t support web standards–and that would even seem to be confirmed by the fact that Mark Pilgrim posted a CSS workaround hack today. But then it occurs to me that it doesn’t make sense for a brand-spankin’ new production browser (as opposed to a brand-spankin’ new beta browser) doesn’t support standards that have been around for two years. Then it occurs to me to wonder what the rest of the standards-based sites I can think of off the top of my head look like. Dive Into Mark? Fine. Dooce? Copasetic. A List Apart? Spiffy. Wired? Well, er, not so great (at least I’m not alone).

Now the kicker: I go to Opera’s own site to see what their markup is. To my surprise, it’s XHTML 1.0 Strict. And it even validates.

So what am I doing wrong?

By the way: Opera may have mouse gestures, but Phoenix has mouse gestures and type-ahead-find. I’m sticking with Phoenix.

What in the world am I on about? Well, take for example my struggle with Netscape Navigator 4. This browser, as many noted in their comments, is just evil when it comes to develop a site using CSS. When I pulled up kennsarah.net, the fonts were askew, the borders were pixels off of where they should be, and the entire right-column of our site was rendered–I kid you not–underneath the left column. I figured that I couldn’t be the only one experiencing these difficulties (and I’m not), but the reason that a lot of this goes unnoticed is that the majority of the sites on the Internet are using design techniques (such as embedded tables) that are circa 1996. The markup on these sites looks like garbage, but you’d never know or care if you were using anything later than a version 4 Internet Explorer or Netscape browser. However, if you use a text browser or–more importantly–a text reader, you’d know that these other sites just can’t cater to people with disabilities, or people who are using other mediums for web browsing such as cell phones or PDAs.

I’m rambling now. Other people have made this point better than I am, but the point is this: websites are about content first, design second. If you place limitations on how your web page can be experienced, than you alienate a potential readership. Now, does that mean that a site should look like garbage? No: my site hardly looks any different today than it did on Friday to anyone using a post-version 4 browser. It’s the markup underneath that changed to accomodate the larger readership. I improved the site in such a way that my original design has been retained, while at the same time allowing the site to be used by a wider audience.

The next logical question to ask is, “But, who will look at your site as only text?!” Well, there are people that do (for their own reasons). If there weren’t, you wouldn’t be able to download the latest version of the Lynx browser. More importantly, though, is that Google looks at web sites in text-only mode. Google doesn’t see graphics (beyond their title and alt attributes), and it can’t understand Flash. I was flipping through the introduction pages of students in my Senior Project class, and one peer had posted a link to his corporate site. I clicked through. Not only did I get one of those annoying “are you HTML or Flash?” menus on the homepage, but when I went to the Flash site I discovered that the entire site–from graphics to text–was entirely embedded in Flash. Search engines can’t read that, and so his potential clientele who are using search engines to find businesses never know his site exists.

“So what were the changes?!” :) The first one I’ll start with is, really, the first step to thinking outside the box when it comes to markup design. I have external stylesheets on my site, and, rather than use the standard <stylesheet type="text/css" src="styles-site.css">, I used this:

<style type=”text/css”>
   @import url(”http://www.kennsarah.net/styles-site.css”);
</style>

This techique is valid for referring to external stylesheets in post-version 4 browsers, but NN4 doesn’t understand it. It effectually removes the style from the markup from Netscape 4 so you can see what your site would look like in a browser that doesn’t support stylesheets, such as a PDA browser. By making this change to the site, I decided that any browser that doesn’t sufficiently support CSS should just get the raw markup. Some would argue that this doesn’t really answer to the question of accessibility–the site doesn’t look broken anymore, but it sure doesn’t look great, either. My rationale for that decision was that if the user is still using NN4, then I’ll make it readable and navigable, but I’m not going to design an entirely new site in tables just for a browser that is rapidly on the decline.

Once stylesheets were removed, I noticed some interesting things about my site. First, the columns rendered in such a way that the left column was on the top of the page, the blog content in the middle, and the right column at the end. This, I figured, doesn’t make a lot of sense: the main blog content should be placed at the top. To do that, I just moved it to the top of my markup (you can view the source to see what I’m talking about). I also noticed that some text mini-headers (such as those under our links section: friends, family, etc.) showed up as plain text and made the links harder to read. It occurred to me that I could use the <h1> through <h5> tags on my site to distinguish the headers in the markup. Wow, what a grand idea–that tag has only been around since ‘96. :)

I was actually getting into this–the site was looking more and more navigable on my Palm, Netscape 4, and a text-browser as I continued to tweak the HTML. I went a step further: <hr> tags are used in markup to draw horizontal lines. this would be useful in further distinguishing the columns when looking at the site in text- or markup-only. The difficulty was that I didn’t want any of the changes I made in markup to negatively affect the site when viewed with style. The solution was to include the <hr> tags at the bottom of each column, but to make their stylesheet property hidden with this code:

hr {
   visibility: hidden;
}

Now, when a user is looking at the site with style, the <hr> tags are hidden, but when someone looks at it without style, the <hr> tags draw the horizontal lines like they’re supposed to.

One final thing I did add, though, was that if a user is looking at the site without CSS, I wanted to let them know that the site doesn’t normally look that plain. So, in my page footer, I added a reference to this bit of code that checks to see if the stylesheets are enabled. If they are not, the JavaScript writes a little upgrade-reminder message:

function CheckStyle ()
{
   if (document.styleSheets == null)
      document.write(”By the way, this site looks much better in a standards compliant browser.”);
}

That’s it. Next time you get really, really bored, make sure to check out the site in text-only mode. ;-)

As usual, the next step was to scope out what Mark Pilgrim had to say about NS4. Here were some articles I ran across.

==

• A List Apart: Backwards Compatible Stylesheet Switcher. Ridiculous! Impossible! Why on earth would you want to? Go back to your cave, Neanderthal! All these responses are valid, but I have a peculiar angle on the situation. I do all my web design, however impractical it sounds, using CSS layout that displays reasonably well in Netscape 4. And I saw no reason to change now. This ALA article seems to express that the best way to handle the issue is JavaScript. This might be a good idea (figuring out the browser signature and doing a document.write() wouldn’t be that hard).
• Mark Howells Online: CSS and Netscape 4. It is possible to create some quite good sites for NN4.x using just CSS for layout, but there are a few things that you need to be aware of, even before you open Photoshop to do the initial graphic design. Brief list of pointers.
• Website Tips: CSS (Style Sheets). The CSS Section below is filled with links to some of the best articles, tips, tutorials, editors, and templates on cascading style sheets (CSS). Some nice articles referenced here, including some of the above.
• Mark Pilgrim: The neverending saga of Netscape 4 compatibility. CSS and Netscape 4 Issues. I’m battling this in my day job. (Yes, I have a day job, and yes, it currently involves creating a web-based application that works in Netscape 4. Life is full of little ironies.) A brief commentary on Mark’s NS4 adventures.

==

All in all, I may just serve up raw content (i.e. not formatted with CSS) for anyone who is using Netscape 4. This is similar to what already happens for users using, say, EudoraWeb for Palm. The message being to NS4 users: the site might look boring, but at least it doesn’t look like garbage.

As a geek, the philsophy of content reusability is just too appealing to pass up. As a supporter of open source projects such as Linux and Mozilla, the idea of disseminating information to as wide an audience as possible (without discrimination of browser or platform) is commendable. As a technologist, I’m quickly realizing what a lot of other people (including the editors at O’Reilly) have already figured out: Mark is actively exploring the future of web design.

So, what does all of this mean to the web developer? Well, in short, I think it’s time to get away from the idea that web design is just about static graphics and tags. The bias that I had when I worked on dbleads.com for D&B is that everyone who would visit that website would be using Internet Explorer, and that all of those users would experience that website in the exact same way I did. I never considered the possibilities that the content on that site might one day need to be remodeled to fit another schema (which is ironic, because I’ve remodeled that site twice now). Nor did I consider that anyone would be (”stupid enough to be”) using Netscape. And I especially did not consider that a web-spider such as Google’s would care about indexing the site or that someone with disabilities might even want to consider having its contents read to him or her.

As the web continues to mature, it only makes sense that these considerations will have to be addressed. The release of Mozilla 1.0 (which has seen its market share grow rapidly in the last year) and, more recently, Apple’s Safari browser are harbingers of what’s to come. Mark Pilgrim has already dealt extensively with making his site accessible to the Safari browser. Why? Because it currently makes up 15% of his viewing audience. For those of us who will one day own a Mac, this becomes a poignant issue.

The Internet is about disseminating information and a lot of innovation in this space remains to be seen–I haven’t even mentioned XML, RSS, or other non-browser based technologies. While a strict adherance to W3C standards is not a panecea to the question of presentation, there must be a compromise. We must be willing to support a wide variety of technologies if we hope to maintain relevance, even over the next 18 months. That’s what validating pages is about. That’s what will make the difference between watching your audience grow, or becoming just another forgotten corner of the web.

Update: Of course the morning following my rant about standards and accessiblity, poor Mark Pilgrim has to discover that the W3C dropped some of his critical markup technique and have a tantrum.