On Mon, Jun 11, 2012 at 6:29 PM, Maciej Stachowiak <[email protected]> wrote: > On Jun 7, 2012, at 1:10 PM, Adam Barth <[email protected]> wrote: >> On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa <[email protected]> wrote: >>> On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan <[email protected]> >>> wrote: >>>> >>>> I wanted to let you know that I plan to add support for >>>> navigator.buildType (e.g., "nightly", "beta", "final") to WebKit. This >>>> feature isn't on the standards track (but neither are a bunch of other >>>> similar properties on Navigator). This feature will be behind the >>>> ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: >>>> https://bugs.webkit.org/show_bug.cgi?id=88358 >>>> http://html.spec.whatwg.org/#navigator >>> >>> What is the rationale for adding this property on the navigator object >>> instead of the chrome object we also expose if your'e not expecting this >>> property to be ever standarized? >> >> Generally, we avoid implementing web visible features via the "chrome" >> object because that makes them Chrome-proprietary. In this case, it >> seems entirely reasonable for other browsers (e.g., Firefox) to want >> to implement this feature. By putting it on navigator, we invite them >> to implement it as well. > > This thread seems mostly over, but taking the opportunity to make a broader > point: > > If we want to invite other browsers to implement a feature, then we should > propose it to the relevant standards group (and prefix it or just don't add > it if it seems likely to be rejected). Just implementing unprefixed, without > discussing with a relevant standards group first, is not the best approach. > It can needlessly damage our relations with other implementors and the > relevant standards groups themselves. While browser implementors in general, > and the WebKit project in particular, have not always done a great job of > this, this, we've been trying to do this more consistently since we adopted a > process for reviewing feature additions. [1] We may even want to update that > policy page to mention that you'll very likely be asked, "is this on the > standards track?" and if the answer is "no" you need a particularly > compelling reason.
The approach we try to use in the Chromium project is somewhat documented at <http://dev.chromium.org/developers/how-tos/make-a-web-standards-proposal>. That approach seems to work pretty well for moderate and large features. We've had some trouble with tiny features because the overhead seems a bit too large. (I'd classify navigator.buildType as a "tiny" feature.) There's somewhat of a chicken-and-egg problem between implementation and standardization. You don't really want either process to get too far ahead of the other. One intermediate step that I've found useful (and I recommended in the how-to) is to write up a "proto-specification" like <http://wiki.whatwg.org/wiki/AllowSeamless>. That gives folks something concrete to read and think about without getting stalled on the politics around a FPWD for a new working group. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
