While everyone (myself included) has applauded Microsoft for making moves towards supporting standards, a mere slight improvement over IE6 is not enough this time. I mean, come on - they’re Microsoft, one of the largest software companies out there. Why can’t they seem to get things right?

The bane of web developers and designers

It’s a well-known secret among those involved in making websites that IE6 is horrible when it comes to supporting CSS (Cascading Style Sheets), a format for defining how webpages should be presented. Provided you’re not doing everything in Flash, and care about web standards, you’ll quickly find that you have to learn CSS in addition to (X)HTML if you want to properly design a website, possibly in addition to server-side technologies.

Designing your first website using CSS for the presentation, you’ll quickly find that IE6 is the odd one out, and hardest one to “make things look right” in. Out of all the selectors in CSS 2.1, IE6 only supports a few of them. Additionally, many of the pseudo-selectors, such as :hover, only work on certain elements. Boo-urns!

As most web developers/designers have switched over to a different browser, either by choice (Firefox/Opera) or because of necessity (Safari), they’ll quickly find themselves always having to refer back to IE6 to “fix” the site once things are already looking great in the other browsers. Thus, IE6 has been the target of many a web designer’s curses throughout the course of history. (Perhaps similar to how Netscape 4 caused many headaches years ago - but maybe not as bad as that!)

Corporate lethargy

Some would suggest this is merely the result of Microsoft growing too large and becoming a dinosaur of sorts, not able to respond to changes in the marketplace. A good example of this is their Live-series of web-based services and applications, most of which seem to be inferior to competing products offered by other companies. In this respect, it seems that Microsoft caught on a little too late to this trend.

However, I don’t think this is the case with IE7. Microsoft, by all accounts, has talented people working for them - there’s just no way they could have become so successful without talent. Microsoft research in particular has some really smart people working for it - an MS researcher recently visited our lab last month, and I was impressed not only by his depth of knowledge in his field, but also his breadth of knowledge. He seemed to know, in quite some detail, about each of the areas the people in my lab were engaged in.

Shunning standards?

Therefore, it seems that solving a problem like making IE7 standards-compliant can’t be that big of a problem. I mean, they have had five years - and other companies like Mozilla and Opera have made browsers that fairly standards compliant, with Opera being a bit better than Firefox at standards support. One argument could be that they don’t want to release a browser that’s so different from IE6 that sites will “break” on the new IE7. This isn’t accurate though, as they’ve already made enough changes to virtually guarantee that sites “made for IE6″ will break on IE7.

As much as I hate to say it, some believe that IE7’s lack of support for standards is something that’s been deliberately “implemented”. HÃ¥kon Wium Lie, of Opera software, best sums it up in an interview on Slashdot:

It’s quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don’t they do it? The fundamental reason, I believe, is that standards don’t benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

What he’s saying is certainly plausible - Microsoft has been known to engage in anti-competitive practices, and after all, anti-competitives practices are really sound (but perhaps not ethical) business strategies that only become available when you’re the clear market leader. And, when you have shareholders always squeezing you to make more money, sometimes business strategy can take a more sinister direction.

I want to stop short of actually declaring MS to be engaging in anti-competitive strategies here (though a compelling argument could be made for this), but I will say that the effects of their actions, for whatever motivations, are horrible for web development. Internet Explorer 6 was a big enough problem, as since it’s the majority market holder, professionals in website development had to account for it - there’s just no saying “Screw non-standard browsers”, when your expected client base is 80% (or higher) IE6. And, with the release of IE7 (to be pushed to users automatically), more problems will be created: sites made to work with IE6 will probably not work too well in IE7, and vice-versa. Clever tricks, whether through CSS or JavaScript will eventually provide work-arounds, but all of this adds substantially to the development time for a site.

So much for the chant, “Developers, developers, developers!” Microsoft, please fix IE7 before it’s widely released, and you’ll be sure to receive heartfelt thanks from many formerly-frustrated developers out there.

Furthermore, websites done entirely in Flash are still being pushed - indicating that proliferation of best-practices and advantages, as pertaining to web-design, are still not well known. Perhaps it’s time to outline (at least briefly), why doing an entire site in Flash is a bad idea.

A brief history of the problem

The problems leading to people designing entirely Flash-based websites are in many ways related to, or the same as, those found in the design of poor websites. If we understand why this happens, then there’s less ignorance - and hopefully less thinking that people who design entire Flash websites are “idiots” - they are not. There’s just a basic misunderstanding of what’s at stake, and problem compounded by standards not followed by either designers or browsers.

Alright, so what is wrong then?

To the average user, there’s nothing wrong with Flash-based websites. To many, they represent a unique experience - you’re able to do many things in Flash (such as animations, nice vector graphics, etc.) that you simply cannot do in regular XHTML. Additionally, nicely-designed Flash websites can look nifty and have that “wow-cool” effect. In fact, proper use of Flash can enhance a website without harming it - sIFR being the best example that comes to mind; furthermore, Flash games are probably here to stay. However, making an entire website in Flash can have many negative effects.

When I say “entire website”, I mean that all the content - text, links, pictures - is contained within Flash. This is bad, because it eschews standards-based content representation (like XHTML and CSS) for a proprietary format. Perhaps because of this, it also has negative effects on usability and accessibility - it’s often hard to search for text in Flash-based websites (the standard browser search doesn’t work), text resizing is difficult, and often widgets (such as the scrollbar) are re-designed or made to look different, which can be confusing to a user.

Furthermore, Flash content is hard for search engines to index. If you’re making some sort of website, chances are that you want it to be popular, especially if it’s a store. If you have your content displayed via Flash, it’s inherently difficult for Search Engines to get at it and add it to their index, thus making it harder for people to find your website. You have to take special steps to ensure that a search engine will index it - when just doing the website in regular XHTML would have probably sufficed. Additionally, this doesn’t help those who are disabled - Flash is notorious for being inaccessible.

But for me, the biggest problem is that the use of Flash sets the stage for bad design. Jakob Nielson sums this up best in his article, Flash: 99% Bad. (Sometimes I think he’s too pragmatic, but he hits the nail right on the head here.) The issue is not whether Flash is inherently bad - it isn’t - but rather it tends to be used poorly and creates issues. For example, Flash is often used for things that don’t add much value to the site, and in many cases, actually make it harder or more annoying to use. The things that come best to mind are useless fancy animations, and sound effects or music. A website that automatically plays music or sounds is one of my pet peeves - I make it a point never to revisit that site. I’m not sure how mainstream users feel about this sort of stuff, but I believe once the “wow-cool” factor of a Flash-based website has worn off, users quickly realize that they tend to be harder to use.

Additionally, Flash is used for things where it’s simple not needed. The most popular example I can think of is the menu of links most websites use. There is no reason to do this in Flash - as mentioned before, complex animations slow things down and detract from the content being presented, and furthermore, many of the animations can be done in JavaScript, with proper regards to standards and graceful degradation, something Flash does not do very well.

By graceful degradation, I mean how does your site respond when someone doesn’t support that feature? For most Flash websites, if the user doesn’t have Flash, they’re outta luck - they’re greeted with a very unfriendly link telling them to get the latest Flash player. Before anyone points out that “most people have Flash”, remember that accessibility also has to be taken into account. For people using speech readers this is a very important problem. And again, most Search engines don’t care for Flash.

Other problems with Flash-based websites are small but noticeable. They often break the back-button functionality, don’t work as great on slower computers, and usually take longer to load than non-Flash-based websites. These are the factors that make my cringe anytime I visit a website done entirely in Flash.

What can be done

Firstly, many of the problems can be traced to a need to add “neat” effects to a websites, such as the aforementioned animations and so forth. Much of this simply isn’t needed as it doesn’t add real value to the content, which should be the most important part of a website. While it’s true that many people will think that the effects are “cool”, effects are not what will keep users returning to a website - fresh content is what does that, and often neat graphical effects get in the way of displaying content in a fast and efficient manner, thus detracting from the most important aspect of a website.

I’m not saying that a website can only be done one way for it to be “good”. And, I’m not saying that a website must not have Flash in order for it to be good - there are many ways for Flash to enhance a site’s usefulness. However, designing a website entirely in Flash is a poor choice when the current drop of standards-friendly tools like XHTML, CSS and JavaScript were made for website design. Flash was not - and this is why the websites are inherently less accessible and usable. Designing using standards-based approaches doesn’t have to boring, and doesn’t have to result in websites that all look alike. One look at the CSS Zen Garden and you’ll it to be exact opposite of that.

Summing it all up

Flash is not inherently bad, but it tends to be overused to the point where many do consider it to be evil. This tends to happen when web designers haven’t read up on the benefits of standards or proper design. This doesn’t indicate that someone is “stupid”, but rather that they just haven’t been exposed to all the knowledge that is out there. Unfortunately, as with poor website design, it’s easy to start down the wrong path.

Furthermore, many of the criticisms about Flash can also be applied to Ajax, which I tend to promote instead of Flash. Unfortunately, it’s also easy to use Ajax improperly, and there are accessibility issues as well. Thankfully, these are being addressed relatively early in Ajax’s development, and we can only hope that it doesn’t suffer from overuse and misuse like Flash has.

