This Thanksgiving I've decided it's about time that I provided some more background and analysis on one of the things I am certainly unintentionally (in)famous for. This entry was started at 7pm on Thanksgiving evening, but took me until now to complete.
Before CSS hacks
I don't know who first came up with using the presence of a 'media' attribute on <link> or <style> to hide CSS from Netscape 4, but it was the first technique that I remember hearing of to use a perfectly reasonable HTML feature (yes, the 'media' attribute is in HTML, not CSS) to deliver CSS selectively to browsers that supported a certain feature.
This HTML-based "filter" was perhaps the first such technique, though it would be many years before the term "filter" was introduced as a general term for such techniques.
Banishing version four browsers
The first filter I came up with (again, before they were named as such) was perhaps the @import with quotes filter, which I didn't even bother writing a page about in particular because it seemed so simple: @import "foo.css"; is only supported by IE5, NS6, Opera3 and better. I just posted an example usage at the time for Web Standards Project's Browser Upgrade Campaign (BUC). That particular legacy contribution was also made anonymously to one of the ALA redesigns, though I believe Jeffrey has outed me at some point since.
Neither the HTML 'media' attrribute filter nor the CSS @import quotes filter, in my humble opinion, qualified as hacks, because they lacked what some might term the essence of a hack:
either a kludge, or the opposite of a kludge, as in a clever or elegant solution to a difficult problem
. Neither of those filters were particularly kludgy (warning, not a Scrabble word), nor clever. In other words they were too "obvious" to really be considered hacks.
Seemed harmless
Anyway, the @import filter seemed harmless enough. At the time the only big difference it made was to filter out IE4.x (both Mac and Windows), which had already been obsoleted by IE5 (both versions). And it was praised as: ... for people who make websites, that is nothing short of revolutionary.
Sidenote: note the fact that that article on ditching <table>s for layout is almost FIVE years old
yet those of us that are real professionals still have to repeat the message .
Thus the idea of using a feature of CSS to essentially do a lightweight form of browser specific style sheet switching was born, but the Pandora's Box (Model) of CSS Hacks had yet to be opened. That would come exactly one week later.
Hacking open the Box Model and releasing the filters
Jeffrey Zeldman expressed to me how nice it was that it was possible to write CSS without having to worry about what might look bad in
(or even crash) obsolete browsers like Netscape 4. Having been freed to use more of (and depend more on) CSS, he and many others following A List Apart's suggestions quickly ran into the next issue which was the inconsistent box model treatment between IE5.x/Windows and IE6/Windows.
If only there were a way to send one width to IE5.x/Windows, and another width to modern browsers which supported the CSS box model...
is a rough approximation of what Jeffrey Zeldman said (emailed) to me at the time.
Eager to be helpful, and armed with the intuitive knowledge that the key to Pandora's Box of CSS hacks could be hidden amongst the jungle of CSS1 section 7.1 parsing tests, I went hunting. It didn't take long until (with Todd Fahrner's help) I discovered how test twentyb (rotation-code: "\"}\""; - look familiar?) messed up all versions of IE5.x/Windows,
but no other modern browser. After that it was a simple manner of finding an abandoned CSS2 property which accepted arbitrary string values.
I had opened Pandora's Box (Model) of CSS Hacks, and there was no turning back.
Shortly thereafter, I generalized the Box Model Hack to enable hiding entire style sheets from IE5.x/Windows and CSS Filters were born. More followed soon thereafter.
Intelligently designed hacks
Implicit in the story above are a set of design principles which I kept in mind when I first set about creating CSS hacks, and which I really should have noted at the time. Given all the hand-wringing about CSS hacks incited by my colleague Markus Mielke, it's about time I documented these principles. More on the hang-wringing later.
A CSS hack should (or MUST in the RFC2119 sense if you prefer):
-
Be valid. Invalid hacks are unacceptable. Back in the heyday of Web 1.0 (i.e. the late 1990s), the The Web Standards Project and numerous others were already spreading the message of better coding through validity, and thus hacks themselves had to validate as well. (Nevermind that many/most so-called "Web 2.0" sites can't be bothered to validate. See above about the real professionals having to repeat the message).
-
Target ONLY older/frozen/abandoned versions of user
agents / browsers. When the Box Model Hack was introduced, we were already playing with betas of IE6/Windows (back when we expected there would be an IE6/Mac), and so we knew how to make sure it wasn't affected. And now we're playing with betas of IE7.
-
Be ugly. It's actually a good thing that a hack be visually ugly from a coding aesthetic point of view in the hopes that the
ugliness will be a reminder that the hack is a hack, and should incite a tendency for people to a) minimize it's usage, and b) remove it's usage over time. At it's core, browser switching is one of those things you really shouldn't, but must, do to get your job done. Hacks' ugliness are like the equivalent of persistent warning tags, a reminder to dispose of them when no longer necessary.
Explosion of CSS hacks and filters
But I didn't document those principles at the time. Once said Pandora's Box was opened, it didn't take long for the notion that hacking CSS was a "good idea" to spread far and wide in the web design and development community (much further than I could have possibly expected, to the #4 result for 'hack' on Google, and even onto t-shirts!). Of course once hacks for IE5.x/Windows had been discovered, and refined into the concept of "filtering" which browsers got to see whole style sheets, it was only a matter of time before hacks were developed and documented for nearly every browser. Nevermind that so many of the hacks violated the above-mentioned principles. Those ideas spread and mutated without any such strings attached.
At this point I can only strongly recommend that people evaluate these myriad hacks based on the above principles before using them.
IE7 Team Puts CSS Hacks On Notice
Now, about that inciting and hand-wringing that took place last month.
The irony is that I don't disagree with the details of Marcus's MSDN post. Note that his "Call to action: Please check your pages" does not mention a single one of the CSS hacks I developed. The one partial overlap is the use of the child ">" selector, which was introduced as part of the Box Model Hack to "Be Nice To Opera" (Opera 5 in particular, which at this point is probably ignorable - anyone even hear of anyone that still uses Opera 5, even for testing purposes?).
The sad thing is that most of the hand-wringing could have been avoided (as noted in the comments) if people would first try fully standards based cross-browser solutions before resorting to hacks.
However, the undertone of that blog post (and what Markus and Chris Wilson have expressed to me and others in person) is that web developers must stop using CSS hacks altogether.
I know that's perhaps a bit of a hyperbole, but that's the message that's been heard nonetheless. However, such a message is, with all due respect, the impractical perspective of folks who are not a professional web designers / developers. I know this, I was there once too.
Avoid Targeting Current Versions Of Browsers
To be specific, the problems with hacks have arisen because of hacks that are targeted at a current browser, namely, IE6/Windows. E.g.
* html
Using A CSS2 Feature Is NOT a Hack
And a misperception that the use of an implemented feature is a hack.
E.g. people (ahem, starting with the "BMH" as noted) have used the child selector to send "valid CSS" to "compliant implementations", e.g. with
html>body
That's not a hack. It's not targeting a specific browser. It's actually
inclusive of all browsers who would support CSS2(.1) selectors.
Sending valid CSS to compliant implementations is proper behavior.
400 Tiny Violins For the Newcomer
(With apologies to Star Trek)
Does this make it harder for new/late implementations (like IE7) to come along and support that selector?
Why yes it does. This is no surprise.
If you support the child selector, now all of a sudden you have to
compliantly support all the other properties/values of CSS2(.1) that authors have been successfully using with the child selector.
But given that several other browsers do so (otherwise authors wouldn't be using the child selector), and thus the market has demonstrated this is not a problem, this is a reasonable expectation.
However, if a browser is somehow unable to do so, then the answer is simple.
Don't implement that selector, until that browser is able to do so. IE5/Mac did so, so can IE7, more than five years later...
This may seem "unfair" that that these features (a CSS2(.1) selector and
some CSS2(.1) properties/values) are now "tied" together in terms of
requiring implementation support, but guess what?
CSS2(.1) doesn't say you can implement part of the spec. You're supposed to implement the whole spec in the first place.
The Red Queen Problem
Obviously this was hard (in fact, impossible for self-contradicting and ambiguously written REC-CSS2 in 1998), and browser vendors (yours truly included) tried to do the next best thing, which is to implement logical "chunks" of CSS2(.1).
Well it's been 7 years since REC-CSS2, and those logical "chunks" have simply grown, more, chunky, as it were. They've also been clarified down to previously unseen levels of details in CSS2.1
You need to keep coding just to keep up.
Support CSS 2.1 NOW!
The bottom line: eventually what will happen (within a couple of years at most?) is that so many browsers will have implemented all of CSS2.1, and authors will be writing with that in mind, that any new browser that wants to support part of CSS2.1 will have to support all of it in order to support the style sheets in the wild.
IMHO, that's called progress.
For Now
But we don't have any fully compliant CSS 2.1 browsers yet. And we still have obsolete/abandoned browsers with enough marketshare (or machine dependence) to warrant the incremental bit of effort to support them. So for now:
- First try to simply author standards-based cross browser designs.
- Validate, validate, validate.
- Check any browser differences to see if your code is perhaps depending on an implicit browser default style sheet (like the example of the visible empty
<legend> in IE6/Windows), and specify that styling explicitly instead of depending on the defaults.
- Use CSS hacks and filters sparingly (and only as needed) to get non-compliant obsolete/abandoned browsers to comply to your presentational wishes.
- And keep the pressure on the browser vendors to implement the web standards all of us web developers depend on to get our jobs done.
If you've made it this far, you've been extraordinarily patient and have the attention span of a savant. I wish you a happy Thanksgiving holiday.
[This entry originally posted over here.]
In Molly's recent WaSP buzz, Web Standards and The New Professionalism she offers:
Today, I want to express that I believe that this new professionalism means taking responsibility for the education of ourselves and each other, and ensuring that reversions like Disney Store UK never happen again.
As part of the WaSP Edu TF, I am here to say that we need more effort in more areas, as a group, as a *New Professional*, as an individual. It is not enough to educate ourselves and each other, though it is a good plan and a start, and not all that new. We need to educate, promote, and advocate change to the educators, schools, and the programs or courses. The state of web related education is sub-standard in most cases. The degrees and training signify little in many cases. A lot of work needs to be done.
Many of us, *Old Professionals* have been involved in mailing lists and online communities advocating standards, accessibility, guidelines as well as offering help, information, and resources for several years. We do it because we are passionate and believe in what we are doing. Advocating has not been easy, but it is rewarding and exciting to see change and understanding grow. We have been doing this since the mid to late 1990's, and much of the early advocacy and information exchanges were the groundwork for all the excellent information and resources that exist today. We need to look outside of our web community and start working in other areas, too.
It has been a long road and we know the learning is a never ending process. Our CSS and markup education and skills may have come from a variety of web site offerings and articles: The CSS Pointers Group, Westciv: House of Style, Rich in Style, Brian Wilson, HTML help, AnyBrowser.org, HTML Goodies, Matt Haughey, Todd Fahrner, Dave Baron, Eric Meyer, Jeffrey Zeldman, and several notable others, including the W3C and The Web Standards Project. For many of us, our tools were text editors and the W3C validators, and the first validators were a challenge to use. For many of us, the text editor and validator are the same tools we use today. We have come a long way, Hobbes' Internet Timeline (1950-2004) and DejaVu.org, but we have a long way to go, and a lot of work to do.
We need to increase our efforts and focus to Education. In the recent buzz by Molly, she offers a quote by Andy Clarke:
There are now so many web sites, blogs or publications
devoted to helping people learn standards and accessible techniques
that there are now no excuses not to work with semantic code or CSS.
At the EduTF we realize there are no excuses and we also see many reasons why standards and accessible techniques are not being taught. Addressing these issues is part of the work we are involved with behind the scenes. And we have been very busy.
Many schools are not teaching standards, guidelines, accessibility, and best practises. They are teaching the opposite. Just a few weeks ago a frustrated student in a web program contacted our EduTF and told us that he had to use table markup for layout on his final project even though he was aware of and knows how to use standards and CSS. If he did not use the table for layout, his grade would have been marked down. The student in the program is enrolled to get a degree so his work and skills are more recognized. There is something seriously wrong with this situation. What will that degree mean? Does it represent a quality education where needed skills are taught? No. The same student is keeping in touch with us and sent us information on his current course, a web scripting course which offers up the advice of not to use CSS. It's not important to single this institution and program out, because there are many more out there. Many of us feel that this situation and others like it represent the majority of educational institutions. We need to address this issue.
In a recent Interview of Mark Trammell at Digital Web Magazine, Mark offers up several thoughts involving education. Here are a few of his words regarding web education in Universities.:
University Web design courses are an ideal time to start young developers thinking in terms of separation of content from aesthetics and behavior, but unfortunately, this is rarely the case. If the correspondence I receive from students in higher education Web design courses is a true barometer, academia is not keeping up with the Web's progression. Students often complain of being taught development practices circa 1998, at best. Photoshop slicing and table-based layouts rule the day in most courses and the Web suffers for it.
The EduTF knows there are several factors or challenges involving the poor educational situation and we are working behind the scenes with educators, web developers, students, and advocates. The educators, staff, and administrators may not be aware of or are not teaching these skills to students. The courses offered by many institutions do not have strong guidelines, recommendations, and outlines of updated material to be taught. A course in web authoring or web design may not fit into any one department, the materials and learning fit into many departments: technical, art and design, communications, business, sociology and psychology. Web Design is about functionality, usability, and aesthetics. The students need to learn a lot and by the time of completion of their courses they should have a basic and solid foundation and skill set that includes standards, guidelines, accessibility, and separation. The students should also be aware of how to continue to update their skills or keep up with emerging technologies and change, by learning about how to network, how to find new information, and research skills.
Standards, guidelines, accessibility, and separation skills need to be taught to developers and designers. We need better applications, software, and content management solutions. We need better ecommerce applications, better educational software, and coursewares. So developers in computer science departments need to know and learn these standards, too.
The Trammell interview also offers up some comments worth reading following the article. In particular, Richard Quaite states:
I for one have spent years complaining about the lack of suitable
graduates, and suffered when trying to recruit-I'm sure I'm not alone.
Quaite worries that others trained and working in the field will get turned off by lack of support and opportunities. He gave some ideas in helping to support education. As employers, we could offer internships and experience for undergraduates. When there are conferences or events, we could extend invitations to undergraduates, educational institutions, and departments. As a WaSP EduTF member, to those offering internships or on the job experience opportunities to students, find out what the student knows or what is being taught and if it does not include standards, guidelines, accessibility, get involved with the institute and its program staff and let them know that they need to change or update their materials. Institutions teaching standards may have more internship and experience partnerships and may help increase post graduate placement and recruitment possibilities for its students. Educational institutes that make these partnerships and open up opportunities for its graduates may also attract more students to its programs. We need to get creative about promoting standards in many ways.
Again, this is just some of what we can do to help promote, advocate, and change the situation of standards in our community, beyond our community, and for the future. We have a lot of work ahead and we need to get help and information out to those in Web Education. More institutions need to start teaching and producing web designers and developers as new professionals, too.
[This entry cross-posted to take your comments and trackbacks.]
With the aftermath of the Disney UK Store redesign fiasco still ringing in our collective ears, I am coming to believe that we're in a process of defining a new professionalism for Web developers and designers.
In an interview with Accessify's Ian Lloyd, Accessibility: The gloves come off, my oft-colleague in the education and training of Web designers and developers, Andy Clarke, delivers a strong message that needs to be heard:
"Those people still delivering nested table layout, spacer gifs or ignoring accessibility can no longer call themselves web professionals."
The heart of the issue is simple: We must know our craft! And what we don't know, we must be willing to say we don't know and be open to learning. As Clarke points out:
"There are now so many web sites, blogs or publications devoted to helping people learn standards and accessible techniques that there are now no excuses not to work with semantic code or CSS."
We also have each other. Between the blogs and various sites, lists, wikis, meetups, geek dinners, and conferences there simply is no excuse to not reach out and help each other understand the difficulties, nuances, and challenges of our craft.
In another recent article, AT&T: One Full Year with Web Standards, Joe D'Andrea discusses his experiences bringing that monolith into the standards age.
Joe writes:
"I'm incredibly pleased - and proud - to have helped www.att.com and others at AT&T evolve from a hodgepodge of largely nutritionless mid '90s-era markup to their current leaner, healthier state."
Whatever we call it - Web 2.0, evangelism, religion, or simply the best way to do our jobs, I can't agree more with the strong yet very clear message that real-world Web professionals are sharing. No doubt that getting to a highly skilled level isn't that easy. Believe me, I understand. I've been at it for the majority of my career and as the old adage goes, the more I learn, the less I realize I know.
The essence of this new professionalism isn't about being perfect at what we do. It's being able to say: Hey, I don't know that. Let me go find out!
It isn't about knowing it all, because we surely never will. And, there will be shifts and changes. D'Andrea, for example, expresses that he's concerned how new senior management at AT&T will deal with the site from here forward.
We can save the discussion of consumer rights and our role in assisting consumers for another day. That, and the subtle fixes that Disney Store UK has made since the public outcry less than two weeks ago. Obviously, someone got the message, but it still isn't good enough. Again, more for another day.
Today, I want to express that I believe that this new professionalism means taking responsibility for the education of ourselves and each other, and ensuring that reversions like Disney Store UK never happen again.
[This entry cross-posted to take your comments and trackbacks.]
Dear Disney Store UK,
I would write this to you directly via your site feedback page but it is throwing Access database errors. The email appears to be down as well. So instead, I’m going to write my letter here in a public forum in the hopes that someone from your team sees it and takes heed.
Your so-called redesign is a travesty, a tragedy, and an embarrassment. Your prior store was not only far more beautiful visually, but was a magnificent example of standards-based design. Perhaps more importantly, the site was also accessible under the UK’s Disability Discrimination Act (DDA).
You now have a site that regresses back to all the bad habits that have hurt the progress of Web development and design. Here’s what you can expect from what you’ve done to your site:
- Performance will become slower. Due to the overblown markup and inclusion of massive JavaScripts within each individual document, your site will slow down considerably. Not only that, but because of the table-based layout method, each page loaded has to not only redraw each of those tables (which takes two passes of a browser rather than one) it’s carrying both the presentational and behavioral baggage from page to page. I feel really sorry for your potential customers at large, and even more so for those who are on dialup. I really do.
- Your site will become significantly more difficult to manage. Want to change something in the visual presentation of the site? You now have to change it in every single document. So, instead of opening a style sheet, making a change in less than a minute, and having that change automatically distributed to all pages linked to that style sheet, you will have to search and replace. That adds a margin for critical errors, which can in turn make changes even more complicated. The same holds true of your scripts, which are embedded into each document. You’ve completely lost the ability to effectively manage your site, much less redesign it effectively when the time comes.
- Your site will become more expensive to maintain. Because of the document management issue, money and time will be spent every time a change is required. Your bandwidth costs are going to skyrocket, particularly now as we approach the holiday season as your traffic is likely to increase significantly during this time.
- The site may experience a drop in search rankings across all engines. Even if that doesn’t happen, apparently, according to Google, you are selling a product called spacer gif. What in the world are those? Oh yeah, wait! I remember! They’re an outdated, unnecessary method in today’s contemporary design and development approach. Spacer gifs, in case you don’t know what you’re pimping to the world, are a means of keeping table based layouts from collapsing in on themselves. And now, as Google so clearly tells us, they are part of your catalog. I’m not convinced you’ll get much sales on spacer gifs, but you never know.
- The site is unusable for any blind person who might like to visit. But you know, blind people probably don’t want to buy Disney products for themselves, or their children and families anyway, right?
For taking a beautiful design developed with all of today’s modern approaches that gave you so many benefits, made us proud of you, and provided a shining example of effective use of markup, CSS and accessibility features and re-doing it using outdated and inaccessible methods, I say shame on you and I repeat, this is a travesty, a tragedy, an embarrassment.
Shame on you Disney.
Molly E. Holzschlag, Group Lead, Web Standards Project (WaSP)
[Cross-posted to take your comments, and by all means, someone from Disney please do in fact comment, we’d love to hear your response.]
In mid October, the IE Blog urged developers to stop using CSS hacks to workaround IE's problems, and start relying on Microsoft's proprietary conditional comments. I wrote up my thoughts about the new syntax, and it seemed practical enough considering that IE7 is looking to address most of the reasons you'd hack in the first place.
But it was clear that some of you have discovered non-trivial problems in working with conditional comments — for instance, they don't work in a one-PC, multiple-IE testing environment, and XSL doesn't peacefully co-exist with them. So when I heard certain WaSP members would be meeting with the IE team, I compiled a few direct questions for them to pose. Here are the replies from Chris Wilson and Brian Goldfarb of Microsoft, as transcribed by Molly Holzschlag.
- How do you propose we test sites relying on conditional comments across multiple versions of IE on a single PC? The current method we have of installing multiple versions of IE does not work with
conditional comments.
Chris Wilson replies:
"This is a tough one. Best way of testing IE with multiple installs is using Virtual PC. There is a way on Windows itself, but IE installs its components into system directories. You can cheat the system - add the DLLs in a separate directory named .local rather than going to the windows system. However, this is not actually replacing all of IE, it doesn't maintain a separate set of registry info, and you might end up pulling that information from the new install.
With VPC, you install multiple versions of Windows installs as you have disk space. It's basically best way to do testing on one machine, have a massive machine run VPC with multiple windows installs . . . Need a lot of disk
space, and may find some oddities because it's running as a separate virtual
machine.
I've done it, used it, but am not an expert."
- Why not implement conditional comments in CSS syntax, so we can move our filtering into external files and keep our markup clean?
Chris replies:
"I think it would be great if we provided a mechanism like conditional comments inside CSS. We've [Microsoft] thought about it, we're not going to do it in IE7 because we want to do it in a sane, rational way. You'll want conditional comments to be backward and forward compatible. Tough to design that into CSS so that it will actually work."
- How do you propose we use XSL to transform documents that use conditional comments?
Molly says that Chris would like more background about this. So a few solid examples/test cases where the conflict is clearly outlined would be handy right about now. A further question from Chris:
"Not sure what the input is in the initial comments. Are you concerned with input or output? And what are you trying to use the comments to switch?"
- Unrelated, but prompted by this discussion: why did it take years and someone outside of Microsoft to discover that it's possible to install multiple versions of IE? Can you confirm we will be able to continue using this method in IE7 and onwards?
Chris responds:
"It didn't take someone outside of MS to discover it. We knew about it a long time, we'd used it in development. We don't do that much anymore. Two big reasons we do not publicize this as a good idea First, unless you copy ALL the DLLs that IE uses, you don't necessarily know which version you're really going to. It kinda works, and if really all you want to do is load some HTML and see how it works, it'll work. If you use JavaScript or
networking libraries, timing could get weird and so on.
The other reason is because we get in a lot of trouble in the support side
if we tell people to do this - your computer breaks, the Web doesn't work,
you call up your computer manufacturer, spend an hour on the phone with them before you tell them about the multiple installs, the tech's don't know what you're talking about, and it causes a customer service nightmare.
You have to know what you're doing, and back it out after testing. We are not to my knowledge disabling anything that would change this for IE7 currently, but can't guarantee it'll work on Vista."
Brian Goldfarb went onto say that they got really strong feedback that they shouldn't push people to do this because of the customer service problems. It's an unsupported process: "Non-supported scenario. This causes damage to support scenarios." It is therefore a practical business decision.
Big thanks to Chris and Brian for their answers, and to Molly for posing them. Cross-posted to take your comments.
The WaSP Microsoft Task Force held another face-to-face meeting with available members on Tuesday. We met in a Starbucks along the waterfront in rainy Seattle. While the setting might have been a bit predictable, the conversation was unique and at times, very encouraging.
WaSPs at the meeting were DL Byron and myself. Microsoft was represented by a number of Web platform program managers such as the ever-amiable Brian Goldfarb, Sam Spencer, Rob Mauceri, and the legendary Chris Wilson, the Group Program Manager for IE Platform and Security who has worked on IE since 1995.
We discussed a number of issues including standards support in new software, the role of XAML and the Microsoft agenda, the Acid2 test, SXSW, and last but most decidedly not least, IE progress.
Standards Support in Upcoming Microsoft Products
There are three new tools at the ready for Microsoft, each being developed with the designer and design workflow in mind. The product of most immediate interest to WaSP is code-named “Quartz.” Rob Mauceri gave Byron and I a demo of the software, which produces XHTML 1.0 Transitional out of the box and also supports other relevant DTDs. No tables for layout, all CSS, which is great news and worthy of a hearty round of applause.
Drilling down into the markup and CSS, the tool is not without common problems we’ve seen with other designer environments. The XHTML and CSS generated are not as intuitive and useful as they could be, with lots of span elements, classes up the yin and out the yang, and a tendency toward presentational naming. Fortunately, a skilled CSS designer isn’t blocked by the tool and is in fact able to use it to create leaner, meaner markup and style in much the same way that familiar competitive tools provide.
Not perfect by a long shot, but unquestionably a potential software addition for any Microsoft developer interested in improved workflow along with XHTML and CSS support.
XAML and the Microsoft Perspective
One of the most common questions I get asked when discussing the WaSP Microsoft Task force is “what about XAML!” XAML, the Extensible Application Markup Language, is a Microsoft-specific language that many fear Microsoft will use to leverage its hold on the Web at large.
XAML is at the core of the majority of Microsoft tools development, which does suggest that when in Microsoft, do as Microsoft does. There’s what might be described as a paradigm shift for Microsoft, though. Along with XAML-based applications, Microsoft is concurrently including a subset of XAML that would be more readily useful for cross-browser, cross-platform solutions. The Windows Presentation Foundation Everywhere (WPFE) will enable developers to work within the XAML subset. Sam Spencer describes XAML and its subset broadly as “Two different kettles of fish.”
Chris Wilson digs a little deeper. He describes XAML as “a rich client experience,” and the Web itself as being a rich experience. In simpler terms, XAML provides a rich experience if you’re on Windows and developing for Windows. You’ve got “everything you need to build a Windows app.” According to Wilson, XAML isn’t intended to replace HTML. While it’s a Web language, it’s about platform. A developer would choose a situation and determine whether a XAML application is appropriate, or the WPFE subset, which relies on JavaScript, is more appropriate. “WPFE” he says, “gives you a migration path from a rich experience to a broader experience.”
I can’t say I’m delighted with the approach, as conceptually any Web language that is platform-specific goes against the spirit and vision of the Web. At least Microsoft is strategically providing some alternative that would be more conducive to interoperable ideologies, but only time will tell how this concern really does play out.
Want Some Acid2?
It was very interesting to be able to talk to Microsoft the day after Safari released the first distributed browser version to pass the Acid2 test. With Opera 9 only steps behind, and the KHTML browsers (such as Konqueror) already sporting an updated codebase, the KHTML browsers (such as Konqueror) already sporting an updated codebase, and the upcoming iCab browser already passing the test in its pre-release beta version, the question of Acid2 compliance and Microsoft is at the ready on many a tongue.
WaSP has known for some time now that passing Acid2 wasn’t going to be a benchmark for IE’s development at this time, but Wilson, at least, has always been diplomatic about Acid2’s role. In fact, perhaps more diplomatic than the Firefox team, who have stated that Acid2 came at a bad time and wasn’t really relevant for their development process, despite their interest in and support of Web standards.
Maybe Firefox can take a lesson in diplomacy from Microsoft in this one. Wilson told me that he is well aware that Acid2 “tests a variety of features that Web developers would like to have.” He went on to say that he supports the goal, and complimented the Acid2 guide for being well written and fully laying out for developers exactly what is being tested. He finished up his comments on Acid2 by assuring me that IE will pass the Acid2 test at some time in the future, but to not expect it by IE7’s release.
SXSW
We’ve not yet announced this information to the public, and more details will be forthcoming soon, but WaSP will be holding two important sessions during the March 2006 SXSW Interactive Media Festival. First, we’ll be holding a panel.
WTF? Another panel you say? Well yes! This time it’s the WaSP Task Force panel, in which WaSP and leaders from our Task Forces will be present to discuss what we’ve all been up to in the past months. Expected panel members include myself as moderator, Drew McLellan for WaSP strategy; Chris Wilson (Microsoft) on the WaSP / Microsoft relationship; Jennifer Taylor (Product Manager, Macromedia Dreamweaver) on standards support progress in Dreamweaver and related products; Dori Smith, co-lead for the DOM Scripting Task Force and long-time WaSP member on scripting progress; and Matt May, Accessibility Task Force lead, on WaSP activities related to accessibility.
If that doesn’t sound like an interesting panel, come watch WaSPs buzz in real-time. We’re very pleased to announce that our annual WaSP meeting will be held live and in public under the auspices of the SXSW crew. This will include every WaSP member who attends SXSW plus all task force participants, including significant representation from Microsoft and Macromedia.The first hour is our meeting, following rules of order but open for any member of the SXSW public to observe (we are also hoping to videocast it). The second hour will consist of questions we’ve collected in advance of the event from any interested individual (we’ll be setting up an email address, watch this spot for more information) and the final period will be available for open Q & A from the audience.
We look forward to your participation, whether you’re able to be present in Austin, or not. Again, more details will be forthcoming as the plans, participants, and locations are finalized.
IE Progress
Many readers here also follow the IEBlog (a good practice for contemporary Web developers and designers). Expect significant repairs to most existing bugs, implementation of long-awaited CSS features such as fixed positioning, child selectors, and attribute selectors. Alpha transparency in PNGs? Yes! The XML declaration will now be available without disturbing the DOCTYPE switch, and object handling will be improved with proper fallback.
However, some things simply won’t be there. Generated content? “Won’t make it” Wilson tells us. There’s an overflow problem that probably won’t be fixed, and object for images will most likely not be repaired in IE7.
Wilson remains optimistic and philosophical however, wrapping our conversation up by saying that “I knew when we started IE7 was going to be a challenging release for us, we weren’t going to get as far as people wanted us to get.”
It’s been my opinion all along that Wilson’s perspective is not unreasonable in the least. Anyone who expects immediate gratification for the support problems in IE is simply not realistic. Wilson sums this up himself, saying “I understand we might be the worst offenders today, but hey - I remember back when we weren’t the worst offender.”
And finally, a nod to his team and to the realities of IE’s future:
“The team has done a tremendous amount of work, but we still have a long way to go.”
Good Coffee
The meeting went well, and I’m always impressed by the way that Microsoft interacts with us. Bridges have been built, and we at the hive are confident that we can continue to be an encouraging, supportive resource for Microsoft developers, no matter where their business strategy might lead.
[This entry cross posted to take your comments].
