After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome - it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page - no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list - this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well - the combined address bar/search bar is very much like Firefox 3’s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials - and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

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.

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.

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.