WebKit, the rendering engine that powers web browsers like Google’s Chrome, Apple’s Safari, and soon Opera as well, has become a developer favorite thanks to its support for web standards and near-ubiquity in the mobile world.

Unfortunately for developers, WebKit isn’t always WebKit. While WebKit-based browsers share some code, not every WebKit-based browser behaves exactly the same way.

WebKit is an open source project with dozens of browsers based off the core code. But WebKit doesn’t have everything you need to build a graphical web browser, which means there’s considerable variation even among the two biggest WebKit users — Google and Apple.

To clear up just what WebKit is, and why there’s sometimes quite a bit of difference between WebKit browsers, Google’s Paul Irish — who is part of Chrome’s Developer Relations team — has put together a comprehensive guide to WebKit. Irish covers exactly what WebKit is, what it isn’t, how WebKit is used by WebKit-based browsers and why not all “WebKits” are the same.

Irish’s write-up should be required reading for all developers, but especially anyone who’s ever wondered why something works in Chrome, but not Safari; or why 3D transforms that fly in one WebKit-based browser crawl in another (short answer: GPU code is not shared among WebKit browsers).

When you’ve finished with Irish’s overview, be sure to follow the links at the bottom of his post for more details — particularly worth your time is Eric Seidel’s talk on how WebKit renders a webpage.

The proposed Pointer Events spec makes it easier to handle input from fingers, pens. Image: W3C.

The W3C recently moved Microsoft’s proposed Pointer Events spec to Last Call Working Draft. To help developers get up to speed, the IEBlog has published an overview of Pointer Events.

Microsoft has even helped to create a build of WebKit with experimental support for Pointer Events (for those not using Windows 8 or who’d prefer not to test in IE 10).

The goal of the Pointer Events spec is to provide a unified model for dealing with all the various input devices on today’s web, namely, the mouse, the stylus and the finger.

Pointer Events handle the various ways a user might be interacting with your site without requiring you to write unique code for each input method.

Currently most browsers register any input as a mouse event, even when it obviously is not (as is the case for most mobile browsers). It works, but it’s what you might call a blunt approach. Pointer Events adds some finesse to the equation, including details like the touch contact geometry size, the pressure applied or the tilt angle of a pen.

If you’d like to get your hands dirty with Pointer Events, either fire up IE 10 or download the experimental WebKit build and head on over to the W3C’s Web Platform docs. Microsoft’s Rob Dolin has a great overview tutorial with basic examples on how to get started. Also be sure to watch the video below from the recent W3Conf; Jacob Rossi, IE Program Manager gives a nice overview of Pointer Events and what you can do with them.

Right now only IE 10 supports Pointer Events, but Microsoft’s David Catuhe has developed a JavaScript polyfill, called HandJS, to support Pointer Events in browsers that don’t yet offer native support. Kudos to Microsoft for not just bringing pointer events to the W3C, but for working to add support to a competing browser and creating a polyfill for the rest.

WebKit: not actually one ring, but many, many rings. Image: Screenshot/Webmonkey

Opera software is abandoning its homegrown rendering engine in favor of the open source WebKit rendering engine. Many developers seem to think this means one fewer browser to test in, but unfortunately, that’s not the case.

The problem with the dream of less testing because there’s more WebKit is that “WebKit” can mean many things. The WebKit in Safari does not have all the features you’ll find in the WebKit that powers Google Chrome. The situation gets even more complicated with mobile where there are about as many different versions of WebKit as there are browsers.

As Mozilla’s Rob Hawkes and Robert Nyman point out in the post WebKit: An Objective View, that means “each browser will still have its own quirks, performance differences, design, and functionality. These should all be tested for.”

Worse, individual WebKit browsers can pick and choose which APIs to include in their final builds, which means just because something is available in WebKit, does not mean it’s available in, for example, both Chrome and Safari. Couple this with Safari’s relatively slow release schedule and just the two major desktop WebKit variants are going to require testing to make sure everything works.

Throwing a WebKit-based Opera in the mix just means another WebKit browser that needs to be part of your testing.

