So, after getting an email from Sitepoint this past week, I decided to drink some of the Webkit CSS kool-aide. If you’re in a Webkit browser, go ahead, rollover the links and navigation.
To give a very quick background, Webkit is the foundation for the Safari Web browser. Additionally, many OS X apps use Webkit to display Web content. NetNewsWire, Mail.app, the Dashboard, are just a few. Site-Specific Browsers (SSBs) like those built on Fluid are also using Webkit.
Basically, if an OS X app’s Web integration has a tight feel to it, you can bet that it’s using Webkit.
Webkit is a strong platform. The only thing I see potentially harmful is that they stray away from W3C standards with their modern functionality. However, even as a relatively strict standardista, I don’t fault them. It takes forever for the W3C to get anything done and then the adoption rate takes even longer. This is why we have programming strategies like progressive enhancement(8).
The new Webkit CSS properties are relatively simple to implement and ignored by the other browsers. (Well, I tested only in FF3 beta and I don’t think I have the patience for IE… no wait, I’m SURE I don’t..)
For me, the only tricky thing was understanding where the actual properties would live in the style sheet. The transition property I’ve used on the navigation areas and links is actually set in the selector that will change.
For example:
#tertCol a {
display:block;
color:#D1570D;
font-size:.8em;
line-height:1.2em;
border-top:1px solid #BBB;
padding:4px 0 4px 4px;
-webkit-transition: color .25s linear;
-webkit-transition: background-color .25s linear;
}
#tertCol a:hover {
background-color: #D1570D;
color:#FDE792 !important;
}
This seems a bit counter-intuitive to me. Time-based event effects such as animations and transitions seem like they should go on the event handler such as hover. It makes sense that static effects would be handled in this way, but not dynamic ones. Anyway, minor annoyance, not a deal-breaker.
Photo by bartmaguire.
Why Is Now A Good Time?
Before jumping in and adopting proprietary technology, it’s always good to second-guess. Thing is, Webkit is not propietary. It just seems that way because there is only one prominent player. It’s actually open-source.
See the Billowing Steam?
As mentioned above, Webkit has gained some good ubiquity on the Mac OS X platform which itself is gaining steam in both the consumer and business markets. Additionally, perhaps more importantly, Apple has beat out Dell in the education market. That means even more people in the coming generations will have a preference to OS X.
Webkit is the engine that drives Safari and it’s mobile sibling on the iPhone, which has gained an enormous share of the PDA market. The iPhone is no doubt here to stay and after Apple’s enterprise initiatives take this summer, forget about it. Every executive wants one, but is bummed they can’t connect it to the corporate email. That’s going to change soon. (Not to mention after 3G hits)
Apple is not the only major company adopting Webkit, though. Nokia and Adobe have adopted Webkit as their rendering engine of choice as well with the Nokia S60 and AdobeAIR, respectively. And, not saying it’s going overthrow the great, bloated behemoth that is IE, but Safari is now available for Windows as well.
High Zippiness Factor
Webkit renders HTML/CSS at blazing speeds and it handles Javascript like a champ(4).
I used to use Firefox for years because of its vast array of plug-ins and added functionality. While I miss the Web Developer toolbar, I stay in Safari for all my browsing because it so stinkin’ fast.
Easy to Implement
Webkit is easy to include in your apps because it is well documented for the Xcode and MS Visual Studio IDEs (as well as Express). I even found that some developers find using Webkit a perfectly legitimate tactic to create desktop apps using Web technologies. This is where guys like Todd Ditchendorf and Jon Crosby are making plays. Don’t think they’ll be the only ones because even I – a hack of a programmer – grokked that one from the moment I started playing with Xcode.
Hardcore Compliance
Yeah, Yeah, say what you will about The Great Browser War of the ’90s happening all over again. The fact is, when it comes to current standards compliance, Webkit is hands down, above the rest(7). So, zip it Chicken Littles. (besides, the browser war has never ended.)
Photo by Killer App
Furthermore, there is a difference here. This is more a matter of stylistic enhancements, not structural and behavioral integrity as it was between Netscape and IE. When considering a 4-layer approach to design; that is, separating content, structure, style, and behavior from each other we’re looking to keep visual enhancements away from disturbing the accessibility to content. Which is what these properties are for.
Again folks, it’s called Progressive Enhancement(8). I was shocked to find that some people are still unfamiliar with this notion. Essentially, progressive enhancement, means that, if you’re going to add some modernity and flare to your code, make sure it degrades gracefully to non-supporting browsers by adding enhancements to already sound, accessible code. (I won’t flag you if you ignore IE, though.;-) jk
If you’re worried about non-webkit support on a Blackberry or some other mobile device: again, you haven’t taken the time to ensure best coding practices for degrading gracefully and if you’re not coding with best practices, then you have a lot more to worry about than non-compliance to Web standards.
Add it to Your Toolbelt
The features I toyed with are rudimentary. Webkit can do masks, gradients, transforms, rounded corners, all sorts of goodness. There are many possibilities to help shorten your dev cycle as you design for the future Web.
The Web is in a constant state of flux; expanding and contracting. As architects and builders, we’re going to be charged with taking applications to mobile devices and creating stand-alone apps that access the Interwebs via Javascript APIs, etc. Coupled with coding for graceful degradation, Webkit is going to be the easiest path we have.
Being in this biz for over 12 years and seeing technologies come and go or stay, I’m predicting that if you want to retain, or gain, some credibility as a Web designer/developer, do not waste any more time, put Webkit at the front-end of your development process.
Now, if we could just see more cool plug-ins!
To say that Webkit is “above the rest” is really not true. Acid3 is not the end of standards compliance. Opera support 90 % of all SVG tests. Webkit only half of them. Webkit mistreats the (being standardized) innerHTML method. Firefox support is rock solid – and innerHTML is way more important than many of the obscure parts of Acid3. Opera is way ahead on Web Forms 2.0. Firefox is way ahead on JavaScript. And, oh, yeah, Opera actually beat Webkit to the 100 score by 40 minutes…
I am not saying Webkit is bad. It gets some things right that no one else does. It is a bit behind on other features. As for this new stuff: Transitions may one day become a usable standard. Today the potential for abuse is way too high. Gradients is a much better proposal.
Lars, thanks for your input. Opera is a great browser, no doubt. To be honest, I made the mistake and did not consider it when I wrote this. I don’t think Opera is gaining the same traction in adoption as Webkit. And I think the support for innerHTML has been largely worked out and if not, it is on its way. FF is certainly a stronger browser in this regard and leading in usage, but it’s so darn pokey. I think for general browsing, we’re going to see a leap in Webkit usage because of Safari, AIR, and Nokia.
The point I’m making is not to get hung up on the introduction of non-standard techniques and avoid them in this case. Some think that the addition of these properties is going to debilitate their code. If you practice sound coding tactics like progressive enhancement, you’ll avoid much of the troubles of future (non)compliance.
And I totally agree with you that the potential for abuse is high, but as with any technology, those who improperly use it will be sifted out and *hopefully* learn from the mistakes.