Re: interface definitions in Events spec

On Dec 4, 2012, at 12:20 AM, Jason White <jason@jasonjgw.net> wrote:

> It's very encouraging to see that work on the draft is progressing.
> 
> I think the interfaces defined in the draft should be specified in Web IDL
> (with proper syntax) to bring it into line with current W3C practice. I would
> also refer to Web IDL in the document itself (normatively of course).

Hi Jason, thanks for the feedback. I'm documenting the interfaces in ReSpec IDL, and the WebIDL output is generated by the ReSpec.js parser. Can you give an example of where the syntax is incorrect? I must admit that I am relatively new to WebIDL, so I would not be surprised if there were mistakes in the interface definition, but as far as I know, the syntax should be okay, unless there is a ReSpec bug.

> I am also confused by the decision to define a UIRequestEvent interface, which
> differs significantly from the interfaces defined in DOM Level 3 Events
> (http://www.w3.org/TR/DOM-Level-3-Events/). It seems to me that the UIEvent
> interface includes all of the methods and attributes appropriate to the events
> that use UIRequestEvent interface according to the current draft.
>  
> So, why not simply specify that the event objects implement UIEvent as defined
> in DOM 3? In effect, we are adding event types but using the same interface.
> Then the other interfaces could all inherit from UIEvent and add the necessary
> attributes/methods.


The thinking was twofold:

1. I believe the interfaces needed some additional parameters not available in UIEvent. Are you anticipating adding a "partial interface UIEvent" for these, or handling those outside of the interface? 

2. Because this is a "request" event—that is, a request on behalf of the user for the app to make something happen, rather than a notification that something already has happened—I thought it best to keep the interface separate, in case there are other unforeseen differences that need to be in the spec. That said, I'm open to solving that problem when we get to it, if you have a good solution that incorporates the additional needs and parameters in a better way.

I do have one action[1] to bring the initializers in line with the DOM Level 3 initializers. Until yesterday, I did not realize that the DOM 2 init methods had been deprecated in favor of initialization dictionaries for DOM 3. If this is part of the confusion to which you're referring, it's on the list. 

James

1. ACTION-35 https://www.w3.org/WAI/IndieUI/track/actions/35

Received on Wednesday, 5 December 2012 01:44:44 UTC