If there’s one thing I’ve learned in my time developing websites it’s that well organized code is much easier to read and maintain. Whether you’re writing JavaScript, CSS, PHP, ASP, or whatever, a well thought out and organized file will make your life much easier in the long run. This is the first of what will become an ongoing feature where I’ll highlight quick tips or tricks that I find useful in my development work. First up, CSS…

Alphabetize Your Properties

This is something I started doing after seeing it mentioned in a BarCamp session last year. At the time I thought “Well, that sounds reasonable. I’m gonna try that”. Little did I know that once I got used to it it would take over my life! Here’s an example:


.foo {
background: #fff;
display: block;
height: 300px;
text-align: left;
width: 400px;
z-index: 2;
}


Once I started doing this it made things much simpler when trying to troubleshoot display issues. I no longer needed to read every property to determine if that element had a specific property set not knowing where I might have placed it. Did I place the “height” first or is it in the middle of the list of properties? Is it in the same place for every property? The answer to the latter was invariably “no”. Now, with things aplhabetized, I can quickly scan the list by just looking at the first letter and immediately know if a specific property is defined.

It’s entirely possible to group certain properties together and keep them consistent (and I do this on occasion) but I find that alphabetization is easier for me. I don’t have to remember whether I’ve changed my grouping methodology over time and try and determine when the file was originally written. Aplhabetization never changes.

Microsoft’s reversal on it’s version targeting scheme and the subsequent release of the first IE8 beta has certainly been the news of the week. Unfortunately I haven’t yet had the opportunity to install the beta and play around with it but I’ve been trying to find out everything I can about this most anticipated release. I’m planning on diving into the beta a bit this weekend at which time I’ll be posting my first impressions of the browser. Until that time I’ll have to satisfy myself with the reactions of others.

To that end I thought it might be helpful to provide a list of some of the articles and blog entres that I’ve found useful and/or entertaining. I’m sure anybody who is reading this will already be aware of most of these but it never hurts to get more exposure for some of these great writers/bloggers/early-adopters/gurus.

• Robert O’Callahan on IE8
• IEBlog on Acid2 test issues
• John Resig on IE8 and JavaScript
• Anne Van Kesteren on the bad in IE8
• IEBlog on Activities and WebSlices
• Dion Almaer on JavaScript and Render performance in IE8

Of course there’s no better place to get info than straight from the horse’s mouth:

• IE8 Beta whitepapers

If you’ve found any helpful links please feel free to share them in the comments.

This just in, winter weather advisory in Hell. OK, well maybe I’m just projecting from the frozen wasteland that New England has become this winter but still, the news out of Redmond is both surprising and welcome. If you hadn’t heard the news yet IE8’s proposed default behavior has been changed. IE8 will now act like IE8 for standards compliant sites unless otherwise specified.

Background

For those who have been living in a hole for the last month or so (or perhaps have been shoveling out of one) Microsoft had announced a radical new concept in forward compatibility for their upcoming release of Internet Explorer 8 called “version-targeting”. In the interest of “not breaking the web” they decided that all future releases of IE would make use of a new X-UA-compatible meta tag that developers could use to specify which version of IE the site was developed for. The result is that IE will always display the site using the appropriate version’s rendering engine essentially freezing the display of the site in IE. The benefit being that your website will always look the same no matter what future version of IE a user is running.

This approach in and of itself is not necessarily a bad one. It may not be ideal and it certainly hints at a number of implementation issues that are bound to crop up but the principal is sound. The IE team wants to help fix the mistakes of the IE6 to IE7 switch. The problem with their announcement however was not necessarily with the proposed fix but with the proposed default behavior in IE8.

The Issue

This is where Microsoft slipped up. The original proposed default behavior was to display all sites (standards compliant or otherwise) using the IE7 rendering engine. The only way to unlock the latest and greatest features of IE8’s newly updated rendering engine would be to use the X-UA-compatible meta tag. The thinking behind this was that it would allow any and all legacy sites that are currently working with IE7 to remain unaffected by the upgrade to IE8. The IE6 to IE7 upgrade path was certainly a rocky one for developers around the world who had to test all of their existing sites against the new browser and fix whatever issues cropped up and Microsoft had no desire to revisit that scenario.

