Colin Cochrane

Colin Cochrane is a Software Developer based in Victoria, BC specializing in C#, PowerShell, Web Development and DevOps.

Internet Explorer 8 Beta 1: First Impressions

Since the IE development team releasing the first beta version of Internet Explorer 8 for developers last week, I've had the chance to play around with this latest incarnation of the Internet Explorer family.  While most of the focus has been on the improved support for web standards, which is immediately evident even in this early beta, there are many more new features and enhancements that are making IE8 look like its shaping up into a solid browser.

1) The Acid2 Test

First off, I'll confirm that yes, IE8 does pass the Acid2 test.

ie8-9

2) Loosely-Coupled IE (LSIE)

How many times have we all come across this classic?

ie8-1

Nothing was quite as annoying as having multiple tabs/browsers open and having an error on one page, or with a plugin, cause all of them to crash.  The IE development team has addressed this with a collection of internal architecture changes called Loosely-Coupled IE.  In a nutshell, what LSIE means is that the browser frame (everything other than the tabs) and the browser tabs are now located in separate processes, so if you visit a website that disagrees with one of your plugins, it doesn't result in IE completely crashing out.  Rather, you will see the classic "Internet Explorer has stopped working" window:

ie8-2 

Which is now followed with the problem tab being recovered, rather than the entire browser:

ie8-3

3) Session Recovery

IE8 also offers a new session recovery option for those instances where you have an "unexpected" end to a session.

ie8-4

4) Domain Highlighting

A new feature of the address bar now highlights what IE considers the "owning domain" of the site you are currently viewing.  At first it may appear strange, and somewhat unnecessary, but when you consider situations where unscrupulous webmasters try using subdomains to fool the user into thinking they are at a site they are not (such as www.domain.com.path.realdomain.com) this feature becomes a subtle, but useful visual cue to quickly draw your attention to the true domain of the site you are browsing.

ie8-5

5) IE8 Developer Tools

A nice addition for web developers is the built in IE8 Developer Tools, which is the successor to the IE developer toolbar.  It features some nice upgrades from the developer toolbar, such as the ability to changes rendering modes on-the-fly.

ie8-6

A beefed up style-trace, which breaks down each style being applied to a selected element (showing you what specific element the definition is inherited from, and which stylesheet the definition is located in), and allows you to toggle the application of specific style definitions.

ie8-7

ie8-8

Unfortunately the developer tools are not as comprehensive as the phenomenal Firefox add-in Firebug, but are still a big step in the right direction, and provides the functionality needed to take most style-based issues with a web page.

 

The IE8 beta is quite stable, so I encourage you to give it a try and see what you think.  I'll be posting more impressions as I continue using the beta, but I'd love to hear some more opinions on it, so please feel free to share your experiences and impressions in the comments section.

Web Standards: The Ideal And The Reality

There has been a flurry of reactions to the IE8 development team's recent announcement about the new version-targeting meta declaration that will be introduced in Internet Explorer 8. In an article I posted on the Metamend SEO Blog yesterday, I looked at how this feature could bring IE8 and Web Standards a lot closer together and find the ideal balance between backwards-compatibility and interoperability.  Many, however, did not share my optimism and saw this as another cop-out by Microsoft that would continue to hold back the web standards movement.  Being that this is a topic that involves both Internet Explorer/Microsoft and web standards I naturally came across a lot of heated discussion.  As I read more and more of this discussion I was once again reminded about how so many people take such an unreasonably hard stance on the issue of web standards and browser support.  When it comes to a topic as complex as web standards and interoperability it is crucial that one considers all factors, both theoretical and practical, otherwise the discussion will inevitably end up taking a "your with us or against us" mentality, that does little to benefit anyone.

The Ideal

Web standards are intended to bring consistency to the Web.  The ultimate ideal is a completely interoperable web, independent of platform or agent.  The more realistic ideal is a set of rules for the creation of content that, if followed, would ensure consistent presentation regardless of the client's browser   This would allow web developers who followed these rules to be safe in the knowledge that their content would be presented as they intended for all visitors.

The Reality

Web standards are attempting to bring consistency to what is a enormously complex and vast collection of mostly inconsistent data.  Even with more web pages being created that are built on web standards, there is still, and will always be, a subset of this collection that is non-standard.  There will never be an entirely interoperable web, nor would anyone reasonable expect there to be.  The reasonable expectation is that web standards are adopted by those who develop new content, or modify existing content, and that major web browsers will be truly standards-compliant in its presentation, so that web developers need not to worry about cross-browser compatibility.

One aspect that is often forgotten is the average internet user.  They don't care about standards, DOCTYPES or W3C recommendations.  All they care about is being able to visit a web site and have it display correctly, as they should.  This is what puts the browser developers in a bind, because the browser business is competitive and its hard to increase your user base if most pages on the web break when viewed with your product.  A degree of backwards-compatibility is absolutely essential, and denying that is simply ignorant.  This leads to something of a catch-22, however, because on the other side of the coin are the website owners who may not have the resources (be it time or money), or simply lack the desire, to redevelop their sites.   They are unlikely to make a substantial investment to bring their sites up to code for the sole reason of standards-compliance unless there is a benefit in doing so, or a harm in not doing so.  While the more vigorous supporters web standards  may wag their fingers at Microsoft for spending time worrying about backwards compatibility, you can be sure that if businesses were suddenly forced to spend tens of thousands of dollars to make their sites work in IE, Microsoft would be on the receiving end of a lot more than finger wagging.

I admit this was a minor rant.  As a supporter of web standards, I get a great deal of enjoyment out of good, honest discourse regarding their development and future.  This makes it all the more frustrating to read article after article and post after post that take close-minded stances, becoming dams in the flow of discussion.  The advancement of web standards is, and only can be, a collaborative effort, and this effort will be most productive when everyone enters in to it with their ears open and their egos left at the door.