Re: [DOM3Events] CR
On Tue, 06 Sep 2011 21:04:33 +0200, Jacob Rossi wrote: All of the Last Call issues formally raised in our Tracker have been addressed as indicated in our Disposition of Comments [1]. If there are outstanding issues, then they're likely threads on www-dom that got lost in the shuffle. Kindly, can you be more explicit and enumerate the outstanding issues you're awaiting responses for? It's hard to tell since instead of pointing to the email where I raised the issue you point to a tracker issue. I have no idea what the relation is between the two. But e.g. I do not have a reply to these emails in my inbox as far as I can tell: http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0054.html http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0065.html http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0066.html http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0067.html http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0122.html http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0131.html Furthermore given the normative changes that have occurred (e.g. to event.type) another Last Call is needed where I wanted to note the issues I noted elsewhere in this thread, regarding not using Web IDL normatively like all our other drafts if they are not addressed by then. [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html -- Anne van Kesteren http://annevankesteren.nl/
RE: [DOM3Events] CR
> On Sun, 04 Sep 2011 17:47:45 +0200, Doug Schepers > wrote: > > On 9/4/11 9:41 AM, Anne van Kesteren wrote: > >> 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. > > All our specifications use Web IDL normatively. I do not see why DOM Level > 3 Events has to be special here. > > > >> 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. > > The File API specification has a warning in the specification about this > changing. > I think at a minimum that should be stated. > > > These were just two issues that came to mind though, I still have outstanding > Last Call comments, as do other people. All of the Last Call issues formally raised in our Tracker have been addressed as indicated in our Disposition of Comments [1]. If there are outstanding issues, then they're likely threads on www-dom that got lost in the shuffle. Kindly, can you be more explicit and enumerate the outstanding issues you're awaiting responses for? Thanks! [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html
Re: [DOM3Events] CR
On Sun, 04 Sep 2011 17:47:45 +0200, Doug Schepers wrote: On 9/4/11 9:41 AM, Anne van Kesteren wrote: 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. All our specifications use Web IDL normatively. I do not see why DOM Level 3 Events has to be special here. 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. The File API specification has a warning in the specification about this changing. I think at a minimum that should be stated. These were just two issues that came to mind though, I still have outstanding Last Call comments, as do other people. Anne, I try not to impute motives behind feedback, but you have been putting unusual energy behind undermining and blocking the progress of DOM3 Events, including: * deliberately defining conflicting behavior in a later edition specification being developed in parallel with DOM3 Events, without raising those issues with the DOM3 Events editors Not true. I already explained I started with a clean state. I then checked the differences and raised issues. * refusing to join telcons to which you were invited to discuss issues you've raised Not true. I did not refuse, but I indicated I could not join that day (if I remember correctly it would have been late at night for me). * asking other groups (like the Web Performance WG) not to cite DOM3 Events on the grounds that it is "obsolete" Not true. That was about DOM Level 3 Core and I did not say obsolete: http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0079.html * raising issues very late in the process that call for sweeping non-technical changes to the spec (such as splitting the spec out into 2 different specifications) That issue was raised almost well over a year ago now. And it was not just raised by me. It still seems like the best solution to me. That the "DOM Event Architecture" and "Basic Event Interfaces" chapters of DOM Level 3 Events are removed and that you make it an events specification similar to Progress Events. * claiming that W3C Process has been violated in dealing with your feedback, when it had not Water under the bridge. I already acknowledged this was a misunderstanding. * Finally, this email, where you state a false claim (that we don't provide Web IDL definitions) and introduce a blocking claim (exception handling) that will not be resolved anytime soon and which is not critical for the success of the spec and its implementations. Both are technical issues with the specification. Perhaps these were unintentional missteps on your part, rather than deliberate attempts to slow down the progress of the specification, but it had the same effect of causing more work for the editors and stalling the process. I don't think this is appropriate behavior for participating in a group in good faith, and seems more political than technical. I think you are making more out of this than it is. You have also provided good feedback to the spec, which we have incorporated and which we appreciate. This spec, with feedback from crucial implementers and reviewers, provides incremental and substantial improvements to the Open Web Platform, such as a much-needed standardized keyboard model, and I suggest that any further improvements needed can be made in a later DOM spec. Can we simply move forward, please? As long as we disagree on how I am not sure how. [1] http://www.w3.org/TR/DOM-Level-3-Events/#webidl-definitions -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM3Events] CR
On 9/4/11 10:06 AM, Doug Schepers wrote: On 9/4/11 12:49 PM, Charles Pritchard wrote: 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. We will be building a complete test suite and implementation report during CR phase, which is the traditional time that stuff is done. Informally, I believe that IE9+ implements all of the normative assertions in the DOM3 Events spec (there could be minor details that need better testing), and most of the spec is implemented in other browsers, since much of it is based on existing browser features. I think the least coverage is in one of the most important features, the keyboard model; I would love to see this implemented in more browsers than just IE, but haven't been able to get anyone to prioritize it yet. 'mouseenter' and 'mouseleave' also need broader support (John Resig was just asking me to expedite this the other day, on behalf of jQuery). I've got a bad situation with Apple's VoiceOver on Mobile Safari. As they have not taken any steps to improve Canvas accessibility, I'm in the unfortunate position of only having self-voicing via audio tags. Is mouseenter and mouseleave intended for touch events as well? On Mobile Safari's eyes-free interface, a user simply drags their touch across the screen, and as it enters various elements, the elements are voiced. The user then double-taps to focus on a given element. It's a whole-lot-of-work to re-implement that from scratch. mouseenter and mouseleave would lessen that burden. But, it is a touch* system, vs a mouse* system, at it's core. 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. I believe the right place to deal with that is in the CSS Object Model specs. Do you remember which list was discussing the addition of a MouseCoords method being available on mouse events? I believe the thought originated from the SVG realm. -Charles
Re: [DOM3Events] CR
On 9/4/11 12:49 PM, Charles Pritchard wrote: 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. We will be building a complete test suite and implementation report during CR phase, which is the traditional time that stuff is done. Informally, I believe that IE9+ implements all of the normative assertions in the DOM3 Events spec (there could be minor details that need better testing), and most of the spec is implemented in other browsers, since much of it is based on existing browser features. I think the least coverage is in one of the most important features, the keyboard model; I would love to see this implemented in more browsers than just IE, but haven't been able to get anyone to prioritize it yet. 'mouseenter' and 'mouseleave' also need broader support (John Resig was just asking me to expedite this the other day, on behalf of jQuery). 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. I believe the right place to deal with that is in the CSS Object Model specs. (Snipping discussion of DOM 4. I don't want to muddy the issue of moving DOM3 Events to CR with discussions of a later spec. Those issues should be dealt with in another thread.) Regards- -Doug
Re: [DOM3Events] CR
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 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
Re: [DOM3Events] CR
Hi, Anne- On 9/4/11 9:41 AM, Anne van Kesteren wrote: On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow 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. Anne, I try not to impute motives behind feedback, but you have been putting unusual energy behind undermining and blocking the progress of DOM3 Events, including: * deliberately defining conflicting behavior in a later edition specification being developed in parallel with DOM3 Events, without raising those issues with the DOM3 Events editors * refusing to join telcons to which you were invited to discuss issues you've raised * asking other groups (like the Web Performance WG) not to cite DOM3 Events on the grounds that it is "obsolete" * raising issues very late in the process that call for sweeping non-technical changes to the spec (such as splitting the spec out into 2 different specifications) * claiming that W3C Process has been violated in dealing with your feedback, when it had not * Finally, this email, where you state a false claim (that we don't provide Web IDL definitions) and introduce a blocking claim (exception handling) that will not be resolved anytime soon and which is not critical for the success of the spec and its implementations. Perhaps these were unintentional missteps on your part, rather than deliberate attempts to slow down the progress of the specification, but it had the same effect of causing more work for the editors and stalling the process. I don't think this is appropriate behavior for participating in a group in good faith, and seems more political than technical. You have also provided good feedback to the spec, which we have incorporated and which we appreciate. This spec, with feedback from crucial implementers and reviewers, provides incremental and substantial improvements to the Open Web Platform, such as a much-needed standardized keyboard model, and I suggest that any further improvements needed can be made in a later DOM spec. Can we simply move forward, please? [1] http://www.w3.org/TR/DOM-Level-3-Events/#webidl-definitions Regards- -Doug Schepers W3C Developer Outreach Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs
