Dashboard: Benevolent Pragmatism

Who would have thought the “Little Browser That Could” would create such a flap in the web standards community? After reading Dave Hyatt’s explanation about what HTML extensions Apple is adding to WebKit, I am simply in awe at how far little-known KHTML has come under the tutelage of one very talented person at one very idealistic company. To do what Apple has done with this rudimentary rendering engine in less than two years is nothing short of amazing.

So now that Dave’s fit WebKit with a gown for the ball, Apple is looking for some glass slippers. Enter Dashboard extensions. Enter shortly thereafter, Eric Meyer. Eric rightly questions Apple’s implementation plan, yet recognizes and respects what Dave and his team are trying to accomplish. Instead of offering a blanket condemnation of everything Dashboard stands for, Eric clenches his fists a few times, breathes deeply, and offers constructive suggestions that only he and a handful of other people in the world are even capable of thinking of. As a result of these suggestions, Dave listens, thinks, and responds positively before the dust can even settle.

This is what happens when two smart people listen to each other.

It is commendable enough that Apple has been this open with the development of Safari, but to show this sort of flexibility and transparency is a huge break in tradition for the normally covert company. After all, we’re talking about an operation who has fired people for discussing the tint of aluminum used in their cases. Apple, past and present, is legendary for its ability to keep a lid on things, and yet with Safari it not only breaks this model but turns it completely on its face.

Openness is next to Godliness

Apple gets that the web is about commonly adopted technology and not necessarily standards bodies. Their goal with WebKit was to first make it the most capable renderer of existing web pages and then extend it in a positive direction from there. Through Dave’s genius work and the culture of openness on the Safari team, the first goal was reached in record time, putting further into question why the hell it’s taken Mozilla this long to get where it’s at (I know, I know, AOL). And so now it is time for Apple to take Safari where browsers should have gone years ago: to the desktop.

Knowing that adding certain functionality would be controversial, Dave posted his entire plan for the world to see on his blog… only a day after Steve Jobs introduced Dashboard on stage. Designers and UI people like me slobbered like puppies while more seasoned web gurus like Eric Meyer and Tim Bray put their watchdog hats on and rightly said “Hey wait a minute.”

It’s too early to tell how this whole thing will play out, but the opening act looks less like the nefarious land-grabbing of the Microsoft-Netscape wars and more like benevolent pragmatism to me. Apple wants to improve things and they are letting everyone know in advance what rules they plan to bend and for what benefit. As experts like Eric and Tim weigh in, my bet is that, as often happens on the web, everyone will make everyone else better. It’s not unreasonable to think that Mozilla itself will benefit from some of Safari’s trailblazing either. Mozilla has been talking about embedded desktop applications for years, but their problem was that not enough people knew how to write and deploy them. You can bet that Eric sees the benefit in Safari being able to solve this.

Get further by getting along

No matter how the Dashboard situation turns out, it is a dramatic reminder of the importance of rapport. One of the smartest people I’ve ever worked with once told me that whether or not he makes a deal is almost always determined simply by how well he gets along with the people on the other side of the table. What if Eric publicly flamed Dave for even wanting to extend WebKit? What if Dave dismissed Eric’s suggestions as ridiculous? What would happen is that Apple would go their own way and we’d all be the worse for it. Heck, they might even add *more* proprietary stuff just to spite the critics.

I’m sure it helps that both Dave and Eric worked on the Mozilla project for years and share a lot of the same passions, but what’s really impressive about all of this to me is that given their different allegiances right now (Dave to Apple, Eric still a little to Mozilla deep down inside), they both seem genuinely interested in doing the right thing for the community.

The most important lesson I take from this is that the only way to further develop the web with any sort of speed and efficiency is for the right people to be at the bargaining table. People that know each other, respect each other, and have the integrity to put the community first. I’ll take a table full of these people any day over meetings upon meetings from standards bodies who, though benevolent and honorable, have no real power over who actually adopts what.

Actions speak louder than words

Here is a real-world example of what I mean: A few months ago, I wrote on another blog that I wished absolutely positioned elements could be cleared just as floats could be cleared. In other words, that they not be taken completely out of the document flow. If this was the case, it would open all sorts of flexibility in standards-based design. And so, as he usually does, Shaun Inman, known to me simply as The Wolf, came up with a solution in a matter of days. Shaun wrote a script which beautifully and portably clears absolutes in all browsers, but of course it relies on javascript, and therein lies the rub. So if Shaun can clear absolutes with a pinch of javascript, how hard would it be for browser makers to add this functionality into their products? It could be done in seconds by simply baking in the javascript. It could be done more gracefully by adding another position attribute like “absoluteflow”. So my question is, if you had the choice between the W3C baking this into their next spec, or a few key people from Apple, Microsoft, Mozilla, and Opera agreeing to make this happen within weeks, which would you choose?

