[webkit-dev] Adding nonstandard features (was Re: Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore)

[Adam Barth]

On Mon, Jun 11, 2012 at 6:29 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Jun 7, 2012, at 1:10 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>> On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan <sullivan at chromium.org>
>>> 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