Go read his post Call for Action: The Open Web Needs You *Now*. Or read some of what I’ve excerpted below.

As in the past with IE6, it’s not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only “experimental” CSS properties prefixed with -webkit-* and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers.

In many if not most cases, the -webkit-* properties WebKit-specific web sites are using do have -moz-*, -ms-*, -o-* equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.

Emphasis mine. As I said in my previous post, a vendor prefix means that the property is in flux, and the syntax of functionality may change radically once it’s finalized and implemented. But here we have this mass of (primarily mobile-targeted) web sites* that are calcifying the web in its current state.

The problem is so bad that, as Glazou says in his post, other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. Yes, every major browser vendor, Opera included, will likely implement support for -webkit-* properties.

Save your celebration, son. Your laziness and myopia is what got us here.**. The best we can hope for is that Opera, Mozilla, and Microsoft agree to support the same set of -webkit-* properties, and agree to handle conflicts and cascades the same way.

But what if they don’t? Frankly, either way, we have a hot web development mess on our hands. We’ll either have more of the same proprietary prefix lock-in, or we’ll have a tangled mess of conflicting implementations.

Okay, so what can I do?

If there is any good news, it’s that you can get us out of this mess. Here’s how.

Step 1: Educate yourself about the state of browser support for CSS properties

• HTML5 Please
• When can I use
• www-style@w3.org Mail Archives
• CSS Discuss

Step 2: Use tools to make writing cross-browser CSS3 easier

• David Desandro’s CSS Textmate bundle
• LESS
• SaSS
• Compass
• CSS3 Please
• CSS3 Generator
• CSSLint
• Chris Coyier also has an excellent roundup of CSS pre-processing tools
• Or just write your own script to do it for you†

Step 3: Retrofit your existing code

That’s self explanatory.

Now ideally, you would also test in every browser. But I understand the tradeoffs between market share and time. For what it’s worth, Opera tries to make testing easier with its Opera Mobile emulator. You can also set up an Opera Mini test environment on your own machine. Firefox also offers a mobile emulator. For Android, install the SDK (it’s painless). Pro-tip: You can also run other Android browsers using the SDK.

Let’s not repeat the mistakes of years past in the mobile space. We know better, and we can do better.

UPDATE 1: Check out the Prefix the Web project.

*Having learned the lessons with IE6 sites that are optimized for larger screens are less guilty of this.

**Ever the one for fairness and nuance, I present Ian Lunn’s Vendor Prefixing: Standing Up for Developers.

<?php

$pref = array('moz','webkit','ms','khtml','o');

$str = '';

foreach($pref as $p){
   printf('-%s-%s;',$p,$argv[1]);
   echo "\n";
}

echo $argv[1].";\n";
?>

I am incredibly impressed with this dude’s ability to rhyme about web standards. Not that his rhyming skills are hot, mind you, but the subject matter isn’t exactly the stuff of legendary hip-hop.

Acid1 and Acid2 tested for compliance with CSS 1 and CSS 2 specifications. Acid3 also tests for support of DOM Scripting / ECMAScript, SVG and webfonts.

Safari 3 and Opera 9 pass the Acid2 test, as does the beta version of Firefox 3. Version 8 of Internet Explorer will also pass the Acid2 test.

Here’s how today’s leading browsers handle Acid3 (check out the reference image). Each image links to a larger screenshot.

Firefox 2

Opera 9.26

Internet Explorer 6

Internet Explorer 7

Safari 3

Firefox 3 Beta

About 6 years ago, I remember taking part in a conversation about preferred browsers on the Jane magazine message boards. IE 5.x was still king of the PC world. IE 6 was coming on strong. Netscape 4 was still widely used by universities. Netscape 6 was on its way.

Most of the respondents said they preferred Internet Explorer. Why? Because sites just “look right” and “work better” in Internet Explorer. My response at the time was simple: if a site doesn’t work in Netscape, it’s because the web developer didn’t know what (s)he was doing.

Of course, they didn’t care. They were far more into Sephora than HTML code quality. As far as they were concerned, Netscape was the problem. They didn’t blame crap code, or Microsoft for developing a browser that stomped harder than a Catalonian flamenco dancer all over the W3C specs and allowed ugly code to thrive. They blamed Netscape.

I was reminded of that conversation when I first read Microsoft’s recent announcement about Internet Explorer 8. After my initial D*MNF*CKINGBLOODYHELL!JUSTBREAKTHF*CKINGWEBALREADYMICROSOFT!WHATTHEF*CK? IAMTIREDOFYOURAGGEDYBASTARDSMAKINGMYDAYJOB1000TIMESHARDERTHANITNEEDSTOBEBECAUSEYOUCAN’T DEVELOPABROWSERTHATFOLLOWSAF*CKING10YEAROLDSPEC!!! reaction passed, I came to the following conclusion: this is the best approach to a bad situation.

Microsoft does not want to be where Netscape was. It’s a sad but true fact is that if a site breaks, the average web user — and, dare I say, average web developer — will blame the browser. Microsoft is too entrenched in corporate intranets and applications to let that happen. Doing so would cause a sh*tstorm of massive proportions for the company. From a business perspective, I understand.

And while I am also not happy about the default implementation (as Jeremy Keith explained Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.), opting-in to web standards eliminates the need to revise existing code.

Yes, it’s potentially a nail in the coffin for progressive enhancement techniques. Yes, we’ll still have to do something special to cater to Microsoft browsers. Yes, this could freeze web development at the IE7 level for years to come. But I believe — and it pains me to say it given the hate-hate more relationship I have with Microsoft browsers — that Microsoft, given its position, had no other choice.

