On Mon, Nov 30, 2009 at 1:45 PM, Maciej Stachowiak <[email protected]> wrote:
> > On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote: > > Reading this, I am reminded of a great commentary by Alex Russell, >> written nearly 3 years ago: >> >> http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ >> >> Despite of what I may think about SharedScript, I am certain that >> waiting -- whether for standards community or Web developers to >> embrace or reject our ideas -- is not the right answer. If we really >> want to move the Web platform forward, we can't afford a feedback >> cycle this long. Especially, when we have an opportunity for close >> collaboration with Web developers of some of the most JS-intensive Web >> properties. >> >> Experimenting is great. We should experiment. >> > > WebKit (or at least the mainline) is not necessarily a great place for > experiments. As our Project Goals say: "WebKit is an engineering project, > not a science project." <http://webkit.org/projects/goals.html>. Of > course, that's a pretty fuzzy line, because sometimes a use case is really > well proven and we're not willing to wait for standards groups to get their > butt in gear. But there are some potential bad scenarios with building > features that don't have a clear path to standardization: > > 1) It will be rejected by other browser vendors and end up a WebKit-only > (or nearly WebKit-only) feature, but enough WebKit-specific content depends > on it that we can't drop it, even if we would like to. Then we are stuck > maintaining a dead-end technology indefinitely. It seems like the SQL > database may be on this path. > > 2) It will get adopted into standards, but with significant changes when > other implementors and standards experts jump on the bandwagon. These > changes can cause a very painful transition, since we need to remain > compatible with legacy WebKit-specific content, yet at the same time we > don't want to be in violation of the consensus spec. This actually happened > with <canvas> - it changed incompatibly in ways that broke a bunch of > WebKit-specific content (in particular Dashboard widgets), but we had to > implement the standard to support content coded to Firefox. This really > sucked and we have Dashboard-specific hacks still lying around in our code > base as a result. > > So please realize, experimenting is not free. The cost can be much greater > than the implementation cost, and may indeed last far beyond the > experimental era. These kinds of bad scenarios are the reason that nowadays > we try to get standards buy-in on new Web platform features *before* they > get shipped in a mass-market product. And experience with these kinds of > scenarios is what makes some of us very wary of going hog-wild with > experiments in the WebKit code base. We take backwards compatibility for Web > content very seriously, and so we hesitate to put anything in that we don't > feel we can commit to. > Isn't it being developed behind a flag? If not, couldn't it be? That would keep it from being inadvertently shipped with any platforms. If there is a compatibility breaking burden, it would be those who explicitly choose to ship it, and those alone. As far as I can tell, the only thing at issue here is the code maintenance burden. Other embedders of WebKit should be shielded from the other issues you cite.
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