If you’re a web designer, you may be disenchanted everytime you visit a poorly-designed or poorly-structured site. Why do these still persist, despite proper techniques of content/presentation separation having been around since 2001? Has the whole world gone mad? Fortunately no - but it is a complex problem.

The problem of poorly designed websites, in my opinion, can be traced to two important factors, both of which can be assigned varying degrees of “blame”, depending on your viewpoint. There are tons of complicating factors, but I believe these to be the two most important.

Firstly, HTML (the precursor to XHTML), was designed as a document markup language (hence the name), completely devoid or separate of presentation information. Since the earliest users of the web were mostly from academic circles, it’s no surprise that much of the markup in HTML applies to formatting things like scientific journal papers, which typically make extensive use of headings, lists, and other semantic elements. The complete lack of presentation styles in the first version of HTML might seem like a good thing nowadays to web designers “in the know”, but unfortunately, most people don’t think that way. This resulted in later version of HTML adding presentational elements such as font, and even browsers implementing their own non-standard elements, all due to user-demand for control of presentation. Much of these elements have now been depreciated or eliminated, but they still remain in use - it’s hard to close the door once it’s been opened.

The problem lies in the interpretation of what exactly is content, and what is presentation. Content exists for the purpose of communicating information or a concept; presentation defines how that content should be shown. However, most non-technical people tend to blur the line between the two - for most people, presentation is part of the communication process. This is an equally valid point-of-view, and is in fact, probably the normal way to view things - human beings are visual creatures.

It takes a different sort of person to consciously think “This part of the document should be marked up with a list because it depicts a series of objects with some sort of logical relation among them”. Most people simply read the list as-is, but subconsciously, they are probably making the same connection. I think this has to do with the person’s MBTI, (and obviously their areas of education), but that’s another topic altogether.

The second factor deals with the unusually low-barrier to entry for making a website. HTML, quoted as the lingua franca of the web, is a fairly easy language to learn, as far as learning topics in computer science go. A grade school kid who can read at a decent level can easily learn the basics and begin coding the basics of a web page almost immediately. This is enhanced by the availability of many WYSIWYG HTML editors that make creating web pages as easy as using Microsoft Word or PowerPoint. However, while HTML is easy to learn, like many other things it is hard to truly master, especially when using it properly with a combination of CSS and JavaScript. This creates the situation where “a little knowledge is a dangerous thing“.

While it’s easy to make a web page, it’s also easy to flaunt disregard for web-standards, accessibility and usuability, all in the name of making a page that looks “nifty” or “cool”. This is perhaps best seen in the unending multitude of MySpace pages, where users are given control to customize almost any part of their page. This has resulted in pages that are either poorly designed, hard to use, do annoying things like play music, or a combination of the above, creating a haven that is a throwback to the Geocities of the 1990’s. The problem is compounded by problems with proper implementation of best-practices as well as the fundamentally different ways design must be done on the web as opposed to other forms of media such as print.

In reality, HTML is a language that demands almost the same level of attention to detail as a programming language. However, since programming languages are harder to learn, they present a greater barrier to entry that keep out those not willing to learn things the right way. (If you make a syntax mistake, the program will probably not compile or run - however some would argue that there’s still a lot of problems related to poor programming practices as well.) Some people would like these strict rules to apply to XHTML as well - in fact they do, if XHTML is served as XML, which it was intended to be. This has created a very stratified community of “website designers”, best summed up in Roger Johansson’s article on Levels of HTML knowledge.

Furthermore, good structural HTML is important if you care about Google or any other search engine indexing your site properly. The Googlebot (their spider that crawls the web, searching for new content to add to their search index) will have the easiest time indexing your site if you’ve properly separated content from presentation, and used meaningful (X)HTML elements to markup your content. Many people do not understand this - they either don’t understand or have the false view that search engines view websites in the same way that people do, through a browser. Additionally, if you care at all about accessibility, you must follow web-standards, which are conducive to designing a website that is accessible by anyone with disabilities.

I don’t draconian parsing rules are the solution, as for something to be the lingua franca of the web, it must be accessible to use by all. Easy to use, standards-compliant XHTML editors are what is needed, but I acknowledge that the problem is difficult. Thankfully, things are improving - despite the presence of sites like MySpace, the increasing popularity of blogs has given another outlet for people to create personal websites. Most of these blogging platforms are relatively standards-compliant, and in line with the spirit of web standards as well, and in many ways have been at the forefront of promoting good website design. Let’s hope more sites follow suit.

Why and what’s it for?

A lot of people might wonder what all this talk about “validation” and “standards” is even about. This is a valid question - after all, many people place website design in the same realm as making a powerpoint presentation or even a word document - and there are no standards or validation to worry about for those documents, so why should there be any for webpages?

