- From: Brendan Eich <brendan@mozilla.com>
- Date: Fri, 9 Sep 2011 12:17:12 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Anne van Kesteren <annevk@opera.com>, Cameron McCormack <cam@mcc.id.au>, Alex Russell <slightlyoff@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Isn't the problem not so much the lack of vendor prefixes, but the wrong API design? IOW would a bunch of webkitCreate functions really make the current situation better? In Ecma TC39 we do not vendor-prefix but we do try to get agreement on design principles and particular straw proposal details, including names, and then optimize for success. My point is not so much to criticize vendor prefixing of JS APIs (I'll save that for another message) as to observe that if we don't agree on constructor pattern beating document.createX then vendor prefixing won't help. /be On Sep 9, 2011, at 10:16 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Fri, Sep 9, 2011 at 2:00 AM, Anne van Kesteren <annevk@opera.com> wrote: >>> Not sure why that's a bad thing. Yes, HTML DOM can (and should!) do >>> something smarter, but this is clearly a step in the right direction. >> >> Why don't you make proposals for how existing specifications ought to >> change? >> >> As I said before, just saying everything can be constructed will just lead >> to a messy situation. > > Somehow we also need to avoid the mistake of browsers releasing > unprefixed APIs which don't use constructors as they should. The touch > events spec is filled with silly document.createX functions that > should use constructors because Apple implemented it that way and > without a prefix. :( > > / Jonas
Received on Friday, 9 September 2011 19:17:53 UTC