Chris Casciano’s Place Name Here

On Friday Nov. 20th, ending a wall to wall week of conferences and general geeking out about web technologies I had the pleasure of both attending and speaking at Standards-Next at the Time-Life building in Manhattan. Industry big shots Håkon Wium Lie [inventor of CSS! OMG!], Molly Holzschlag, Andy Budd and Pete LePage of Microsoft [sans flak jacket] guided an enthusiastic audience through the tools we’ll be using to build web sites over the next few years.

Instead of writing about these things this week I let them fly into the twitter, IM, or news reader ether likely not to be mentioned by me again. Maybe I’ll make this recap a semi-regular features on this site as I expect to be quite busy over the next couple of months.

Creating a site for yourself has always been a refreshing outlet for web builders. Without rooms of stakeholders, you alone have the control over which technologies to use, what features to include and what browsers to support. Part of that control is deciding how you are going to deal with browser bugs and often having the freedom to take the ‘high road’ and leave defects be so that they can be used for bug reporting, test cases, and to help prod browser vendors into maybe making those bugs a higher priority.

While I have no desire to work around them for my personal site, I think its worth it to point out and work to get these bugs fixed at the source, including the following 2 CSS bugs with visible on the new Place Name Here that I decided to let be — one in Microsoft Internet Explorer 8 beta 2 and the other in Google Chrome.

So here I am a couple weeks after the IE team announced through a variety of different channels their proposal to help cushion the blow of their next browser release through the use of a META declaration and HTTP header, “X-UA-Compatible” describing what browser(s) the page and its associated styles and javascript files target.

I’ve got plenty of thoughts on why vendor extensions and related adjustments to behavior are bad. I also have some concerns over this one in particular. Extensions, and more general workarounds and hacks of all kinds [vendor driven or not] get buried into code, reused, copy and pasted, dropped in application templates, removed by accident, and generally used by people who don’t know why they’re doing it, but instead just because it works. As anything other then a very temporary, one time use solution this doesn’t seem to me to solve any problems that are inherent with either web standards or an ecosystem where content publishers are open to who they let see their content. But let me not get too far off onto that tangent and consider first that the proposed solution goes through.

For the moment I want to focus on the practical — what does the additional rendering mode and the ability to switch to it via META declaration mean to me as a working web developer?

Through ALA and the IEBlog comes a proposal for a new mechanic of handling the backwards compatibility of web sites — pushing the familiar DOCTYPE Switch aside and going with a new mechanism of declaring target browser versions via meta tag.

• Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 by Aaron Gustafson at A List Apart
• From Switches to Targets: A Standardista’s Journey by Eric Meyer at A List Apart
• Compatibility and IE8 by Chris Wilson at the IEBlog
• Opting-in to standards support and Microsoft’s Version Targeting Proposal at the WaSP

The perfect solution or the last sign of the web standards apocalypse? If you’ve got an opinion let it be heard.