There’s nothing wrong with this state of affairs, nor will it change all that much when Opera is on WebKit as well, but it won’t mean less testing, nor is it going to make web developers’ lives any easier (especially since most of them weren’t testing in Opera anyway).

Testing will always be a necessary part of web development, but the danger that Hawkes and Nyman foresee is that developers will test less because they assume that if something works in one version of WebKit it will work in all of them. While that hasn’t happened yet, the CSS prefix debacle certainly doesn’t bode well for the WebKit-heavy future.

Opera software announced this morning that it is dumping its homegrown Presto rendering engine in favor of the increasingly ubiquitous WebKit rendering engine.

For all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine, mirroring what you’ll find in Google’s Chrome browser. Apple’s Safari also uses WebKit, though it has its own JavaScript engine.

Writing on the Opera Developer Blog, Opera’s Bruce Lawson says the first WebKit-based Opera browser “will be for smartphones, which we’ll demonstrate at Mobile World Congress in Barcelona at the end of the month.”

While Opera’s desktop market share hovers around 2 to 4 percent, the company’s two mobile browsers have, until very recently, been the most used mobile browsers on the web.

Indeed, while Opera’s official announcement is vague about the reasons for the switch, it doesn’t take a soothsayer to know that the reason is mobile. One influencing factor is no doubt the fact that Apple’s iOS only allows third-party web browsers if they use the built-in WebKit rendering engine.

Then there’s the -webkit CSS vendor prefix problem. At least some of the blame for Presto’s demise falls on web developers for developing against WebKit, rather than using web standards.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way. In fact, web developers fell in love with the -webkit prefix and often forget that there are other prefixes as well: -o for Opera, -moz for Firefox and -ms for Internet Explorer.

Using only -webkit means sites break in Opera even though Opera could have rendered the site just fine if the developer had bothered to include the -o prefix.

Of course, as Mozilla’s Christian Heilmann points out, “content not showing up or showing up broken in your product is terrible for a commercial company — the web is never wrong, if your browser shows it wrongly it is your fault, right?”

It would always be Opera’s fault in the eyes of most users and that’s why the company decided to support the -webkit prefix last year. In many ways today’s announcement is just one step further — if you’re going to support the prefix, why not just use the rendering engine? That seems to be exactly what Opera has decided to do.

So what becomes of the Opera features you know and love? The DragonFly developer tools are most likely done for, WebKit already has its own developer tools. It’s less clear what might happen to Opera’s other unique features like the built-in e-mail client or Opera Turbo, which compresses webpages to give broadband-like speeds on almost any internet connection.

An Opera spokesperson declined to comment on the future of any Opera features, telling Webmonkey only that “compression is in Opera’s DNA, but other than that we don’t talk about features of unreleased products.”

While I’m optimistic about Opera’s WebKit future, it’s hard to see the loss of a rendering engine as anything but bad news for the web. One less rendering engine means one less way to discover and fix bugs in web standards, one less place to see what you’ve done wrong. And Opera, while sometimes difficult to test in, was almost always right when it came to implementing web standards. In 13 years of building websites I’ve found no other testing environment in which I knew that if something didn’t work, it was almost certainly my code that was wrong. And I’m not alone; apparently even some Chromium developers feel the same way.

But that won’t stop developers who’d like to see a monoculture of WebKit from shortsightedly cheering this news.

Mozilla developer Robert O’Callahan summarizes why a WebKit-centric web is not a good thing:

some people are wondering whether engine diversity really matters. ‘Webkit is open source so if everyone worked together on it and shipped it, would that be so bad?’ Yes. Web standards would lose all significance and standards processes would be superseded by Webkit project decisions and politics. Webkit bugs would become the standard: there would be no way for developers to test on multiple engines to determine whether an unexpected behavior is a bug or intended.

WebKit makes a fine rendering engine and it does a good job of keeping up with web standards, but don’t assume that just because a web browser uses WebKit under the hood that it will render your pages the same as every other WebKit browser. Just look at the rendering and feature differences between Chrome, Safari, Mobile Safari and Mobile Chrome to get a sense of the pain that awaits developers yearning for a WebKit monoculture.

The other possible downside to a WebKit Opera is that the company’s once mighty voice for standards may not be heard as clearly amid the Google- and Apple-dominated WebKit developer culture.

