- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 04 Sep 2011 09:49:02 -0700
- To: Doug Schepers <schepers@w3.org>
- CC: Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Jacob Rossi <jrossi@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, Chaals McCathieNevile <chaals@opera.com>, www-dom@w3.org
On 9/4/11 8:47 AM, Doug Schepers wrote: > Hi, Anne- > > On 9/4/11 9:41 AM, Anne van Kesteren wrote: >> On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow >> <art.barstow@nokia.com> wrote: >>> Some members of the group consider the D3E spec as the highest >>> priority of our DOM-related specs and they have put considerable >>> resources into that spec. Doug and Jacob will continue to lead that >>> spec effort, and as I understand it, a CR for D3E is imminent. I >>> expect the group to help progress that spec. >> >> I do not think that is appropriate given that unlike all our other >> specifications it does not use Web IDL > > DOM3 Events does provide Web IDL definitions for the interfaces [1]; > it simply doesn't make them normative, because Web IDL is not yet stable. > > Should the Web IDL spec reach a stable state in time, we can make the > Web IDL definitions normative. > > >> and we still have not settled how >> to deal with exceptions on the web platform. > > DOM3 Events doesn't change anything about this. Should a later spec > (such as DOM 4 / DOM Core) change how exceptions are handled, and if > implementers agree with that change, we can simply issue an erratum > for that in DOM3 Events, and publish an updated draft. This is a > minor and common issue... that later specifications supersede previous > ones. Doug, Is there a wiki page or other resource for looking into implementation status on DOM3Events? It's a large spec, and I'd like to plan for it in our internal roadmap. I'm no fan of event.pageX, but it's very heavily used in our code base. Our screenX hooks, when written, were targeting Adobe's Flash event namespaces. It's mentioned once, in DOM3Events, in the legacy context of initMouseEvent. Anne, It seems to me that the following section documents DOM Core's proposed improvements to DOM3Events: http://www.w3.org/TR/domcore/#dom-events What are the current restrictions in Event.type that are concerning you? As I understand it, there is no normative list for event types, though vendors -may- restrict them. There are strict restrictions for null/empty string types. http://www.w3.org/TR/DOM-Level-3-Events/#event-types I do see that in 9.2, DOM Core attempts to clean-up some older namespaces. "Implementations conforming to this specification will not support them". That seems to me, the primary reason for labelling DOM3Events as "obsolete". Is it common for a specification to explicitly state that conforming implementations will -not- support legacy specs? There's this bit of related text as well: "Vendor-specific proprietary extensions to this specification are strongly discouraged. Authors must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question." That seems in conflict with the following, in the mutations section: "We encourage experimentation with that proposal, as well as alternative proposals" I understand DOM Core to be encouraging a tidy and easy-to-use API. It does not seem to leave room, with some of these statements, for legacy compatibility, nor much experimentation. -Charles
Received on Sunday, 4 September 2011 16:49:28 UTC