But putting pragmatic approaches and practical considerations aside, I think Ben Buchanan said it best:

If they’ve included a DOCTYPE, they’ve declared they want to render to standards. If they did that in ignorance, it’s time they started earning their money instead of letting Dreamweaver do their jobs.

Related: Internet Explorer 8 Round Up

Validator S.A.C. is a Mac-only, stand-alone version of the W3C Markup Validator. With it, you can check the validity of HTML, XHTML, SMIL and MathML documents right from your desktop. Or you can run the validator as a web service on your Mac, which makes it available to other Macs on your network via Bonjour, and to other computers via IP. Plus you can run Validator S.A.C. from the disk image, or from a USB drive without installing.

The interface is nearly as easy to use as the online W3C validator. Enter a file’s location — either directly in the form field, or by selecting File > Open from the menu bar (or Command + O) — and click “Check” to validate — no Internet connection necessary.

Speakers include Molly Holzschlag, Garrett Dimon, Stephanie Sullivan, and Jared Spool. It’s really a top-notch list.

The LitePacific hack for example, works well in Internet Explorer 6 and 7, but also affects Safari. If you support Safari, you will also need to create a separate set of style sheet hacks to address differences in the way Safari and IE render pages.

CSS hacks also make your style sheets much harder to read. With conditional comments, you have to maintain multiple style sheets, but each style sheet is cleaner and clearer. Granted, with each new version of Internet Explorer, you have to update your header templates. But updating a header file offers far less risk than integrating new hacks into your style sheets.

Which necessary evil do you prefer? CSS hacks or conditional comments? Speak your piece in the comments.

I upgraded my own computer to Internet Explorer 7. And because I’m running Windows XP Home, I couldn’t use the Virtual PC disk image offered by Microsoft. But since I also need to test web sites in IE 7, downgrading wasn’t an option.

Then I found out about IEs 4 Linux. It’s a project that will install Internet Explorer versions 5, 5.5 and 6.0 on any *nix machine running Wine.

Now I don’t have a Linux machine. But I do have a Mac with a copy of Parallels installed. That means I could install Xubuntu, install Wine, and then install IEs 4 Linux.

And aww junk! It almost works like a charm. Just one hitch:* my web site looks all janky now because the fonts are different. Now ordinarily I wouldn’t care, as long as the functionality is preserved, but the whole point of this exercise is to see how most Windows users would see the site.

How to fix? Just install the msttcorefonts package on your Xubuntu install (Applications → System → Synaptic Package Manager). Restart your virtual machine, and your fonts should be loaded and good to go.

Cost of Parallels: $79.99. Cost of a full Windows XP Professional license: $279.99.

By the way, IEs 4 Linux recently released a beta version that loads the Internet Explorer 7 rendering engine on top of IE 6.

Hat tip: John Daigle who told me all about the Wine + IEs 4 Linux combo.

(*Okay, there is more than one hitch. IEs 4 Linux has trouble with some — possibly most — PNG files.)

I’m interested to know the firm behind the site.

UPDATE: As Paul Irish posted in the comments, Boston-based web firm Molecular developed the site.

As it turns out, in past versions, Outlook used two rendering engines. IE’s for reading content, and Word for composing messages. What this meant was that if you were replying or forwarding HTML emails, previous versions of Outlook would first use IE’s rendering engine to view it, then would switch over to the compose engine, Word.

Read the entire post for an explanation.

Related: Microsoft Outlook 2007: What you need to know when developing e-mail newsletters

So you check your code. You remove all of the line breaks and spaces from around your img tag. Then you refresh your browser window. And guess what: you’ve still got spaces.

The issue (properly) occurs when your document has a strict or XHTML 1.1 DOCTYPE (view an example). Most browsers (including IE 6) will add a thin space after each image. That‘s fine if you’re just organizing images on a page. But for e-mail layouts, and splash pages, you probably don’t want that space.

The solution

You‘re in luck: There are three.

• Switch to a transitional DOCTYPE
• Use an HTML 3.2 DOCTYPE
• Use the display: block; property and value of CSS.

Switching to a transitional DOCTYPE will send most browsers into quirks mode. You’ll need to use a few more hacks to get Internet Explorer 6 to behave, but it‘s not a bad option.

Using HTML 3.2 also provides good consistency, but you lose the ability to use CSS and scripting. It’s not so bad for HTML e-mails, though.

You could also eliminate the DOCTYPE entirely, but I don’t recommend this because it will result in all kinds of browser wackiness.

For best results, I recommend sticking with the strict DOCTYPE, and using display: block; in your CSS. Doing so presents the best cross-browser rendering, while still solving the post-image space issue.

More information on DOCTYPE switching

• Doctype switching and standards compliance: An overview
• Rendering Mode and Doctype Switching

I’m partial to two methods:

1. Using JavaScript to write the object and embed tags, and providing a <noscript> alternative, such as a static image.
2. Using the object element, and embedding alternate content (perhaps a still image from the animation) within the object.

Both options validate completely — even with the invalid<embed> tag in the first version. But, because of the way Internet Explorer, handles ActiveX controls, the second method creates a user experience problem.

I can’t vouch for the accessibility of either method. But they are two more options for embedding Flash (and other multimedia) content.

Related posts

• Get ready for the next version of Internet Explorer
• Flash, validation and the latest versions of IE