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.

However, this design constraint also imposes some problems on people with higher resolution screens who want the website to use more of the available space. (I personally run at 1280×1024, but prefer the smaller, fixed width as easier to read due to the smaller line lengths.) Well, taking a cue from some websites out there, I decided to implement a style sheet switcher that would allow users to pick which format they wanted. It’s now available - see that icon in the upper right corner that looks like this?

Simply click on it to toggle between a fixed a fluid-width layout, and view this site how you like it. At this time, I have no plans to add other different styles, as in my mind a simple switcher like this is all that’s needed. And, I don’t really feel like a re-design at this time; I think this current design is good at least for a few more months. (On a somewhat unrelated note, I’m currently working on a WordPress theme for public release though, stay tuned for more details.)

How’s it work?

The script I used was an older one, written by Paul Sowden for A List Apart. It’s almost five years old, but still works great with a few slight changes. What’s cool about it is that it saves your selected style in a cookie, so upon return, the website will know which format you prefer. So, while Firefox users have always had the ability to switch style sheets, this script adds to that by saving the user’s selection for future reference. The script also works fairly well across browsers; I’ve tested it in the latest versions of Firefox, IE and Opera.

I’ve also made it so that the script downgrades well - if for some reason, JavaScript is not enabled on a user’s browser, the style switcher icon will not be present. They will still be able to switch styles if their browser provides this functionality, though.

One hitch I ran into was with the use of this script with the IE7 fixes library by Dean Edwards. Using IE6, the style switcher doesn’t quite work; when clicked, the styles do not toggle, but the settings are saved via cookies. Thus, a reload of the page is needed to see the effect - not exactly ideal, and it makes it look completely broken. So, for the time being, I’ve disabled the IE7 fixes, and so far, nothing seems to be whacky with the layout of the site when viewed in IE6. (Dropping the IE7 scripts also will save about 24 KB in bandwidth per page viewed in IE as well.) There are other javascript style sheet switchers out there, so I may give them a try to see if they’re compatible, or if I have even more time, try to write my own. But the “problem” might be with the IE7 fixes.

Not that I mean to putdown the IE7 fixes - they’ve been a great asset at times when I’ve been too frustrated to figure out why IE was borking on some piece of CSS. I highly recommend IE7 if you’ve been pulling your hair out over some layout problem. I haven’t yet had a “real” problem with it, but as always, I try to use this sorts of fixes as a last resort - let’s see how long I can hold out for, and let me know if you notice any layout problems.

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.

That quiz would be SimpleQuiz XVI: Launching Windows. It proposes the question of what is the correct way to launch a new window for a hyperlink when it is clicked on. Since XHTML 1.0 Strict and XHTML 1.1 (without the proper module) do not allow the target attribute, this is a problem when it comes to validation. (HTML 4 Strict does also not allow the target attribute.) A limited set of solutions is intially proposed, but the comments quickly provoke more questions, such as: Should a website even be able to specify a new window for a link, to the chagrin of some users?

Many users felt that the answer to this such question should be a resounding “No”, as many people seem to be annoyed when the default behaviour of a clicked link is something else than they expect. This is understandable, as most of the people who are responding are undoubtedly “power users” who have plenty of Internet browsing experience and well-defined habits. However, many people are not like that and that nonwithstanding, I still think there are legitimate uses for launching a new window, for example, from a page that has been POST’d to, and as such, the web developer might not want the user to leave the page, which could perhaps expire the data.

Also, using the target attribute despite the fact that the attribute is not specified in those aforementioned DOCTYPEs is not an acceptable solution for those who take their validation seriously. That leaves the option open to using XHTML 1.0 Transitional, which I don’t believe is a problem, but many people will gawk at this suggestion as well.

Therefore, the solution of using JavaScript to perform the new window opening was suggested as the ideal solution, since, JavaScript should primarily be responsible for behaviour, and the opening of a new window is most definitely a behavioural aspect. However, as many pointed out, the implementation of this solution matters heavily. Simply putting an inline call to JavaScript in the XHTML code is no better than non-separation of content and presentation, since inline JavaScript combines behaviour with content.

In the end, the solution I liked best was to assign a class to any link that you wanted to open in a new window, then use JavaScript to navigate the DOM and change the target property of such elements to _blank. Though, some people will again go back to the first question, and say that you shouldn’t have any links open in a new window by default, and then back up this claim by saying that the “semanticness” is suspect.

A nicer solution would be to identify external links using different styling, and also have a JavaScript-enabled control on the page that could toggle the opening of such “external” links in new windows on or off. I’ve seen this before, and so a moderate knowledge of JavaScript and CSS would be all that was needed to make such a useful script.

But a bigger question that was raised in my mind was regarding the initial topic of separation of behaviour and style. In the current version of CSS, this may not be fully encouraged, in my opinion. The small example I have is of the :hover pseudo-class used as a selector. As many of you know, it allows the style of elements that recieve an “onmouseover” event to be specified. But, should any style changes be implemented this way, since it explicitly uses CSS to define a behavioural aspect, that is, what happens when the mouse pointer hovers over an element? Don’t get me wrong - I’m not trying to preach to everyone, as I’ve always uses the :hover as a selector; it’s just much easier than using a JavaScript solution, which is entirely possible.

But, then again, using the target attribute is also easier. Right now, I’m sort of confused - both appear to violate the separation of either behaviour and content or behaviour and presentation yet one is apparently condoned on the whole.