Ideally, it would happen at the W3C level first, and then browser makers would adopt it from there, but we all know how long that takes. Wouldn’t we be better off in a world where the people who developed browsers just got coffee every month and talked this stuff out? I’m liking what I’m seeing here with Eric and Dave, and I’m hoping this benevolent pragmatism thing catches on.

Update: Well, that didn’t take long. Little more than a day after Eric’s namespace proposal, Dave says it’s implemented and all ready to go.

“I have not yet committed this solution, because I want to see if this meets with public approval first. Please trackback with suggestions and/or amendments.” — Dave Hyatt

Now that’s cooperation.

13 comments on “Dashboard: Benevolent Pragmatism”. Leave your own?
  1. Gordon says:

    You could flip some of this right back on it’s head too.

    Let’s challenge the W3C to set the path. Why not? Why aren’t they the ones organise the coffee every month? Sit in and be the ‘user advocates’ in the process. You can be sure that Apple, Microsoft, and to a lesser degree Mozilla and Opera, will have their own technical requirements needed for other internal projects/external products. So let’s have that round table, and let’s have the W3C chair and drive the entire process. Just think, it would mean only one set of release notes!

    Hey, a guy can dream, right?

  2. David S says:

    So my question is, if you had the choice between the W3C baking this into their next spec, or a few key people from Apple, Microsoft, Mozilla, and Opera agreeing to make this happen within weeks, which would you choose?

    I would always choose the vendors to do something over a standards body. Standards bodies are notoriously slow. From what I’ve seen, things almost go one of two ways:

    1. Company A makes product X with technology Y. Technology Y is then submitted to some standards body in an attempt to make it an [industry] (surprise, surprise) standard.
    2. The other deal is that companies A, B, and C come out with similar, competing products and things need to be standardized. If said companies don’t feel like getting together and standarizing things themselves, sometimes a standards body will pick up the burden. Either way, the process basically breaks down whatever the companies came up with, picking the best pieces (of course, defining “best” can be rediculously hard), and standardizing from there.

    Obviously, the second method is the one that best defines modern (X)HTML + CSS + DOM and I would much rather see browser vendors innovate and come up with something new as opposed to waiting around for some standards body to catch up. That’s why I have little faith in WHAT-WG and the like, if only because what they come up with won’t be reliably in place until long after I don’t care anymore.

    Also, I don’t see the big scare with the WebKit extensions. They are just extensions to the WebKit, and that’s just great. The purpose is to give people an easy way to create widgets without a big learning curve and that’s just what they’re doing. I say great! Carry on! And, I know this will make some people boil, but just because these extensions aren’t “W3C certified” (who, I might add, don’t even hold much swagger when it comes to standards), doesn’t mean that they aren’t a standard. If you want to create Dashboard widgets, you have only one toolset to deal with and it is completely standardized.

  3. David S says:

    Gordon — yes, you can dream, but relying on a standards body to do anything like that is completely rediculous. In fact, it doesn’t even make much sense (though, at times, I wish it did).

  4. I’m still trying to figure out what Dashboard is all about… I’ve just caught the recent buzz about it. I can say, though, that I am with you on “absoluteflow.” That would be insanely useful, and from almost day one I’ve wondered why the current implementation was seen as the best way. I don’t understand it I guess.

  5. Shaun Inman says:

    How about position: absolute-inline; or even position: absolute; used together with a new property, flow: inline; (the alternate being flow: remove;)? That way older browsers would still have at least something to grab onto and then my scripting can make up for the rest ;)

  6. Rob Cameron says:

    I’m sorry, am I missing something here or did you suggest in your last couple paragraphs, and several people have agreed, that the browser manufacturers add their own tags and properties instead of following standards recommendations by the W3C?

    Uhh … isn’t that what happened in the late 90’s that made our jobs so difficult today?

    Without a doubt it would be 100x faster for the browser manufacturers to do this on their own time and let the W3C add it the spec when they get the chance, but isn’t that a step away from the proprietary tags of the The Browser Warsâ„¢?

  7. Mike D. says:

    Shaun,

    Yep, I think the “flow:inline/remove” suggestion would be ideal. Jeez, how easy would this be to implement! Cake! And since it’s a new property, as Shaun says, it could never break anything.

  8. Mike D. says:

    Rob,

    Here’s the difference: I suggested that the browser manufacturers get together and *agree* on things to add. What happened in the browser-war days is that nobody got together, nobody particularly liked one another, and everybody added their own stuff. Would this happen still today? Perhaps, but I feel like we live in a more cooperative world now. I could easily see Apple, Mozilla, and Opera agreeing on things so that just leaves Microsoft. Without them, of course this wouldn’t be a good idea, but I have friends on the inside at Microsoft and they really do seem a lot more concerned about doing the right thing than they have in the past.

    So I guess in answer to your question, yes, I wouldn’t mind browser manufacturers deciding to implement things without W3C recommendations ahead of time, but only if it’s a collaborative process and everyone agrees on the changes. I just don’t think that’s that far out of a concept.

  9. Jemaleddin says:

    I wish that I could agree with you that this is all working out wonderfully, but it isn’t. Please read Ian Hickson’s repsonse to see what I mean.

  10. Mike D. says:

    Thanks for the heads-up about Hixie’s post, Jemaleddin. I tend to agree with most of it, and I think you’re right that “as things are right now” with Dashboard, there are still problems which remain unsolved.

    However, towards the end of his post, Ian says this:

    “The real solution is to bring these proposals to the table, get some consensus between the relevant vendors and other interested parties, and then use that. For specific features like these, it doesn’t take long to get consensus; they are small features whose basic design can be agreed reasonably quickly. Doing this also usually means getting wider peer review, which improves the quality of the API.”

    This is exactly the sort of thing I’m talking about, and I don’t think Apple has shown unwillingness to negotiate and consult with the WHATWG so far. Yes, they went out and created these tags as a proof-of-concept, but they did say they were submitting them for review by the WHATWG. It looks as if the mere act of disclosing their existence has, in effect, automatically submitted them to the WHATWG (and the rest of the world) for approval.

    The key to how this whole thing plays out now is how quickly the WHATWG and the rest of the world respond (constructively godamnit!) directly to Dave, and then how quickly and constructively Dave responds and adjusts. As I said before, this is all about a small group of the right people simply getting together and talking this stuff out. Between Dave, Ian, and some other members of the WHATWG, we might just have the right group to act quickly on this.

    And then again, maybe not. Time will tell. These next few months are critical.

  11. Caleb Jaffa says:

    Truthfully even though I am a web developer some of this stuff is a little over my head. However, I think that the whole Safari/Dashboard has the best shot of anything to set a good precedence for these situations in the future. You can’t always rely on the standards body to lead the game. We run the risk of stagnation. However 6-12 months before (well Safari 1.3 might be released sooner) Tiger Mac OS X 10.4 which will be the first real release of Dashboard to the public, Dave Hyatt is laying his cards on the table. This allows not only for other developers to incorporate what they want, but it also allows for Dave and company to get public input from experts so that the final shipped version will not be a lame duck version that would need to be overhauled to be ideal.

  12. Robb Beal says:

    Mike,

    You miss something really important: Safari and Dashboard are *tied* to OS X.

    I don’t know of a competitive analog to tying in the design world, so suffice it to say that OS tying is a competitive weapon of mass destruction in the PC software industry. Here’s some additional depth on tying,

    http://www.usercreations.com/weblog/2004/07/06.html#a609

    Historically, Apple’s relatively slow pace and scale of tying has been considered acceptable. In recent years, the pace and scale of the tying has reached the point where it’s near insane to invest in creating significant, new Mac software and some of those who did (eg, Karelia, where I was prod. manager, Konfabulator, Opera, etc, etc) aren’t seeing their investments through to the maturity they expected when they made them.

    When Safari/WebKit/WebCore was first announced, I was cautiously optimistic that Apple was simply trying to provide a fast, standards-compliant browser and would fill in some holes (eg, client-side SSL) in the IE Mac offering. (In 2000-01, I was an Apple employee working on web-related technologies and saw first-hand the inability of MS and Apple to collaborate on IE Mac.) But, the recent Dashboard tying and the HTML extensions confirmed my worst fear: that Safari/WebKit/WebCore would being used as a conduit for tying ever more functionality to the OS!

    That’s how it looks from here!

    Robb

  13. Johnathan says:

    How is this “tying”? Apple isn’t encrypting Dashboard applets with a special “Apple Digital Security Certificate” that developers must license (for fee or free) and agree to not attempt to decrypt it on any other OS or platform. Apple, to the contrary, is documenting what it’s doing as it goes along, so that (anyone who pays attention) will know how to both develop Dashboard applets and implement a runtime engine for them. Admittedly, Apple is only providing a nice-looking runtime on OS X, but they aren’t doing anything at all, to my knowledge, that would prevent someone from (for example) grabbing the Gecko engine and baking it into their own runtime for another platform. Perhaps a bit rougher around the edges, at least at first, but certainly able to provide all the functionality, just without as much “eye candy” as Apple’s version will certainly have. For that matter if Opera saw “desktop widgets” as a worthwhile thing to bake into their Windows version, I don’t see anything stopping them.

    And, I don’t see Safari or Dashboard as anything the user will be required to use. Yes, something the user can’t remove, but the user will still have the option (at least as of this writing) to use IE (shudder!), any Mozilla variant, Opera, etc as well as Konfabulator in lieu of Dashboard. It also seems to me that really, the only platform-specific thing Apple’s done to KHTML is to improve the “glue” code between KHTML and OS X to improve performance on Apple’s own platform. However, I don’t see anything preventing the changes to the KHTML engine itself from helping any other KHTML-based browser. Has Apple really done anything to the “core” technology here that represents the “extinguish” of “embrace, extend, extinguish”? I’m not seeing it. Apple is providing an additional way to use HTML through Dashboard, but it’s not taking away any existing uses, and certainly isn’t breaking compatibility with anything.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe by Email

... or use RSS