This default behavior put the onus squarely on the “Standards aware” developers to make sure that they added the appropriate code to ensure that their sites could take advantage of the latest CSS and JavaScript changes in IE8+. This didn’t sit well with many developers who felt that it was a flawed fix and inexplicably “punished” the web standards crowd by making them put in the extra work to maintain compatibility.

Developers Respond

There was no shortage of opinions on the matter with many well known and well respected Web Standards and usability experts weighing in on both sides of the issue. Many felt that the idea was a welcome change in Microsoft’s stance on standards and usability. They felt that the new version targeting functionality would allow developers to publish sites without fearing any unexpected changes in future versions of IE. Others felt that the proposed behavior was at best a clumsy “fix” that threw the baby out with the bathwater and at worst an attempt by Microsoft to possibly start another browser war by allowing them to introduce any number of proprietary behaviors and functionality without fear of breaking existing websites.

At the end of the day the IE team decided that although they would leave the version targeting functionality in IE8 they would change the default behavior to the more logical option of displaying sites using the latest rendering engine while still allowing developers to lock their sites to a specific version of IE by using the X-UA-compatible meta tag. This decision is not without consequences however. Upon the release and adoption of IE8 developers of older sites will still need to check to see whether their sites are “broken” by the new rendering engine. Now however, unlike the IE6 to IE7 change, an easy fix will be available to them. They can simply add the new meta tag and never have to worry about it again.

The Aftermath

My stance on this issue hasn’t really changed much even with the release of this proposed change in behavior. I was never a fan of version targeting but I certainly didn’t like the original default behavior. I can live with the new proposal and feel that it can even be beneficial for “fixing” older sites with minimum fuss. However, my largest concern over the proposed version targeting scheme remains. Just how bloated will future versions of IE get when they need to support multiple versions of their rendering engine?

I don’t believe that Microsoft will include separate and unique rendering engines for all versions of IE7+. I’m sure that they will include this backward compatibility using some sort of conditional logic so that they can minimize the amount of extra code in future versions. Still, to me it stands to reason that at some point IE will reach a threshold where they simply won’t be able to support the earliest versions of the rendering engine without severely hindering the browser’s performance. Perhaps this will not happen for quite a long time at which point IE7 or IE8 support will be completely unnecessary. If that’s that case then there certainly won’t be any complaints from me.

Personally, I’m just glad that the responsibility for implementing standards support will remain in the hands of the browser makers rather than the developers. Developers should be responsible for creating sites that are usable and standards compliant and browser makers should be responsible for creating a browser that supports standards and usability. Now, can’t we all just get along?

So here it is, the inaugural post on the Codion Interactive blog. I’m thrilled, as all of you are I’m sure. There will be a fair number of changes around here in the coming weeks. For one, I’m going to be developing a new skin for the site. Don’t get me wrong, I think that the HijauSegar style from Lynette Chandler is great but, alas, it is only temporary. After all, what kind of designer/developer would I be if I neglected to design my own blog. Seriously. So that’s something to look forward to.

I’m also going to be adding many more posts and links to the site. Since this is a blog that probably goes without saying but I said it anyway. I’m not taking it back. Regardless, there are so many exciting things happening in the Web Development world that the problem will probably be figuring out what I shouldn’t write about. You can look forward to seeing me share my thoughts on current standards and practices in the web development community, great tools and resources that I find useful, and exciting changes and technologies that are on the horizon.

You may find my thoughts to be sagacious, poetic, or illuminating in which case I welcome you, dear reader, to share your thoughts as well. On the other hand, you may find my thoughts to be tired, pedantic, or poorly researched. If this is how you feel then let me assure you that this is strictly intentional. After all, the best way to foment meaningful debate is to offer an unconventional viewpoint and let the masses tell you why you’re wrong. Now that my shallow and transparent justifications are out of the way I can get to the work of crafting more inane posts.

I hope you’ll find all of this enjoyable, or at least entertaining in some way. Stick around, things are about to get interesting.

-Ben