Well, in this case it’s important to understand the differences. In a certain sense, Word and PowerPoint documents must also “validate”. If you were to open a Word document in Notepad, change a few random characters, it probably would look all messed up when you opened it back up in Word. This is because Word would not be able to parse or “understand” the changed or “invalid” data since it wouldn’t be in a form that it expected.

The same goes for (X)HTML documents, except sometimes it’s not as noticeable. Browsers have been coded, for the most part, to work around invalid markup to some extent, due to years of improperly coded and invalid sites dominating the web. However, as Tantek points out, improperly-formatted documents screw up the DOM (Document Object Model), so when it comes time to add JavaScript to your site, things may start acting weird. It’s best to clean up your act now - if you code by hand, you need to be aware of the rules you need to follow for validation. For other people, unfortunately, there are still many WYSIWYG editors that spew out ugly code. Dreamweaver may be a good choice in this sector.

The official validator does a pretty good job of diagnosing errors and giving warnings, though Tantek’s entry gives a better explanation of some of the more common errors that remain unfixed during the validation process.

Of course, if you’re using a blogging tool like WordPress, much of this work of validation is taken care for you. You just need to be sure that you don’t use invalid markup in your posts - something that may seem annoying to non-techies, but there are times when rules should be followed.

Proper separation of presentation and content

This is perhaps the most preached concept in proper web design, as you can find articles about the subject going back at least a few years. For those used to the “old ways”, this is perhaps the first thing you should know after validation. In fact, you pretty much need to have to the two. It’s entirely possible to have a valid webpage that uses tables for layout/design, but this would violate the proper use of tables. Tables are a semantic element (which means they carry meaning and assign a certain meaning to the information they contain), so using them for layout is an incorrect practice, though it’ll pass the validation test.

This is an important difference to note. Validation tests for document well-formedness, that is, can the data be properly interpreted by a client that only follows the outlined (X)HTML parsing standards. Use of tables for a layout is a design decision that is separate from this; however, the two bad practices of invalid markup and table design often go together. If you’re looking for a good guide to dropping tables, check out Stop Design, and get your site out of the 90’s.

Tantek also gives a nice tip on CSS class names - the use of context. I’ll be the first to admit that I’m probably the worst offender. I use class names like postDate and postMetadataTag when an element with a class of date within an element of class post is the better and more succinct way to do it.

Serving up standards

In short, while following all these guidelines may seem a bit daunting for the new or occassional web designer, it’s worth it to follow these rules as it’ll make your site easier to maintain, and make the XHTML format more viable in the long run. Adhering to an open data standard will make the web easier to use, search and update.

A little background

The history of RSS is complex and coloured with many differing non-compatible standards all using this three-letter acronym. Of these, RSS 2.0 and RSS 0.91 seem to be the most popular, with perhaps RSS 2.0 becoming more popular with time. You shouldn’t have to worry about all of these differences, as anyone who makes a quality news reader/aggregator, the software used to subscribe to these feeds is probably aware of this and has made their software compatible with all these different versions.

To further add to the confusion, another syndication format, Atom was also developed back in 2003, in response to RSS not being an open format, such as XHTML. As a result, Atom was developed, and is the only format with the IETF’s backing, and hence the only format with a proper, recognized, MIME-type. It thus has a large following among the geeks and tech-saavy, who are perhaps the only people in the world concerned with such things - not that this is such a bad thing. However, most common folk only care “that it works”. (Note: WordPress offers Atom feeds as well as RSS feeds; I simply have not linked to them for brevity and so as not to create confusion with multiple feed links for the same content.)

So, how does it work?

In very basic terms, syndicated content doesn’t utilize any new web technologies, in contrast with, for example, BitTorrent. Instead, to create an RSS/Atom feed, a website will make another copy of regularly-updated content, except it will be formatted and marked up in a certain, XML-friendly way, so that it can be read easily by news readers/aggregators. This file is known as the “feed”, or its location as the “feed URL”. The contents of the feed have been formatted very carefully, and if you were to look at the source, it would look similar to HTML markup, except maybe a bit more complicated.

These feeds are almost always generated by software, and not by hand, thus they fit very nicely into most blogging and CMS software. They usually only contain content, and some useful metadata about it, such as publishing date, author and so forth, and thus allow the reader to get at what’s useful, without having to remember to visit that website.

How’s it helpful?

On their own, the feeds wouldn’t be very much use. But the other side of it is client software called feed readers, news readers or aggregators. These allow the reader to “subscribe” to feeds that they choose - in effect, making a list of sites whose content they are interested in seeing when it is updated with new information.

