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?

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.

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â„¢?

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.

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.

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.

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

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.