In a must-read post on IEBlog, Chris Wilson lays out some of the web standards fixes planned for IE7.
While it doesn't hit everything we might like, and we won't see most of it until Beta 2, it's a pretty impressive list for a release that by all accounts is primarily about security and UI features.
Even more impressive than the contents of the list, though, is that it's even available outside the Redmond campus. Having been through this 'work with Microsoft' thing once before in the late '90s, I can assure you this sort of openness is a radical departure from the Microsoft of old and as good a reason as any for optimism that this is just the beginning, and we can expect even more and better in IE 7.5 and beyond.
Three cheers for transparency! Three cheers for openness! Three cheers for standards in IE7!
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.
Since the announcement of the WaSP / Microsoft Corporation Task Force we’ve had two face to face meetings. The first was held in Portland, Oregon at WebVisions ‘05. WaSP members DL Byron and myself met with Microsoft’s liaison to the Task Force, Brian Goldfarb. In this meeting, we brainstormed potential strategies and discussed how WaSP can be of greatest assistance to Microsoft as it makes its products more standards compliant.
The second meeting took place in Seattle, Washington on Wednesday of this week, when I met again with Brian Goldfarb, whose primary role at Microsoft is Product Manager for the Web Tools team. We were joined by Chris Wilson, who readers might recognize from his many years as a developer for IE, and who is now lead Program Manager for the Web Platform in Internet Explorer.
We used our time to discuss specific activities for the WaSP / Microsoft TF in the months to come. Plans include arrangements for WaSP members to evaluate Microsoft product betas and overall strategies. We’ll also work directly with the developer teams to unveil concerns and make recommendations regarding the standards compliance in products including Internet Explorer, Visual Studio, .NET and a range of other Microsoft software and platforms where Web standards matter.
The bottom line? We’re talking, Microsoft is listening.
Not only has Microsoft offered an open door to WaSP’s criticism and ultimate assistance, but individual developers there are expressing a lot of enthusiasm about our relationship. Sitting face to face with Brian and Chris, it’s certainly clear to me that these are colleagues who not only get the importance of standards compliance, but want it badly, too.
What’s also clear is that the realities of software development cycles, company policies and security priorities all will influence the timeline of how standards are implemented and bugs repaired within the Microsoft line of products. That we all have to be patient is simply a reality, and neither faction is looking at this as a short-term stopgap, but rather a long-term commitment to the greater good.
As part of the Task Force strategy a plan to keep the Web design and development community informed at regular intervals of our activities and progress is in place. This means that there will be regular updates from both WaSP and Microsoft about our activities, milestones and successes.
My opinion of the meetings, the motivation on the part of Microsoft at large to be a more open company and the individual warmth, intelligence and interest in improving the circumstances Brian and Chris have demonstrated leaves me absolutely confident in saying that support for web standards is an issue Microsoft is paying attention to very, very seriously.
This entry is cross posted at my site to take your comments and trackbacks.
Kevin Lawver, AOL's representative to the CSS Working Group, is making a plea to the design community to give the Working Group feedback on the CSS3 Borders and Backgrounds module.
It isn't often one gets the opportunity to help define the tools you'll be using in your job, and this is a golden opportunity. There's quite a thread already started, but really it's nowhere near as exhaustive as one would expect for such a significant request. Let's change that, pronto: add your comments to his post and tell all your friends.
We've been waiting a loooong time for CSS3. Let's make sure it's worth the wait.
Web standards like CSS and XHTML are being widely adopted, thanks to the efforts of the WaSP and the legions of talented designers and developers who have embraced the technologies. Every day, standards are driving the structure and presentation of more and more websites.
Adding behaviour, on the other hand, is still seen as something of a black art. Using the Document Object Model with JavaScript has, until now, been neglected by many front-end developers. In an effort to promote a better understanding of JavaScript and the DOM, the Web Standards Project today announced the formation of the DOM Scripting Task Force.
Once you're done reading the press release, head on over to the Task Force website. Please excuse its slightly ramshackle state: the design is temporary and the content will be greatly expanded.
For now, there's a mighty manifesto for your digestion. There's also a blog if you fancy some light bites.
Over the coming weeks and months, you can expect to see plenty of articles and tutorials promoting usable, accessible JavaScript.
The web has long since moved out of the IT and design departments and become a pervasive communications medium. As a result, top-notch minds from other disciplines have begun to help make it more robust, vibrant and just plain useful than before.
Dr. Evola has one of these minds. He's applying it to the web in part by teaching a course on web standards at the College of Letters and Philosophy at the University of Palermo, Italy. Dr. Evola's linguistics background gives him a fresh perspective on web standards:
The first lessons deal with the "need" for XHTML and CSS, moving towards a more advanced knowledge of CSS1 and CSS2, keeping in mind that standards means nothing less than "speaking correctly" with our target.
Read the rest of the WaSP Education Task Force's excellent interview for more from a linguist turned standardista.
You might imagine that accessibility specialists are slightly odd folk. Close your eyes and imagine them sitting quietly in the corner of a pub, sipping mild and wearing Hush Puppies. On a crazy night they might break out the box of dominoes and make remarks about how wonderfully accessible those little blighters are. They might even grumble quietly about how inaccessible a bag of pork scratching is, but I digress.
These normally quiet accessibility fellows have got themselves in a bit of a tizzy in the last couple of days over the subject of automated accessibility tests and in particular the activities of a company called SiteMorse, whose automated software-based checks are aggressively marketed to public and private sector bodies through a campaign of regular PR.
How can everyone else be expected to achieve website accessibility, if the experts can't?
With their latest press release, SiteMorse have made many accessibility fellows spit out their beer by publically criticising many UK based accessibility specialist companies.
SiteMorse once again tested the 'leaders' of the field to find large gaps in what these companies claim to be their expertise and in their own capability to deliver.
Their press release names names in what has been seen by many as ungentlemanly conduct. Several subsequent articles have shown the depth of feeling against SiteMorse, their product, testing methods and marketing/sales strategy.
Holding hands across the table
I do not intend to comment either on SiteMorse, their product or their testing methods, although I will say that I find their negative marketing to be very much against the spirit of cooperation so encouraging within the accessibility community.
Many commenters have raised concerns over the secretive nature of the SiteMorse tests. As Mike of Isolani explains,
The SiteMorse product isn't publicly visible. There's no mention of pricing on their site. The website itself makes a series of unsubstantiated claims. Also, there's very little sign of the tool being peer-reviewed by accessibility experts. The SiteMorse product itself looks to be closed source, so its impossible for experts to analyse the logic to determine how accurate its automated test functions really are. The expertise of the developers is limited to a cluster of superficial questions to Usenet groups.
While I can fully appreciate the importance of a commercial entity to protect its intellectual assets, it is also important for specialists of all kinds and vendors to work together towards a more accessible web. In the WaSP Accessibility Task Force (ATF) we are seeking to work with all vendors towards this worthwhile goal.
In the spirit of cooperation I publically invite SiteMorse to get in touch and to work with the ATF with the aim of working with and providing developers and their clients more accessible solutions. I'll be waiting for the call.
Cross post
This is cross-posted to my site to take your comments.
Ever since we announced the WaSP Accessibility Task Force, quickly given the sticky nicky “ATF” the recommendations, requests and even a few ragings have been storm-trooping 'cross the Web.
Here's a round-up of reading associated with ATF activities.
Requests and recommendations
The following articles focus on requests from the ATF, recommendations, and general thoughts with opinions liberally sprinkled throughout (shocked, I know you are).
Opinion and editorial pieces
These are opinion and editorial-centric articles related to ATF:
Please be sure to take some time to read through the comments on many of these posts as there are some excellent thoughts, opinions and related links within them. This is cross-posted to my site to take your comments and trackbacks. If I've left something out that should go onto this list, please leave a comment for me and I'll add it.
The Web Standards Project (WaSP) is collaborating with Microsoft to promote Web standards and help developers build standards conformant Web applications.
Today we formally announce the WaSP / Microsoft Corporation Task Force. WaSP's goal is to provide technical guidance and advice as the company increases Web standards support in its products including Microsoft Visual Studio and ASP.NET.
“Standards are of increasing importance as Web developers strive to make their sites work across all browsers and accessible by the broadest set of customers.”
- Brian Goldfarb, product manager for Web Platform and Tools at Microsoft.
WaSP and Microsoft developers will work together to better understand and execute on Web standards as defined by standards bodies such as the World Wide Web Consortium (W3C).
For more details about the task force, please see the official press release. I'll take comments and trackbacks on my site for those interested in furthering the discussion.
Note: A German version of this press release is now available.