I hesitate to use the word “subscribe”, since although it’s useful to describe the concept (sort of like subscribing to a magazine you like), the process is not the same. Unlike subscribing to a newspaper that’s delivered to your doorstep (A “push” service), news readers actually subscribe by “pulling” the data to your computer. Thus, a news reader will check a feed to see if it’s been updated; if it has, it will download the new data. Thus unsubscribing is fully within your grasp; the act of “unsubscribing” merely means removing the feed URL from your reader, so there’s no real possibility of spam like with e-mail.

It’s useful since it allows you to dilute the vast quantity of new information on the web everyday down to what you consider to be useful. If you’re like me, you are interested in stuff like web design, development, technology and the like. Once I find a site or blog that I like, I subscribe to its RSS feed, and thus I no longer have to continually search the web to find interesting information, and can keep up to date on new developments.

So, how do I get started?

Syndication has been around for long enough that there are many mature news readers out there. Wikipedia used to have a good list, but it was deleted by the admins over there after an extensive discussion, because we all know how evil link lists can be and how they’re destorying Wikipedia and the moral fabric of America. However, they did link to this somewhat hard-to-read directory of RSS readers - the list is huge.

There are different types of readers, based on what you need. The traditional reader will install
onto your computer and provides an interface similar to an e-mail client. Popular ones include clients from NewsGator, and of course the built-in functionality offered by Mozilla’s Thunderbird client, and the “Live bookmark” option in Firefox. However, the built-in options in Thunderbird and Firefox are limited, in my opinion.

