W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [DOM3Events] CR

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 04 Sep 2011 09:49:02 -0700
Message-ID: <4E63ABFE.6030702@jumis.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT