W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

From: Marcos Caceres <w3c@marcosc.com>
Date: Sat, 22 Oct 2011 07:55:37 +0100
To: public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>
Cc: www-dom <www-dom@w3.org>
Message-ID: <BE34D1CAA91C4765BF31CC2A867615C6@marcosc.com>

On Friday, 21 October 2011 at 21:42, Ms2ger wrote:

> Hi Art, all,
> On 10/14/2011 09:27 PM, Arthur Barstow wrote:
> > The people working on the D3E spec (namely Jacob, Doug and Olli) propose
> > below that the spec be published as a Candidate Recommendation and this
> > is a CfC to do so:
> > 
> > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
> > 
> > The comment tracking document for the last LCWD is:
> > 
> > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html
> > 
> > This CfC satisfies: a) the group's requirement to "record the group's
> > decision to request advancement" to CR; and b) "General Requirements for
> > Advancement on the Recommendation Track" as defined in the Process
> > Document:
> > 
> > http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs
> > 
> > The exit criteria has not yet been added to the ED and I request the
> > Editors to please propose the specific criteria in response to this
> > e-mail before the comment deadline. It is my expectation that Microsoft
> > and Mozilla will complete the test suite [TS] they started and they will
> > implement this CR. As such, I assume the exit criteria will include a
> > requirement that at least two independent implementations pass all of
> > the test cases.
> > 
> > As with all of our CfCs, positive response is preferred and encouraged
> > and silence will be considered as agreeing with the proposal. The
> > deadline for comments is October 21 and all comments should be sent to
> > www-dom at w3.org (http://w3.org).
> I used to think that the right approach to DOM 3 Events was to get it 
> published as a Recommendation as soon as possible, and start to work on 
> a higher-quality specification when that happened. However, for various 
> reasons, I've changed my mind, and now think that we should make DOM 3 
> Events a specification of the quality that is now expected from 
> specifications.
> Furthermore, I believe a lot of good work has been put into 
> specification, and hope we can move forward with it soon.
> However, *I do object to the publication* of this specification because 
> the inappropriate resolution of the following issues (in no particular 
> order):
> First (issue 123), it contradicts an uncontested requirement [1] in DOM4 
> forbidding the minting of new DOM feature strings, as reported by Anne. [2]
> Second (issue 179), it ignores the consensus about using DOMException 
> instead of custom exception types like EventException, as noted in 
> WebIDL, [3] which I reported. [4]
> Third (issue 130), the resolution made to add an informative WebIDL 
> appendix is insufficient. Not only did the editors not list any 
> technical reason for this decision in their reply, [5] despite this 
> being required by the Process document. [6]
> The only claim that I could find in favour of this decision is that 
> WebIDL is not stable. [7] However, WebIDL's second LC has ended 
> (without, as far as I can tell, too many comments), and as such it is as 
> stable as DOM 3 Events itself, and is indeed moving ahead at a rather 
> much faster pace.
> Furthermore, the DOM 3 Events specification already (stealthily [8]) 
> depends on the HTML specification, which is even less stable than WebIDL.
> In fact, it is not clear to me what there is to gain by not referencing 
> WebIDL normatively. In reality, browsers will have to ignore the 
> normative IDL code and use the WebIDL instead. In effect, not 
> referencing WebIDL will only make DOM 3 Events *seem* more stable then 
> it actually is. (I note that the specification doesn't actually define 
> which IDL dialect it uses, though the references section lists OMG IDL.)
> I am ready to reconsider my objection once the issues I mentioned above 
> are fixed.
I also would like to second these objections for the reasons cited above. I'd also like to see less overlap between DOM4 and DOM3 Events (and redundancies eliminated by, for instance, allowing DOM4 to define the Event interface and generic event propagation and behaviour, and DOM3 define other events: e.g., mouse, keys, etc.). It's very confusing which document to use right now. So, having said that, I would like to see some clarification in DOM3 Events about its relationship to DOM4.  
Received on Saturday, 22 October 2011 06:56:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:59 UTC