- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 16 Sep 2010 09:19:22 +0200
- To: "Hallvord R. M. Steen" <hallvord@opera.com>, "Doug Schepers" <schepers@w3.org>, "Anne van Kesteren" <annevk@opera.com>
- Cc: "Jonas Sicking" <jonas@sicking.cc>, "Olli Pettay" <Olli.Pettay@helsinki.fi>, www-dom@w3.org
On Thu, 16 Sep 2010 09:01:49 +0200, Anne van Kesteren <annevk@opera.com> wrote: > On Thu, 16 Sep 2010 05:06:56 +0200, Doug Schepers <schepers@w3.org> > wrote: >> The reality is that there are some poorly-designed features that many >> browsers will have to support for legacy content, but where there are >> better-specified and more widely supported alternatives, I think it's >> counterproductive to also specify the non-standard feature. For >> example, keyCode and charCode. > > I don't agree with this sentiment. If a feature (however pointless) is > needed to get traction as a new web browser it should be defined so that > the new browser does not have to reverse engineer other browsers. The > more legacy features (that need to be implemented) we leave undocumented > the bigger the barrier to entry. Which ultimately is just bad for the > ecosystem. I agree. It's not only better for newcomers but it's also better for existing implementations to have it specced so that we can converge to an interoperable behavior. Please specify keyCode and charCode, even if marked as 'obsolete'. I'm pretty sure no browser is going to ship without at least one of them. (I notice that charCode is undefined in Opera, keyCode always returns 0 in Firefox, and in WebKit they both work.) -- Simon Pieters Opera Software
Received on Thursday, 16 September 2010 07:20:03 UTC