Hopefully the WebKit community will find a place for the developers who brought us tabbed browsing, mouse gestures, “Speed Dial”, Turbo, and an uncompromising support for web standards that made Opera one of the first browsers to pass both the ACID 2 and ACID 3 page-rendering tests. For its part Opera is starting off on the right foot, offering up code that brings Presto-quality support for the CSS Multi-column Layout Module to WebKit.

Hopefully Opera engineers will continue to bring the same kind of innovation to WebKit and Chromium as they did to Presto and with any luck WebKit will listen and the web will end up a better, if less diverse, place.

Is it Opera or is it WebKit? Photo: Ariel Zambelich/Wired

If you’re curious and want to see how Opera handles -webkit prefixes, head on over to Opera and download the latest version of Opera Next for Windows 32-bit, Windows 64-bit, Mac or Linux. (Keep in mind that 12.50 is still a very early release and contains some known bugs.)

Opera’s decision to support another browser’s CSS prefix code has caused considerable outcry among web developers and members of the CSS Working Group, which created vendor prefixes.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way. In fact, web developers fell in love with the -webkit prefix and often forget that there are other prefixes as well: -o for Opera, -moz for Firefox and -ms for Internet Explorer.

The problem, in Opera’s view, is that instead of writing code that will work in any web browser, some of even the largest sites on the web are coding exclusively for WebKit (the rendering engine that powers web browsers on the iPhone, iPad and Android phones). Web developers have, the argument goes, created the same sort of monoculture that used to exist around Internet Explorer, with websites proudly proclaiming they “work best in WebKit.”

Opera decided that, in order to remain competitive, it needed to support -webkit in addition to its normal -o prefix.

The company previously updated its mobile emulator tool to support -webkit, but Opera 12.50 is the first actual browser release to do so.

Naturally the -webkit prefix support isn’t the only thing new in Opera 12.50. This release also manages to pack in an implementation of the Clipboard API, and Mac Opera users will find that Opera 12.50 uses Mac OS X 10.8’s coming Notification Center.

The mythical Jackalope surrounded by CSS bunnies. Image: Wikimedia

The mythical beast known as the CSS Variable is about to be released into the wild.

The WebKit team, which builds the browsing engine that powers both the Safari and Chrome web browsers, recently landed preliminary support for CSS Variables, which means variables will likely turn up soon in Chrome/Chromium and Safari nightly builds.

Variables used to be one of the most requested features for CSS, particularly from programmers accustomed to languages with variables. But, between then and now, CSS preprocessors like SASS and LESS have largely filled the role by offering variables (and more). Still SASS and LESS are not CSS, and do require compiling, so there may still be a place for variables in CSS.

There’s nowhere to actually test out CSS variables yet, but you can read up on the proposed variable syntax at the W3C. The spec is currently a working draft and may change considerably before it is finalized, but the proposed syntax looks like this:

:root {
    var-header-color: #06c;
}
h1 { background-color: var(header-color); }

The first rule is the new variable syntax and defines a property named “var-header-color” on the root element. Then you can use that variable throughout your stylesheets with the var(header-color) syntax. Also note that you can use variables within variables like this:

:root {
    var-my-color: #06c;
    var-background: linear-gradient(left, var(my-color), white);
}

There are some more examples of how to use variables on the W3C page, as well as in WebKit’s test suite.

The bad news is that variables aren’t backwards-compatible at all. Older browsers will simply ignore them (right now all browsers will ignore them) and if you’re defining key elements like background colors with variables the results in older browsers won’t be pretty. Eventually old browsers will fade away and CSS variables will probably become commonplace, but for the next few years at least we suggest looking to a preprocessor if you simply must have your variables.

The WebKit project, creators of the rendering engine that powers web browsers like Safari and Chrome, has added support for the new Intent tag, part of the proposed Web Intents standard.

Originally developed by Google’s Paul Kinlan, Web Intents are a kind of meta-website API that would allows sites to easily pass data between each other — for example, to edit a photograph or share a URL with friends.

