Every Time You Make a Good Business Decision, a Puppy Gets Cloned

A List Apart’s Issue #344 went live yesterday with a focus on the recent vendor prefix drama. I didn’t get a chance yet to read the entire Meyer/Tantek interview, but I did read Lea Verou’s piece.

First of all, congratulations to Lea for getting published in ALA. She’s certainly one of the most talented web developers I know, and deserves to be featured in such a context. I hope Zeldman and company continue to use new and fresh authors like her.

So what’s the point of my post here? And what’s the deal with the hyperbolic title that resembles Lea’s? Well, in many ways, this post is a response to what Lea wrote in her article. But this is not to say that what I’m going to write necessarily contradicts or opposes what she’s written. For the record, I agree with the spirit and forward-thinking approach in her post.

The Take-Away Message

Here’s what I agree with, that Lea emphasises in her post:

• We should not make it seem, through writing or other means, that proprietary features not in the spec are actually official CSS3
• This distinction between “vendor features” and “CSS3” is not nitpicking
• Browser wars-era code forking was an awful thing
• All developers should be aware of which features are in the spec, and which aren’t

I think for the most part her message is clear, and the attitude and viewpoint she is advocating is a good one.

Do you sense a “But…” coming? Yeah, I thought so. ;)

The Cold Reality

In the title of that post, which is in itself going to draw quite a bit of traffic, Lea implies that the consequences of promoting “vendor features” as if they are “CSS3” is dire and could cause horrible circumstances.

I’m an animal lover, so I don’t want to see any kittens die. But wait a minute — are any kittens actually dying because of this? Of course not, that’s ridiculous. They’re alive and well, and developers can put them to good use.

But that’s a problematic title, because it’s implying that something awful happens when we put vendor features that aren’t in the spec alongside standard properties. In that article, I can find only a few sentences that highlight the ‘dead kittens’. One is:

Proprietary features that haven’t been through the standards process usually suffer from poor design, even when the general idea is good.

Is that the dire dead-kitten consequence that we should be afraid of? Notice that even that statement had to be qualified by the word “usually”. Because, the truth is, it’s really not that bad.

The only other statement in the article that might harmonize with the dead-kitten theme is:

In our eagerness to use the new bling, we often forget how many people fought in the past decade to enable us to write code without forks and hacks and expect it to work interoperably.

As I mentioned, code forking from “back in the day” was bad. But this is really a non-issue today. Developers understand the concept of progressive enhancement/enrichment, and we know that browsers aren’t supposed to look the same everywhere. If we happen to use something proprietary because that browser’s share is large, we understand the consequences and we deal with that in an elegant manner.

I love the concept of interoperability as much as anyone. But we can’t lose sight of the fact that the people that are writing the specs and innovating often have interests that trump those lofty open-source-era goals we often advocate.

To be clear, I’m not accusing Lea of using a controversial headline to put across a message that isn’t congruent with that headline. I honestly believe that she and A List Apart agree that what she is discussing is a huge problem. But I don’t see it that way, and in my opinion too many things are being overlooked when we have such a purist viewpoint.

Who Implements CSS3 Features in Browsers?

When we discuss “open standards”, “the open web”, “interoperability”, and related terms, we act as if the people in charge of implementing CSS3 features always have our best interests at heart. As shown by the recent vendor-prefix drama, that is simply not the case.

Opera. Microsoft. Apple. Google. Mozilla. Those are the companies that will ultimately decide what features we can use. Guess what? They aren’t running soup kitchens for the betterment of humanity. They are multi-million dollar organizations that make money. Yes, even Mozilla.

That’s why a company like Google can pay a guy like Paul Irish good coin to be “a Google Chrome dev relations guy”. Because, believe it or not, that “free” Chrome browser that you’ve installed is helping Google turn a huge profit. Probably more money than you think.

And sadly, almost every W3C spec is edited or maintained by someone that has a stake in one of the big five companies. I’d like to believe that those editors are going to do everything in their power to make my life as a developer as easy as possible. But I’m not that stupid. Those guys have business interests to take care of, and they’re not going to sacrifice hundreds of millions of dollars in profits for the sake of “interoperability”.

Which brings us more directly to the vendor prefix fiasco.

Adopting “-webkit-” is the Only Option

As Tantek Çelik made clear in his discussion with Eric Meyer, The non-Webkit mobile audience, and subsequently the non-WebKit mobile-driven bottom line, is in jeopardy because the user experience in those environments is threatened.

Mozilla, Opera, and Microsoft are doing the only thing they know how to do: What is best for their long-term business interests.

