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.
This whole prefix thing is a mess. My solution: one global “catch-all” experimental prefix like
-x-property. For inconsistent syntax support, use it multiple times and the browser picks whichever syntax they support.
The real issue with all of this in my mind is the fact that web development continues to become more and more fragmented, making the role of developers even more difficult. Browser wars, vendor specific prefixes, and all of those buzz words and phrases like “progressive enhancement” and “graceful degradation” all just point to the simple fact that developing a website that is truly functional and visually consistent across all modern browsers is difficult if not sometimes impossible.
I clearly understand the reasons behind everything, meaning most of it is business driven as you mentioned, but it also indicates that these businesses seem to have little regard for developers and users when they continue to go down paths that make site consistency across browsers more and more difficult.
I’m not so naive as to believe there will ever be some developer Utopia where you can code for a particular browser and it magically works and looks the same in every other browser, but for once it would be nice to see those driving the industry take steps that actually make things simpler for developers rather than more complicated.
@Ron: I agree with your overall desire that things should be more simple, not more complex. Still, the world is changing, and the bitter truth is…it’s going to be a lot harder. You categorize progressive enhancement and graceful degradation as buzzwords. But in today’s world of fragmented devices, browsers, operating systems, screen sizes…it’s a hard core necessity. The only sane way to move forward if you want to target a broad audience.
As for this article, I found there to be too much emphasis on business. I see the web as something much more broad and important than just the business aspect of it. I also think those able should not just bow to every business need that breaks the web, at the very least one can try to persuade the business otherwise, as often they are not educated about making these choices. If it comes to a showdown, you can still accept but let’s not rollover.
The article has “Business Decision” in the title – pretty sure the focus was meant to be on the business side of things. Just saying :)
I definitely agree with what you’ve said here, and I thoroughly understand why we need all of these differing techniques for accomplishing the same thing across different browsers. We’re basically building on what has come before what we have now, but unfortunately, those that seem to be doing most of the directing seem to be making matters worse.
I can see one of two things happening as a result of Mozilla’s adoption of webkit methods. Either the flames of the browser war are fanned anew and we start seeing more and more vendor specific coding as they all compete to be “the one”, or everyone starts moving to adopt a single, more unified standard with webkit leading the way. Personally, I’d prefer a more standardized approach to development in order to make our jobs easier, but I’m not holding my breath for that to be the end result of what Mozilla is proposing to do.
Bottom line, if supporting -webkit prefix in Firefox than Mozilla has lost the battle. Officially. Self admitedly.
As with NaCl, -webkit will be dropped in Chrome before you know it, in favor of normal properties name, leaving Frefox & Co. redface with shame they never stood their grounds when it mattered.
Will them supporting -webkit prefixed properties make for a better web for users? I really can’t see how. But I’m sure it will make for a better web for webkit vendors.
LL wrote in the first paragraph: “I didn’t get a chance yet to read the entire Meyer/Tantek interview.” Later LL wrote: “As Tantek Çelik made clear in his discussion with Eric Meyer.”
Since the article on ALA cited here by Lea Verou credits Meyer at the end as one of her “feedback” sources, and since LV in her blog entry preceding the one discussed here (subsequently published on ALA), mentions her being particularly reactive to what she describes a mis-statements by Tantek about her design philosophy in a CSS WG Minutes … statements which, according to LV, were later modified by Tantek …
I’d say this article is a form of “rant” which was not preceded by the kind of careful background research intelligent readers are looking for.
By the way, I share with you the opinion (bias ?) that if the client specifies they want something in a particular form, it is perfectly valid for the contractor/designer to agree to deliver exactly that. It’s also good practice, I believe, to find a way to gracefully inform the client of the consequences of making a browser-specific choice.
I also share your opinion (bias ?) that in the “real world” what is actually going to happen in browsers depends much more on the usual corporations. But, a vital standards organization, and a vital pro-developer community that do their best to put pressure on the corporate behemoths to standardize is …. maybe the best we can do.
If tomorrow Browser-X, with a tremendous market share, comes out with a way to replace the cost, overhead, and awkwardness of using iFrames, to render client-side page-invariant templates … see Lea Verou’s excellent blog post content on this topic in: “What we still can’t do client-side” dated Jan. 9, 2012 … let the browser wars escalate :)
So, in conclusion, I think your article is robust enough that it didn’t need to “piggy-back” on the title of someone else’s article, but the possibility you did not thoroughly research the context here is troublesome.
One further comment I meant to include: your semantic quibbling here about what you see as the mis-appropriation of “religious meaning” in the use of the word, “evangelism,” in modern technical journalism (within what may loosely be defined as “computer culture”) is a very narrow-minded literalism: do you reallly think that somehow Tantek and Verou are somehow “being profane,” and that has some implication relative to the technical merit of their discussions ? Your writing about this semantic topic here is an indirect form of “ad hominem” argument.
That said, and having had the un-pleasure of once meeting former jewellery salesman, one of the two original Apple “developer evangelists,” Guy Kawasaki, way back when, I did have a strange feeling, in his presence, that he was, perhaps, possessed by some “daemonic force.” The term “technical evangelist,” was invented by Mike Murray at Apple (former VP of HR for Microsoft before he joined Apple to work on the Mac). Perhaps Murray was infested with some demonic force at MS which he then infected Apple with ? :)
Keep writing and leave religion out of it.
I can’t argue with that! :) Totally agree that this was a rant. But even though I didn’t read the *entire* Tantek interview, I believe I read enough to understand his point about why they were choosing to consider support for “-webkit-“.
Besides, I didn’t hide anything — I openly admitted that I hadn’t read the whole thing. So is there anything I misstated, or misrepresented?
“Keep writing and leave religion out of it.”
That’s exactly why the word “evangelism” should not be used in a web design or business context. :)