Since Kinlan initially proposed Web Intents — which are based on a similar system used in Google’s Android operating system — Mozilla and several other companies have joined forces to work on standardizing Web Intents.

Web Intents offer a way to connect your favorite sites to each other and pass data between them. The canonical example is a photo-sharing website that wants to let you edit your uploaded images. To do that, the site simply adds a button, Edit This Photo, and behind the scenes the new <intent> tag tells the browser that the button wants to connect to a photo-editing service. The browser would then either connect to your favorite online photo editor or offer a list of options.

In practice Web Intents work a bit like mailto: links, defining an action and then passing it along to the browser, which allows the user to choose how to handle the action. The difference is that instead of opening a desktop app, Web Intents connect to web services. Here’s a barebones example of what the tag looks like (taken from webintents.org):

<intent 
  action="http://webintents.org/share" 
  type="image/*" 
  href="image.html" 
  title="Kinlan's Image Share" />

In this example the browser would then give the user a list of registered image sharing apps — services like Twitter, Facebook, Google+ and so on — which the user can choose from.

Part of what makes Web Intents appealing is that it decouples services. Instead of waiting for Flickr to support the latest and greatest online photo editor, Flickr could simply add an intent tag and let you choose any editor you like, including that cool new one that’s still a private beta. Flickr would simply pass the image to the editor of your choice and when you’re done tweaking your photo the editor would then pass the final image back to Flickr.

Other use cases for Web Intents include choosing a preferred search engine, cloud printing, logging into websites and, of course, sharing something on your preferred social networks.

For some more background on Web Intents, check out Paul Kinlan’s blog, particularly his overview post on the brief history of Web Intents and his follow-up on using the Web Intents JavaScript APIs in Chrome. Tantek Çelik, the creator of microformats, also wrote a nice post last year on what he calls Web Actions (same thing, better name). Çelik breaks down the idea behind Web Intents and how they benefit not just developers, but users as well.

As Çelik writes, “web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites…. In that regard, web actions have the potential to become a building block for distributed web applications.”

Web Intents are a long way from a finalized standard and while many things may change before other browsers add support, if you’d like to get a sense of what you can do with Web Intents and how they work in practice grab the latest WebKit nightly build and point it at the examples page on webintents.org.

Image: Aidan Jones/CC/Flickr

Photo: Ariel Zambelich/Wired.com

Yesterday we told you about a disturbance in the web standards force, a supposed rash of websites that work in one and only one web browser. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit, the engine that powers Safari, Chrome, iOS and Android web browsers.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

We aren’t the only ones who think that spells disaster not just for web standards but for the long-term viability of the open web. In fact the response from the web community has all but drowned out everything else in our RSS and Twitter feeds.

Here’s our round-up of what’s being proposed, what it might mean for the web and how we might go about solving the problem:

First and foremost read the minutes from the CSS Work Group meeting, which is where all of this started. The legend for the names is at the top of the page, though you’ll need to scroll about half way down to get to the actual meat of the discussion.

The second must-read post on vendor prefixes comes from CSS Working Group Co-Chair Daniel Glazman who calls on other browser makers to not implement the -webkit prefix and asks developers to make the extra effort to build cross-browser apps. Glazman has since followed up that piece with two more, one clarifying the original post and one defending the CSS Working Group against those who argue that the reason prefixes exist is because the standards process is too slow. If you believe that the CSS spec moves to slowly, this post is well worth a read (spoiler alert: it’s typically browser makers arguing, not the standards process, that creates the hold up on new features).

Remy Sharp of HTML5Doctor fame, weighs in with a series of rough ideas, neatly summarizing the issue and looking at it from both sides. In the end Sharp seems to conclude that just about everyone is to blame, from the browsers to the working group to developers.

Rachel Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it very hard to get that platform to go away if things move on.”

The ever-humorous Bruce Lawson, who works as a web standards evangelist at Opera Software, writes: “Personally — PERSONALLY — I’m pretty depressed about all this. I’ve spent 10 years — pretty much since IE6 came out — evangelizing cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.”

Over at Quirksblog mobile expert Peter-Paul Koch argues that vendor prefixes are just plain wrong: “Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.” He goes on to propose an interesting idea of vendor-neutral prefixes like -alpha and -beta for experimental features.

