[webkit-dev] <a ping> landed

Maciej Stachowiak mjs at apple.com
Wed Oct 6 18:59:32 PDT 2010


We've never really formalized an approach to new Web platform features, but the usual practice has been something like:

- Use an ENABLE macro if the feature is one that ports may be unable to support immediately or may wish to turn off for other reasons.
- Have it on by default if:
   (a) The feature is part of a standard or clearly standards-track; or the WebKit community has rough consensus that it is a worthwhile feature for the project to support
   (b) And it is stable enough that having it on wouldn't make trunk unusable for testing.
- For features where there is not consensus on the appropriateness and usefulness, we make some effort to come to consensus, though full agreement isn't always possible.
- Sometimes things get fuzzier than that and there may be special circumstances.
- It's reasonably common for features to start out off by default, for a variety of reasons, and then get turned on by default later.

Applying specifically to this case, <a ping> seems to be a worthwhile feature, and there seems to be good reason to believe the code is stable. However, there is a special circumstance, i.e. the negative public reaction it has elicited at times in the past. In the past, and most likely in the future, most WebKit additions to the Web platform have been greeted in a largely positive way, so this is an unusual situation, and I do not expect it to come up very often.

To be more specific: some have perceived this feature as being anti-privacy, and privacy on the Web has been a topic of significant public attention. This stance may not be entirely fair, since the alternative to <a ping> is not a world where no one tracks outgoing links; rather, it is a world where sites do so in a way that hurts performance and is significantly more difficult for users to avoid. But that is a tricky case to make, and perhaps some will not be convinced until they see the future in action.

To be clear, the aim here is not to slow down adoption of <a ping> but rather to give vendors and port maintainers the choice of whether to take on some PR risk by being one of the early adopters of this feature, as a courtesy. I think it is likely that in time, this risk will blow over.

Regards,
Maciej

On Oct 5, 2010, at 2:45 AM, Dirk Pranke wrote:

> Fair enough; in retrospect I realize my message may have come across
> with the wrong tone. Mostly I was just wondering how often we do this,
> since it doesn't seem like you'd want this to be the blanket approach
> to new things.
> I defer to Maciej's (and others') wisdom as to what the right thing to
> do is on this particular feature.
> 
> -- Dirk
> 
> On Mon, Oct 4, 2010 at 11:25 PM, Darin Fisher <darin at chromium.org> wrote:
>> I don't think it is the norm.  This one is special for the reasons already
>> stated.
>> -Darin
>> 
>> On Mon, Oct 4, 2010 at 11:17 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>>> 
>>> Keeping it off by default until it has some mainstream acceptance
>>> seems like a bit of a self-defeating policy for new features; is this
>>> often done in WebKit?
>>> 
>>> -- Dirk
>>> 
>>> On Mon, Oct 4, 2010 at 10:12 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>> 
>>>> Since <a ping> has been controversial in the past (for arguably bogus
>>>> reasons, but controversial nontheless), I suggest we keep it off by
>>>> default
>>>> until we find it has some mainstream acceptance and/or we discover that
>>>> more
>>>> ports want it.
>>>> Regards,
>>>> Maciej
>>>> P.S. We haven't decided yet if we want it on for the ports Apple ships,
>>>> but
>>>> it's probable we will turn it on sooner or later.
>>>> 
>>>> 
>>>> On Oct 4, 2010, at 6:51 PM, Jeremy Orlow wrote:
>>>> 
>>>> Given that a ping really doesn't open up any new privacy holes (just
>>>> makes
>>>> it easier for sites to get the data they're going to gather anyway
>>>> without
>>>> slowing down the experience for the user), it seems like we might as
>>>> well
>>>> enable it by default.  If a port doesn't want it, they can always
>>>> disable
>>>> it, right?
>>>> Thanks,
>>>> J
>>>> 
>>>> On Fri, Oct 1, 2010 at 12:39 PM, Nate Chapin <japhet at chromium.org>
>>>> wrote:
>>>>> 
>>>>> This is a few days late, but I just wanted to let the team know that,
>>>>> as
>>>>> of http://trac.webkit.org/changeset/68166, WebKit can support <a ping>
>>>>> (but
>>>>> support is disabled by default).
>>>>> 
>>>>> The reason I left it disabled by default is that some ports may want to
>>>>> have a mechanism for disabling pings, and I didn't want anyone
>>>>> to accidentally pick it up before they were ready.  I'm happy to flip
>>>>> it to
>>>>> enabled by default if that's what people prefer.
>>>>> 
>>>>> ~Nate
>>>>> _______________________________________________
>>>>> webkit-dev mailing list
>>>>> webkit-dev at lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>> 
>>>> 
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 



More information about the webkit-dev mailing list