I’m not saying I agree with their plans to support certain “-webkit-” features. But I echo the words of Chris Coyier when he says

And what if Firefox 11 starts supporting -webkit-? Doesn’t that just mean more websites will work better? What’s so bad about that?

No — Chris doesn’t necessarily hold that view right now, and he was merely brainstorming when he said that, pointing out some pros and cons. But the truth is, that’s the only thing that matters to the non-WebKit browser makers.

Whether you and I accept it or not, in the browser wars (yes, they’re back), business interests come first, and “interoperability” is squeezed in where it’s not financially inconvenient.

Developers Are Business People Too

As developers, we have decisions we have to make. When we decide what features to use and what not to use, we’re considering our own business interests first. If, after we’ve thought things through from a business perspective, we decide it makes good financial sense to use web standards, then we’ll do it. Gladly.

But let’s take something simple like the very well known opacity property. If we were to take such a strict view of standards, and never use IE-only filters, then we should not use the filter property for an oldIE fallback. To be clear, I’m not saying that Lea’s article is advocating such a strict policy. She gives some guidelines on proper use of such proprietary features, explaining how we can use them carefully.

The fact is, we have to use IE-only filters in some circumstances. Sure, we’d all love to be in the position to only accept work from clients who want to only work with web standards. But that is often not a good business decision, and it probably never will be for most of us.

We live in the real world. Our client wants that part of the page to look the same everywhere. We want the code to be maintainable. And we know that validation is just a guide. So we compromise. We don’t use images, but we sneak in a few hacks and proprietary features. As long as it doesn’t negatively affect performance, we’re fine with it, and the client is happy and will give us more work.

Proprietary Code Can Lead to More Business

Recently one of my client projects provided absolute proof that “WebKit-only” CSS is great for business. The client told me to code a bunch of HTML pages for him and he wanted the content jazzed up with CSS3 stuff. He said he wanted it to work only in Chrome. I was puzzled. He didn’t give me too much more info. I didn’t care. He was paying me, why should I care why he wants it that way?

I can’t give too may details about the project, but it turns out these pages were going to be used as a sort of rendering environment where the web app would actually take a screenshot of what was rendered on a Chrome browser, and then display it as an image to the user. So in this case, it was perfectly viable to use only WebKit stuff, and even to use stuff not in the spec.

But this is obviously a rare case, and Lea is certainly not telling us to avoid all proprietary stuff. She just wants us to use them carefully, if at all, and be accurate about how we describe these features. And I hope that’s what people come away with when they read that article.

But this illustrates the fact that the platform and the environment can be defined by the client, not by the developer. As much as we want and need an open web, sometimes business interests come first. If a client wants to develop a “WebKit-only” app because he knows that he’ll have 10,000 page views per day and doesn’t care about the other 10,000 coming from non-WebKit users, then who are we to argue with that? And if Mozilla wants to start supporting WebKit features so they can allow their users to get in on that app too, are we really going to be surprised?

Web Standards is Not a Religion

This is the one part of this article that I dreaded having to write. I love this industry as much as anyone. And I appreciate greatly the efforts that are put in by countless standards advocates in favour of a better web. But let’s not take ourselves too seriously here. Believe it or not, the most important commitments in my life have nothing to do with web design. As workers, we need to have a balance.

I want you to do something. Go to either of those A List Apart articles and do an in-page search for the word “evangel”. The kittens article uses that word’s derivatives six times. The Tantek/Meyer discussion uses it eleven times. That’s seventeen instances of a strictly religious term used in a single issue of A List Apart. Check out the definition, including it’s derivative.

Yes, it does have an obscure secondary definition in the vein of ‘strong advocacy of a cause’. But it’s primarily a religious term and, in my opinion, has no place in business. Otherwise we run the risk of placing more importance than is necessary on our trade.

And again, in no way am I trying to say that Lea or Eric or Tantek or anyone else thinks web standards is a religious movement. But if we’re not careful, we might lose sight of the fact that, at the end of the day, this is just a job for most people, and business interests will always take precedence over web standards.

Still The Utmost Respect

Nothing in this article should be taken to imply that I don’t respect and appreciate the people involved in web standards. I absolutely do. I’m glad Lea wrote that article, and I’m glad she politely took the time to point out that my CSS3 Click Chart could use some improvement. I will certainly do my best to improve it where I see the need.

Above all, let’s work together to solve problems for our clients using the tools at our disposal, so we can all make money in this industry. And let’s not get caught up in politics and quasi-morality, getting over-dramatic about what seem to be negative effects to the open web — an open web that is, whether we like it or not, controlled by multi-million dollar organizations.