Aaron Gustafson, a member of the Web Standards Project, has started a petition to ask Mozilla, Microsoft and Opera to not implement -webkit. Gustafson also has a one-line bash script you can use to search your code for any instances of the -webkit prefix so you can double check to make sure you’re supporting other browsers as well.

Mozilla developer Christian Heilman believes that “this mess has partly been created by developers, the least we can do is help fix it.” To that end Heilmann’s Pre-fix the web project is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

JavaScript developer Peter van der Zee has some other possible solutions: “Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time.”

Finally, if you read through the CSS WG notes you’ll notice that Tantek Çelik cites developer Lea Verou as an example of web developers who use just the -webkit prefix. In fact that’s completely untrue and Çelik has since corrected his statement. Verou has long advocated using all prefixes and even created prefixfree to help automate the process.

WebKit may seem like the only game in town, but it's not. Photo: Ariel Zambelich/Wired.com

It sounds like something from a galaxy far, far away, but in truth it was not that long ago that the web was littered with sites that proudly proclaimed “works best in Internet Explorer.” Thankfully those days are over. IE6 no longer dominates the web.

But, while IE6 may be a thing of the past, the root problem — websites that work in one and only one web browser — sadly, remains.

This time the culprit is WebKit, the rendering engine that powers the browsers on the iPhone, iPad and Android phones. But what’s different about this round of monoculture is that, unlike IE 6, the WebKit developers haven’t done anything wrong. It’s web developers that have created the WebKit-only web.

Instead of writing code that will work in any browser, which might mean adding an extra three lines of code to their CSS rules, some of even the largest sites on the web are coding exclusively for WebKit.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

The danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken. Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, says, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

Vendor prefixes like -webkit and -moz were designed to help web developers by allowing browser makers to implement CSS features before the official standard was published. Prefixes were intended to help speed up the process of adding new features to the web and, used properly, they have worked. Unfortunately they’ve also been widely abused.

WebKit is currently the dominant mobile browser in the mind of most web developers (that Opera is actually the single most widely used mobile browser). But even the perceived dominance of WebKit is not the real problem. The problem is — just as it was last time — that web developers are developing exclusively for WebKit.

To be clear, Firefox, IE and Opera also support these features. In most cases, the -webkit properties being used have -moz, -ms and -o prefix equivalents for use in the respective browsers. Popular CSS 3 features like border-radius, transforms, gradients and animations work in all modern browsers. Developers simply need to add those three additional lines of code to make their websites compatible with Firefox, IE and Opera. But they aren’t doing that.

That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”

Neither Glazman, nor anyone else is suggesting that Apple and Google should stop innovating or stop implementing new features as fast as they can. As Tantek Çelik, a Mozilla representative in the CSS WG, says in the minutes of Monday’s meeting, “I think it’s great that Apple wants to innovate as fast as they can…. I don’t want Apple to slow down in innovation and implementing new things. That helps the Web grow and innovate.”

At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.

What makes the current -webkit-only epidemic all the more depressing is how easy it is to solve — just use prefixes they way they were intended. Thanks to modern toolkits you don’t even need to write any extra code. Preprocessors like SASS and LESS make it easy to output five lines of prefixed code with a single mixin. Not a fan or SASS or LESS? No problem, just use cssprefixer, which parses your CSS and adds any prefixes you need before you publish it to the web (there’s also a client-side auto-prefixing solution if you prefer).

That’s fine for your website, but what about all the rest of those top 30,000 sites you don’t control? Well, you could email the developers, let them know that their site isn’t working in the most popular mobile web browser; let them know that you can’t use their service. If you’re a programmer or web developer you can help out with Mozilla developer Christian Hellman’s effort to Pre-fix the web. Pre-fix the web is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

We at Webmonkey hope it’s obvious that building WebKit-only sites is a waste of time. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative says the CSS WG minutes, “there’s no advantage to the Web to have someone write a platform-specific website.” There’s also no real advantage for the developer, especially when an automated prefixer can do all the work for you. If you want your site to embrace the web, take the time to learn the craft and embrace all of the web. Be good at what you do and do it right.