- From: Brendan Eich <brendan@mozilla.org>
- Date: Sun, 4 Sep 2011 14:47:04 -0700
- To: Sam Weinig <weinig@apple.com>
- Cc: Anne van Kesteren <annevk@opera.com>, Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Oliver Hunt <oliver@apple.com>, Maciej Stachowiak <mjs@apple.com>, Johnny Stenback <jst@mozilla.com>
On Sep 4, 2011, at 2:40 PM, Sam Weinig wrote: > It is relatively easy for us to run that experiment, and I have no problem doing it, but I am not sure it will give us enough data to remove it, since we have quite a bit of content that is singly coded to WebKit (e.g. Dashboard and iOS specific content). (I filed http://webkit.org/b/67579 and attached a patch to make the change so that we can remove engineering effort from the equation.) Thanks a bunch. I owe you one. > Just to be clear, the only reason to drop caller on collections is that it cannot be implemented in javascript? But that would continue to be the case with document.all? I am honestly not sure I understand the benefit of dropping it, especially since 3 out of 4 engines support it. Apart from JS implementability, it's our experience that sunk costs aren't free. If we can remove caller as much as possible, then our code gets just a bit simpler over time. Not a big deal, very much a small deal -- but worth more than epsilon. > If the main issue is dropping support in WebIDL, so that proliferation of the property doesn't continue, I think reduced proliferation can be achieved by moving it to a section of the spec that clearly marks it as for legacy use only, as I think we have discussed in the past. That'd be fine with me. > I should also note, that in WebKit, we allow plugins to make the HTMLObjectElement (as well as HTMLEmbedElement) callable via NPAPI, though that may be outside the scope of this issue. Is that different from other NPRuntime implementations? Cc'ing jst. /be
Received on Sunday, 4 September 2011 21:47:49 UTC