Working together for standards The Web Standards Project

I woke up this morning to find countless emails and IMs pouring into my accounts asking me about the IE 7 beta.

Some developers are expressing relief at seeing some of the bug fixes and improvements, but of course as I’ve been expressing all along, this is a process with which we have to be patient. Expecting full bug fixes and implementation in any beta software is ridiculous, as is expecting that WaSP / Microsoft Task Force can perform retroactive miracles.

IE7 is in beta. Not only that, but it’s early days yet. So it’s a little bit premature to start complaining that things don’t work. I mean, why have a beta, much less one that’s made it out first to developers and press if not precisely to get their feedback pronto? Brian Goldfarb, Product Manager for the Web Tools Team and Microsoft’s liaison to WaSP pointed this out in a conversation we had today while trying to address developer concerns as they’ve been pouring in.

“The whole point of doing a developer beta is to identify potential rendering breakages and changes and resolve them before we hand out IE7 to the broader marketplace. We are working actively to identify any issues with actual rendering problems and resolving those. This beta is one part of that mission.”

Browser Sniffing Smells Funny

One of the primary complaints coming in from developers has to do with browser detection. In an article published in PC Magazine yesterday, writer Cade Metz makes the following statement:

“At present, IE7 has a problem rendering some Web pages. According to Microsoft, this is caused by the sites, which need to update their detection code for IE7.”

This seems to be the paragraph that’s upset most developers. Metz could have helped keep concerns more effectively corralled by being less vague about what he meant, or by seeking out details from WaSP or related organizations who can best address this concern.

Specifically, any new browser version, whether it comes out of Microsoft, a new startup or a well respected search engine is going to have to be accounted for in any scripts that use versioning as part of the script. Fundamentally, this issue has nothing to do with IE, or Microsoft. What’s more, standards advocates have argued against the use of browser-specific detection as long as standards advocates have existed.

Dori Smith, long time WaSP member and WaSP DOM Scripting Task Force co-lead responds:

“It’s long been known that scripters should write their code to check for objects, not particular browser versions. The DOM Scripting TF is working on documenting best practices for scripting, and this is one of the elementary building blocks of good coding style. Scripters whose code follows best practices don’t have problems when new versions of browsers are released – and scripters know that new versions will always come out in the future.”

Jeremy Keith, who co-leads the DOM Scripting Task Force along with Dori, added these thoughts:

“As the number of different browsers being used increases, browser-
sniffing scripts become more and more complex. They need to test for
all possible combinations of vendor and version number in order to
ensure that they work cross-platform. This is a Sisyphean task that
can result in extremely convoluted and messy code. Many browser-sniffing scripts test for an exact match on a browser’s version number. If a new version is released, like IE7, these scripts will need to be updated.

“Thankfully, the practice of browser sniffing is being replaced with
the simpler and more robust technique of object detection. Instead of
testing for a browser name and/or name, simply test whether a
specific method or property is supported. Then your tests will
continue to work in IE7, IE8 . . . ad infinitum.”

Both Smith’s and Keith’s words point to some critical concerns. To begin with, there’s the not-so-small fact that in a standards compliant environment, browser sniffing of this nature shouldn’t even be necessary. Web accessibility consultant and researcher Joe Clark points this out in his recent article on the subject, IE 7: The Saga Begins.

Another point is that the need to improve scripting practices on the developer side of the fence side is imperative. To fix that really is up to us as individual developers as we strengthen and hone our skills based on growing experience and awareness.

WaSP and Microsoft in a Tree

Scripting issues aside, let’s examine the role of WaSP and Microsoft IE, an issue that many are understandably concerned about. I can’t help but once again ask all readers to take a deep breath with me. WaSP’s direct involvement with Microsoft is brand new. Had we been in months ago, maybe IE7 beta would be different. Maybe we’d be further down the road to success. Maybe.

No matter, we weren’t there, and that was due to a lot of factors. So we got down to it and changed that. Now we’re here, and we all want to do what’s right. But anyone who thinks this is going to happen overnight is not being realistic.

As a fellow WaSP Microsoft Task Force member bluntly pointed out to me as I was trying to strategize how to respond to upset developers, WaSP should never act as Microsoft’s public relations department. And he’s absolutely right. WaSP isn’t here to forgive Microsoft for past practices.

However, as the relationship person here, I can only do my honest best to communicate both sides of what is clearly a complex concern. I can only work to assure you that I, and everyone within this Task Force is extremely motivated to make sure we keep things positive, honest, and respectful so we can continue to work together and hopefully, once and for all, achieve the goals we didn’t succeed at before.

So What Do We Do?

WaSP’s continued effort to work with rather than against Microsoft at a very frustrating time in history means that we all have to have patience, and we have to ask everyone to have patience with us in kind. This isn’t easy for anyone, not the Microsoft developers, not WaSP as an organization and of course not the working Web designer and developer.

WaSP liaison to the WaSP / Microsoft TF DL Byron points this out in practical terms:

“It’s much easier to criticize Microsoft than actually engage them. The constructive thing to do is to respond to the beta team and lay out your concerns.”

Microsoft already knows which existing IE 6.0 bugs need fixing, and what needs to be implemented to come up to full compliance. What you can and should do if you are on any beta for Microsoft is use the avenues available to you to identify real rendering issues and bugs and submit them. If you’re not involved in betas, drop by the IE blogs and let the developers there know in practical, respectful terms your constructive criticisms.

This entry cross-posted to my site to take your comments.

Return to top

Post a Reply

Comments are closed.