The last two years have been explosive for WebKit development - the project has really accelerated, moving at a much faster perceivable rate than the other notable open-source web platform, Mozilla. I've been noticing more and more innovations that affect web developers from the Safari blog.
- 2008-04-29 - CSS Reflections
- 2008-04-24 - CSS Masks
- 2008-04-17 - CSS Canvas Drawing
- 2008-04-14 - CSS Gradients
- 2008-04-08? - CSS Transitions
- 2007-10-31 - CSS Animation (spec proposal)
- 2007-10-26 - CSS Transforms (spec proposal)
- 2006-12-21 - Text Fill and Stroke
- 2004? - HTML Canvas - thankfully this was quickly reviewed and thrown into HTML5 so that Opera and Mozilla could get into the act
- Others -webkit-border-horizontal-spacing, -webkit-border-vertical-spacing, -webkit-margin-bottom-collapse, -webkit-margin-collapse, -webkit-margin-start, -webkit-margin-top-collapse, -webkit-padding-start, background-position-x, background-position-y, -webkit-tap-highlight-color (iPhone only), -webkit-text-security, -webkit-text-size-adjust (iPhone only), -webkit-line-break, -webkit-nbsp-mode, -webkit-rtl-ordering, -webkit-user-drag, -webkit-user-modify, -webkit-user-select, -webkit-dashboard-region (Dashboard only)
Is this a problem?
What's troubling me is not that many of these inventions could have been done using SVG (which WebKit now supports quite nicely). I understand that XML is not for everyone and that a few CSS properties are easier to pick up to do what you want.
No, what troubles me is that a few of these innovations are not yet proposed as formal specifications so that they can be interoperably implemented in other browsers (Firefox, Opera). [Update: Correction - as Mark points out below, several of these have indeed been proposed as formal specifications - Bravo!] The point of the WHATWG effort was both to evolve HTML and to specify it in sufficient detail so that future browser vendors would not have to reverse engineer de facto browser behavior. Will the WHATWG eventually have to churn out CSS5?!? 😉
On the other hand...
... Apple has a perfect right to introduce WebKit-specific CSS properties. WebKit is more than just a single web browser. WebKit is a platform and Apple obviously wants to put as many cool web development tools into the hands of its developers as possible. They're already doing a good job at meeting existing open web standards - why not innovate on the side? Also, using CSS ensures that things can degrade gracefully, so you can't quite fault Apple for 'anti-competitve behavior' like you could Microsoft and Netscape's efforts during the First Browser War.
Unfortunately...
Unfortunately these inventions might have the same secondary effect: Forcing the other browser vendors to spend resources on reverse-engineering efforts in order to remain competitive. This could realistically happen before Apple gets a chance to propose these things formally to the W3C. [Update: See Mark's comment below]. It is much more likely to happen if WebKit were to become the dominant force on the open web.
WebKit is not yet the dominant web browser technology, but it's fast on the rise. From all accounts, it is much easier to pick up and hack on than the Mozilla codebase. Let's take a look at where it is being used:
- MacOS Dashboard
- Safari on MacOS
- Safari on iPhone
- Google's Android
- Adobe's Integrated Runtime (AIR)
- Qt 4.4+
- Nokia S60 Browser
I'm sure readers can help me add to the above list too. I believe there is a plan for WebKit to ultimately take over Konqueror's KHTML guts one day too, isn't there? Ironic since WebKit evolved from KHTML in the first place.
So when will it be a problem?
Are we seeing any signs of a trend towards a WebKit-dominated web yet? There are already iPhone-specific websites. How long before Opera Mobile and Mozilla Minimo want to get in on that action and are forced to reverse-engineer? And I'm sorry, but looking at the source is not an acceptable alternative to a well-defined specification.
A tentative conclusion
After typing up this entry and proof-reading it, I tried to discern if I had any coherent conclusion and if I could figure out just what the heck I was saying:
- Apple is not in the wrong for introducing WebKit-specific CSS properties, I think they learned their lesson from the HTML Canvas experience.
- You also cannot fault Apple for its adherence to web standards. They are definitely doing their job here
- It seems like they plan to propose these things as standards eventually, which is also a good thing.
- I guess the only thing I can say is that I hope these proposals happen sooner rather than later, for the other browsers' sake. [Update: As mentioned below, Apple has already proposed many of these things to the W3C as specifications, thereby alleviating most of my concern]. Apple should take a page from what happened to DOM Events: The fact that Netscape and Microsoft had two different event models resulted in the W3C proposing yet a third incompatible Event Model, which Microsoft still has not implemented eight years later. Those type of things just hurt web developers in the end.
Several of the CSS features you mention have already been proposed for standardisation: see http://lists.w3.org/Archives/Public/www-style/2008Apr/0208.html for instance. The background-position-x/background-position-y properties have also been discussed: see http://www.w3.org/Style/CSS/Tracker/issues/9 . Other properties, such as rtl-ordering and text-security, exist primarily for use within the engine to emulate behaviour of the system widgets that WebKit itself implements in terms of HTML (password fields, buttons, etc). Mozilla has a long list of extensions for a similar reason ( http://developer.mozilla.org/en/docs/CSS_Reference:Mozilla_Extensions ).
Last I checked, MacOS was retired years ago in favor of Mac OS X.
@Mark. Thanks very much for those links, I have done some updates to my blog post. One recommendation: Perhaps the Safari blog entries could be updated with the spec proposals so that goofs like me don’t go shooting off my mouth? 😉
We have already proposed many of the big ticket CSS items you mention as new CSS Modules. I would expect most of the others to be proposed more formally in due course as well. In the area of CSS, we like to come with a preliminary implementation because it is often difficult to argue the benefit of new features in the abstract. An implementation that can be experimented with is often much more compelling and informative about details of the design.
Another long-ago WebKit innovation is and the placeholder attribute for elements. We have proposed both of these for HTML5, although forms work on HTML5 is currently on hold. Many of our recent new features in the areas of HTML and general Web APIs don’t make your list because we started with standards for those in mnay cases. For example, we were significant contributors to the design of the and elements, the SQL Storage API, and Offline App support, but these ended up in the HTML5 spec before we implemented. We’ve also added features such as postMessage, getElementsByClassName and querySelector that came straight out of HTML5 or Web API WG specs.
In general, our desire is to see the web improve as a platform and to bring these features to standards and encourage other browsers to adopt them.
iCab 4 and Epiphany will use also webkit in future
Update: Added bit about CSS Reflections