The other, newer breed are web applications that provide news aggregation. Currently, I’m using Google Reader, and am liking it. While it may not offer all the functionality of a regular software client, I like the fact that I can access it from any computer, and it’s fairly fast. Subscribing to feeds is also very easy; you don’t even need to entire the correct feed URL. If you enter a website URL (such as http://unitstep.net), it will automatically see if there’s any feed URLs linked from the site, and will subscribe to them. The layout is also decent, and I haven’t had any problems with it. Google Reader even provides a feed of its own, so you can subscribe to this feed to view your aggregated feeds!

Other options include “widgets”, either for desktop widget engines such as the Yahoo! Widget Engine, or online widgets for portal sites such as Google’s “I Google”, or Microsoft’s new Live service. These allow you to view your feeds in small boxes of information that are part of a personalized home page. I don’t really use these types of sites all that much, but they can be useful to many so its worth a mention.

Your world, your information

So, in conclusion, get out there, and start feeding! It’s easier to read and absorb useful information when its already been stripped down to what you care about, and syndicated content is allowing that.

Credit where credit’s due

To its credit, the W3C has done a lot of great work. Headed by Tim Berners-Lee, the creator of the web, it’s done good work in standardizing the data formats that encompass the Internet. Without some sort of guiding body, the web would certainly be a lot less usable than it is today. They’ve also made decent progress in updating standards as technology/trends change, and haven’t left out accessibility for the sensory-impaired, something that should be lauded.

Certainly attempting to standardize something as widespread as HTML/XHTML across something as big as the Internet is no easy task; working with the companies making the browsers must have been a hard task. After all, companies want to distinguish their product from the others; if they all support the same “standards”, what would make one better than the other? Perhaps this was the thinking during the browser wars when companies started introducing support for non-standard elements in order to make their browsers more appealing to users and web designers.

Part of this is the reason why some pages still render differently in IE than in Firefox or Opera. But these days, it’s mainly IE6 that’s the odd one out, with Firefox and Opera (among others) either supporting the W3C standards better or completely.

Competition breeds innovation

While this effort by browser makers to independently make their own specifications often (especially in the past) resulted in broken web pages that only worked in certain browsers, once in a while, it provided browser programmers the ability to introduce a new feature that was actually of use, besides something like the marquee tag.

What I’m talking about is the XMLHttpRequest object, the basis for Ajax and hence a lot of the websites or web applications that you may use on a regular basis. If you’ve used Gmail, if you Digg, or if you use the new Yahoo!, you’ve benefited from Ajax and hence this non-standard web technology. While the original concept used an ActiveX object, its value was apparently seen by other browser makers, as Mozilla introduced support for their browsers back in 2002, with other browser makers following suit. (Though interestingly, Opera only gained support recently - perhaps this is related to the fact that they follow the W3C specifications closer than either Mozilla or IE)

Gmail’s been around for over two years, and other Ajax websites or web applications have also been in use for over a year. However, the W3C published their first working draft only back in April of this year, which is attempting to standardize a method that is already in wide use. Admittedly, it’s a valiant effort - currently, implementations differ across browsers (mostly IE in one corner, the rest-of-the-world in the other), so getting something down that everyone can agree upon is good.

Too little, too late?

However, it strikes me that it took them this long to develop even a draft. And, with many JavaScript frameworks out there that already abstract the XMLHttpRequest object in such a way that you don’t have to worry about incompatibilities, isn’t some of this work perhaps done in vain?

Thankfully, there’s been some action to counter this slow reaction time. As with most standards bodies, slowness to adapt is a key problem. In fact, it’s why the W3C was developed in the first place, (ironically, it seems), in order to address the shortcomings of the IETF at the time. However, this time, the group that’s taken the helm is a not a vendor-neutral group, but instead one comprised solely of the companies and people who make browsers - the WHATWG.

The WHATWG is not meant to be competition for the W3C; they aren’t meant to replace them. Instead, they hope that by fostering a good relationship between browser makers, good standards can be developed at a fast rate on par with development in the real world. These drafts will then be submitted to the W3C, thus taking a lot of the workload off from the W3C.

W3C-what?

The W3C, which one shouldn’t remember to commend for their previous efforts, still sometimes comes up with specifications that, while looking good on paper, just don’t seem like they’ll translate into something real and usable.

Take XHTML 2.0, for example. With a name like that, you’d expect it to be a successor to, and be backwards compatible, with the current version of XHTML. Not so. In favour of a stricter definition of a document, backwards compatibility will not be included. All the talk of making your HTML/XHTML documents validate in order to preserve backwards compatibility and to ensure forwards compatibility seems to have gone out the proverbial window. For those who were skeptical on the usefulness of web standards, XHTML 2.0 must have seemed like the straw man they were looking for - it really underlined the separation from reality that the W3C seemed to taken. (Even the current versions of XHTML have problems that need to be addressed in the context of delivery over the web)

Maybe it’s time

So perhaps what we needed was the WHATWG - something to keep the W3C in line with reality, and to allow the speedy standardization of things that are still in the process of developing. So far, they’ve produced a few specifications, which have had an impact on the W3C. Their continued interest in text/html as a viable MIME type is rare; too often, people get caught up in current trends, such as the love-affair that everyone seemed to be having with XML a while ago. While certain XML formats are good, they do have issues when there’s a chance the XML will be hand-coded and not checked for well-formedness errors. In this case, traditional HTML in the text/html MIME type is probably better.

In conclusion, hopefully the state of web standards will be better in a few years or so. The W3C has a lot of good to offer, especially when it comes to accessibility and so forth. Combined with the helping hand of the WHATWG, things should progress for the better.

Microformats

At its most basic, microformats are a concept that advocates identifying certain pieces of information so that they can be better collected, parsed, and otherwise aggregated for other uses. For example, the hReview microformat proposes a way to mark up the data that comprises a review (of a product or service, let’s say) so that the pieces of information that comprise a review (author, date reviewed, rating, comments) can be easily discerned. This example deals with the microformat in XHTML or HTML, but it could also be applied to XML documents.

Since microformats do not have strict rules like XML documents do, applying one to an existing document to make it microformat friendly is straightforward and doesn’t require you to totally re-arrange your data. A nice example is shown in the hReview specification. The changes basically amount to adding a few class attributes on some elements, in order to identify certain pieces of information. For example, the name of the item being reviewed must be in an element that has the classes “fn” and “item” applied to it. (Either by the cascade, or directly) This a simple, but effective way to identify data - that is, to use metadata identify the sematics of the information.

Defined by usage, rather than defining usage

The neat thing about this is that it works entirely within the confines of HTML or XHTML to enhance the semantics of the language. Very few changes are needed, and in fact, the changes that microformats suggests are better since they will allow you to style elements better since they will be identified; in fact the way this turned out is no coincidence. Microformats were designed with current “best practices” in mind, so many “in the wild” examples of markup on sites were referenced before the format was specified, in order to develop something that better suited current usage, rather than trying to develop a new standard that would be radically different from what anyone was using. This makes it super-easy to adopt microformats if you’ve already been following current web-standards with separation of content and presentation.

Microformats: out in the open

Also, microformats are not just some idealized standard that’s being discussed, rather than implemented. Many sites already use them, such as Cork’d. As mentioned before, this is because they are quite easy to adopt in a site that has already been well-designed, and so they don’t require a headache-inducing, total re-working of the structure. Thus, web-developers can easily see the benefits of adopting microformats - in many cases, they’re already using them, albeit not with the same class names or attributes. Admittedly, there could be more support for microformats, but I believe that will come very soon, as open source developers of blogging software, CMSs and other portal systems update their code to provide support.

Another important aspect, already mentioned, is the organic development of the microformats. As seen on the examples page of the microformats website, there is much open discussion before any microformat specifications are developed; for this reason, almost all of them are open to discussion, based on what is considered to be the current “best practice” out on the Internet nowadays. In this way, the specifications tend to evolve around what are the best examples out there, rather than the specifications being a pragmatic announcement of what “should be done” and what “is the right way”.

For this reason, I believe microformats will be better accepted, since they will strike the right balance between standardization, ease-of-implementation, and practicality. They will avoid the fate of other web-standards, some of which have been good on paper, but suffer from poor implementation either because of practical issues or compatibility problems.

Open data formats

Microformats are also a simple but effective open data format. With any data format, interoperability and compatibility are issues in the long run. If I save a file in a certain format, can I be assured it will be readable by the hardware and software of computers 10, 20 or 50 years from now? For some data, this is not important, but for some it is very important, such as a digital photo album, any archive information, or records. With the fast pace of development for computer formats, and technology in general, this is a definite problem.

So how are microformats any better than any other format, open or closed? Surely being an open format doesn’t guarantee operability in the long run? That may be true, but one proven hallmark of future-proof data formats is being an established and traditional format. As pointed out by Tantek, this is why Project Gutenberg (”the first and largest collection of eBooks”) has decided to store their archives in the venerable ASCII format. While this doesn’t offer any sort of markup options, it does virtually guarantee compatibility in the future - it’s highly unlikely that ASCII will be forgotten completely in the future.

For these same reasons, Tantek also believes that “Compatible XHTML” (or valid XHTML 1.0 strict compatible with HTML) is also dependable over time. HTML has been in use for over a decade on the Internet, the most widely-distributed, distributed-database in human history. Thus, its ubiquity is certainly not in doubt; its ease of use also helps, as it enables wide adoption.

Openness and the present

Okay, so open data formats can be good in the long run. But what about now? Well, there’s currently some pretty exciting stuff going on. Recently, People Aggregator announced they’d be starting a social network (nothing new) that would also allow users to post across multiple, different, social networking or blogging sites. This is currently accomplished by using APIs such as Metaweblog, but in the future, they envision more complete interoperability. The idea is that switching from one service to another shouldn’t be hard, as if open standards are used, compatibility can be ensured - rather than having to make sure the new service provider has a conversion utility to convert from your old provider.

The additional benefits could also be quite useful. For example, creating a “friends” page listing your friends’ most recent blog posts and content wouldn’t be difficult. If you’re using Livejournal, this is already easy, but the people on your friends list must also be on Livejournal. If People Aggregator is successful at getting more networks onboard their idea, adding people to a friends list would be easy, regardless of what service they were using. There is already a WordPress plugin that does this, by parsing a friends’ RSS feed. But People Aggregator’s idea is to make this functionality accessibile from blogging service.

Problems

The main threat I see against adoption of standards a direct result of the benefits it offers. As mentioned, these open data formats would allow content from one service to be syndicated and/or displayed elsewhere on the web. This helps increase the accessibility of information, as you no longer have only one place where you can get it from - you can display the information how you want to, and in what order you want.

This could directly threaten the ability for services to make money because of the circumvention of ad revenue that would take place. Many social networking sites survive because they allow people to freely make content and share it from their sites, so as long as ads are served up to viewers. If the content can be aggregated, and shown elsewhere, then the ads aren’t shown. Unless agreements are reached about this, (such as ensuring ads are still delivered in any data delivered outside the site, or ad-revenue sharing), this may be a major impediment to adoption.

This would be sad, since open data formats and the ability to “subscribe” to content and display it in a non-traditional way are basic concepts of what I would consider “web2.0″ technologies. This is a natural extension to what HTML allowed, in that it will allow for content to flow easier, just like HTML did some 10-15 years ago.

Necessarily accessible

In fact, many governments, both at the upper and lower levels, have been mandating accessibility for public websites. In the United States, there’s Section 508, and in Europe, they’re working on making it mandatory. Here in Canada, I don’t think there’s any federal law on it, though I might be mistaken. However, in Ontario, I believe the ODA applies, or will apply, to most institutions that receive government funding, including universities, which is all the more reason for them to adopt standards.

Doing it right

Designing an accessible website is not particularly hard, but it does take some extra planning. Not being a public institution, I’ll admit I haven’t taken accessibility to heart, as there are many things I could do to improve it. Thankfully, there are plenty of resources out there. The Web Accessibility Initiative is a good starting point, and the Watchfire WebXACT tool will help evaluate your site for accessibility. My site fails horribly right now, however, it wouldn’t be too hard to fix this, but I just haven’t bothered because I’m not aiming to reach everyone; a weak excuse, but an excuse nonetheless. With a good platform like WordPress, site-wide changes aren’t hard to implement, and structured blogging, a sort of microformat, could help even more.

In essence, making an accessible website is closely related to making your site semantically sound. The two aren’t exactly the same, but if you use semantic markup and get used to it, making things accessible becomes a lot easier. Every web designer (and also web developers) should be aware of this, and take these best practices to heart. If I were to design a site for a company or any institution that aimed to reach out to as many people as possible, I would definitely factor in accessibility and semantically sound markup from the beginning, despite the extra planning it would take. Any time you spent in during this stage would more than make up for any extra time you’d have to spend converting a poorly-designed site to be accessible.

The other side of accessibility

However, one aspect I think is often missed out on is the other side of web accessibility; what I mean by this is that not only must content be accessible, but the ability to produce content should also be accessible to all, regardless of their technical knowledge about web standards.

In the past, this was almost impossible. Before there were WYSIWYG editors, people had to write HTML by hand, something not everyone can do. Even when people did know how to use HTML, it was not always used correctly, and rarely with accessibility in mind. The dawn of WYSIWYG editors did not improve this at all, as most of them tended to produce a tag soup of HTML that was rarely valid, much less accessible. (Versions of Microsoft Frontpage are perhaps a good example.)

Thus, the web turned into a jumble of unsound pages and examples of the ineffective use of HTML, and later, XHTML. I don’t believe this was the fundamental fault of the authors, as I don’t believe everyone who wants to publish content on the web should have to understand all the details of XHTML - after all, does the author of a book usually have to understand all the intricate details of book publishing? I believe the fault lay with the lack of an easy-to-use editor that could produce structurally sound markup.

Thankfully, things are getting better. Ever since web accessibility standards were clearly defined, there have been movements to make publishing well marked-up content easier on the web. Firstly, many online blogging services offer fairly easy-to-use editors, and the next version of Word will support blogging, and hopefully, valid XHTML output. TinyMCE, a WYSIWYG editor written entirely in JavaScript, can be used with WordPress and Drupal, popular blog and CMS platforms, respectively. It effectively provides a word-processor-like interface for document creation, and should greatly improve people’s ability to easily publish web content within a CMS without having to burden a tech services department.

Let’s hope these editors continue to improve to increase accessibility, on both sides of the coin.

For most people, this change will amount to the new layout and styles applied to the website. This amounts to a greater focus on today’s “Top Story”, as well as special features such as their kids section and online radio. Online feature stories were also given greater precendence over mere headlines, which were moved below into neatly organized panels - an overall greater focus on in-depth online articles, rather than just everyday news headlines. The new design definitely looks “more busy”, but not cluttered, in my opinion.

It’s also interesting to note that the design folks at CBC took a lot of user input into account when doing the redesign.

We embarked on the redesign process about 15 months ago, starting with a massive study conducted for us by Decima Research. The survey asked your opinions about dozens of elements of CBC.ca’s design, information architecture and content – and, over just a few days, more than 5,000 of you filled it out for us.

The results of that survey, combined with the feedback we get daily through e-mails, phone calls and our online forms, formed the basis of this redesign. Our goal was to improve the site for you, by making it easier to use and giving you more of the features you’d like to see.

Overall, the site looks a lot more user-friendly, and definitely in step with “modern-looking” sites. RSS feeds have also been added, something that was in dire need, especially on a news-oriented website. The site may end up looking a lot like other news sites (CNN.com comes to mind), and while this may be criticized as a lack of creativity, sometimes congruence is helpful when browsing, to better give the sense that this is a news site, and not something else.

But of most interest to me was the transit to a standards-based, semantic website that properly separated content from style. Upon a quick first inspection, the site appears to make good use of proper XHTML elements, with not too many generic div elements used. This should make the site more friendly and accessible to a variety of browsers, especially those for the visually-impaired. The move also signals CBC’s commitment to web standards, something that, while having its share of growing pains, should help improve the state of the Web now and in the future.

The site also does a fairly good job on separating style graphics from content images - though the link images at the top should probably be put in place via CSS, and not be part of the markup. Another more serious problem would be the use of inline Javascript; in particular, the use of Javascript to submit the search form should have been avoided, as seen in this attribute:

onclick="javascript:forms.gs.searchWeb.value='cbc';
forms.gs.submit();"

I’m not sure what they’re using Javascript here for (as I haven’t bothered to look at everything), but chances are, whatever effect they are doing could be accomplished by using an external script file and then using event registration - all of the major browsers support this, and it results a better site because you don’t have messy inline Javascript calls in your markup. They are also using several onmouseover attributes to dynamically change images, which again, can be accomplished in a cleaner way using event registration.

Which brings me to my next point, that while CBC.ca did a good job of separating content and style, they were a bit sloppy when it came to content and behaviour. While the styles and visual layout information were separated out in a style sheet file, the Javascript governing behaviour was not. The mass of onclick and onmouseover/onmouseout attributes attests to this.

But don’t get me wrong. I have a very favourable attitude towards the new CBC.ca, and I while I may seem nitpicky here, I applaud their efforts as a move in the right direction.