Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)
On Thu, 13 Oct 2011 12:33:40 +0900, Anne van Kesteren ann...@opera.com wrote: On Thu, 13 Oct 2011 11:32:34 +0900, Jacob Rossi jacob.ro...@microsoft.com wrote: Your welcome, I appreciate your tolerance! I made a sweep in good faith through the list archives and was unable to find other unanswered issues. It is somewhat sad comments are not being tracked. I just went through the archives again http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0107.html does not seem to have a response. The same goes for http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0252.html and http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0253.html it seems. -- Anne van Kesteren http://annevankesteren.nl/
[DOM3Events] Oustanding issues (was: [DOM3Events] CR)
Hi Anne,
Talking with Doug this morning, it seems he didn't have a chance to reply to
your mail below since he's been pretty busy. I've provided responses below
inline, sorry for the delay!
Thanks,
Jacob
-Original Message-
From: Anne van Kesteren [mailto:ann...@opera.com]
Sent: Friday, September 09, 2011 3:00 AM
To: Doug Schepers; Jacob Rossi
Cc: public-webapps; Adrian Bateman; Arthur Barstow; Chaals McCathieNevile;
www-...@w3.org
Subject: Re: [DOM3Events] CR
On Tue, 06 Sep 2011 21:04:33 +0200, Jacob Rossi
jacob.ro...@microsoft.com 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
IE and Gecko match the spec. Opera and Webkit do not match the spec--but that
seems like a bug. I'm not sure why calling preventDefault() on one dispatch of
an event should cancel the default action of a second dispatch of that event.
Furthermore, applications don't have the ability to reset this flag themselves.
If implementations don't reset this flag for them, then there's no way to
separate the default actions between multiple dispatches of the event
(cancelling dispatch A always also cancels dispatch B). However, if
implementations do reset the flag then the application can always elect to take
into consideration the return value of dispatch A when performing the default
action of dispatch B.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0065.html
Whether D3E needs EventException was covered in the discussion for ISSUE-179
(http://www.w3.org/2008/webapps/track/issues/179).
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0066.html
The efforts DOM4 makes here are great extensions to DOM L3 Events.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0067.html
I had difficulty testing in Opera (probably something silly I'm doing). The
spec indicates that calling preventDefault() should have no effect on
non-cancellable events (therefore defaultPrevented is still false). But at
least Webkit, IE, and Gecko have interoperable implementations that match the
spec.
var e = document.createEvent(Event)
e.initEvent(test, false, false);
document.addEventListener(test, function(e) {
alert(e.defaultPrevented);
e.preventDefault();
alert(e.defaultPrevented);
});
document.dispatchEvent(e);
e = document.createEvent(Event)
e.initEvent(test, false, true);
document.dispatchEvent(e);
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html
I could see a future spec allow this given a good set of scenarios. DOM3 I
believe DOM4 does this. But I don't see this as a requirement
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0122.html
Ah, yes, may only be called is a bit confusing. A clearer statement is must
be called--which is the intent. Otherwise, if you don't initialize the event
then you'll get an exception when you try to dispatch it. I think this is a
worthy grammatical clarification, so I've updated the spec to be clearer.
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0131.html
Since this one's a bit longer, I'll reply separately on it.
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.
There has been a Last Call since the normative changes to Event Type:
Revision 1.189 made the changes to event.type
Revision 1.200 published the spec for the most recent Last Call
According to the CVS log, all changes since that Last Call draft have been
editorial with the exception of Revision 1.204. However, that change was more
of a clarification which matches all implementations.
[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)
On Thu, 13 Oct 2011 09:54:26 +0900, Jacob Rossi
jacob.ro...@microsoft.com wrote:
Talking with Doug this morning, it seems he didn't have a chance to
reply to your mail below since he's been pretty busy. I've provided
responses below inline, sorry for the delay!
Thanks for getting to them. These were the issues I could quickly find.
How did you make sure no other comments have been missed?
Replies to your responses below.
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
IE and Gecko match the spec. Opera and Webkit do not match the spec--but
that seems like a bug. I'm not sure why calling preventDefault() on one
dispatch of an event should cancel the default action of a second
dispatch of that event.
No, but after an event is dispatched you want event.defaultPrevented to
reflect the result and not have been reset.
Furthermore, applications don't have the ability to reset this flag
themselves. If implementations don't reset this flag for them, then
there's no way to separate the default actions between multiple
dispatches of the event (cancelling dispatch A always also cancels
dispatch B). However, if implementations do reset the flag then the
application can always elect to take into consideration the return value
of dispatch A when performing the default action of dispatch B.
As I suggested in the email we could make initEvent() reset these flags.
This is what DOM4 does.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0065.html
Whether D3E needs EventException was covered in the discussion for
ISSUE-179 (http://www.w3.org/2008/webapps/track/issues/179).
Yes, and you have not replied to my latest comments on that issue:
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0047.html
Meanwhile we have also made up the plan for exceptions -- everything is
going to be DOMException -- and Gecko has already implemented the DOM4
behavior.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0066.html
The efforts DOM4 makes here are great extensions to DOM L3 Events.
These are not extensions. This is basic functionality that needs to be
defined.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0067.html
I had difficulty testing in Opera (probably something silly I'm doing).
Opera does not have the optional argument for addEventListener prior to
Opera 12.
The spec indicates that calling preventDefault() should have no effect
on non-cancellable events (therefore defaultPrevented is still false).
The way this is phrased in the specification is highly confusing as
defaultPrevented does not mention the non-cancelable clause.
But at least Webkit, IE, and Gecko have interoperable implementations
that match the spec.
var e = document.createEvent(Event)
e.initEvent(test, false, false);
document.addEventListener(test, function(e) {
alert(e.defaultPrevented);
e.preventDefault();
alert(e.defaultPrevented);
});
document.dispatchEvent(e);
e = document.createEvent(Event)
e.initEvent(test, false, true);
document.dispatchEvent(e);
Yeah, so in Opera I get false, true, false, true, rather than false,
false, false, true.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html
I could see a future spec allow this given a good set of scenarios. DOM3
I believe DOM4 does this. But I don't see this as a requirement
It's about how the feature is implemented today. The definition in DOM
Level 3 Events does not match existing implementations and as Boris
indicates in
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0071.html this
might be a compatibility hazard.
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0122.html
Ah, yes, may only be called is a bit confusing. A clearer statement is
must be called--which is the intent. Otherwise, if you don't
initialize the event then you'll get an exception when you try to
dispatch it. I think this is a worthy grammatical clarification, so I've
updated the spec to be clearer.
This has no relation to my comment.
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0131.html
Since this one's a bit longer, I'll reply separately on it.
Okay.
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.
There has been a Last Call since the normative changes to Event Type:
Revision 1.189 made the changes to event.type
Revision 1.200 published the spec for the most recent Last Call
1.201 is not editorial either. And does not define the callback this
value I noticed.
RE: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)
-Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, October 12, 2011 6:27 PM To: Doug Schepers; Jacob Rossi Cc: public-webapps; Adrian Bateman; Arthur Barstow; Chaals McCathieNevile; www-...@w3.org Subject: Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR) On Thu, 13 Oct 2011 09:54:26 +0900, Jacob Rossi jacob.ro...@microsoft.com wrote: Talking with Doug this morning, it seems he didn't have a chance to reply to your mail below since he's been pretty busy. I've provided responses below inline, sorry for the delay! Thanks for getting to them. These were the issues I could quickly find. How did you make sure no other comments have been missed? Your welcome, I appreciate your tolerance! I made a sweep in good faith through the list archives and was unable to find other unanswered issues. Replies to your responses below. 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 IE and Gecko match the spec. Opera and Webkit do not match the spec--but that seems like a bug. I'm not sure why calling preventDefault() on one dispatch of an event should cancel the default action of a second dispatch of that event. No, but after an event is dispatched you want event.defaultPrevented to reflect the result and not have been reset. The result is reflected in the return value from dispatchEvent(). defaultPrevented is for use by event listeners; the return value of dispatchEvent is for use by event dispatchers. Furthermore, applications don't have the ability to reset this flag themselves. If implementations don't reset this flag for them, then there's no way to separate the default actions between multiple dispatches of the event (cancelling dispatch A always also cancels dispatch B). However, if implementations do reset the flag then the application can always elect to take into consideration the return value of dispatch A when performing the default action of dispatch B. As I suggested in the email we could make initEvent() reset these flags. This is what DOM4 does I see no need to require authors to call initEvent with the same parameters simply to reset these flags (and to make at least 3 implementations change). I can't think of a valid scenario not solved by DOM3Events' definition. The return value of dispatchEvent() will indicate the result of the flag per dispatch. Then author can decide if he or she wants to do some logical combination of those return values if he or she wants preventDefault() to persist across dispatches. I believe the most common case, however, is that each dispatch will have a default action and you'll want a fresh set of flags for that--DOM3 Events has optimized for this scenario (but doesn't prohibit building an application that does otherwise). http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0065.html Whether D3E needs EventException was covered in the discussion for ISSUE-179 (http://www.w3.org/2008/webapps/track/issues/179). Yes, and you have not replied to my latest comments on that issue: http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0047.html Meanwhile we have also made up the plan for exceptions -- everything is going to be DOMException -- and Gecko has already implemented the DOM4 behavior. I've noted your response to the group's resolution on this issue in the disposition of comments. I'll reply to the thread to ensure that's clear to anyone else reading the archives. http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0066.html The efforts DOM4 makes here are great extensions to DOM L3 Events. These are not extensions. This is basic functionality that needs to be defined. We were fine without such definitions in DOM L2 Events. Even if DOM3 Events defined this, then I would consider that an extension to DOM L2 Events. I see no difference if this is left for DOM4 to define. http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0067.html I had difficulty testing in Opera (probably something silly I'm doing). Opera does not have the optional argument for addEventListener prior to Opera 12. The spec indicates that calling preventDefault() should have no effect on non-cancellable events (therefore defaultPrevented is still false). The way this is phrased in the specification is highly confusing as defaultPrevented does not mention the non-cancelable clause. I didn't find it confusing. But I don't want to be confusing to others, so I don't mind clarifying it. I'll do this along with the editorial changes suggested by Ms2ger. But at least Webkit, IE, and Gecko have interoperable implementations that match the spec. var e = document.createEvent(Event) e.initEvent(test, false, false); document.addEventListener(test, function(e
Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)
On Thu, 13 Oct 2011 11:32:34 +0900, Jacob Rossi jacob.ro...@microsoft.com wrote: Your welcome, I appreciate your tolerance! I made a sweep in good faith through the list archives and was unable to find other unanswered issues. It is somewhat sad comments are not being tracked. I just went through the archives again http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0107.html does not seem to have a response. No, but after an event is dispatched you want event.defaultPrevented to reflect the result and not have been reset. The result is reflected in the return value from dispatchEvent(). defaultPrevented is for use by event listeners; the return value of dispatchEvent is for use by event dispatchers. But that is not what is implemented. As I suggested in the email we could make initEvent() reset these flags. This is what DOM4 does I see no need to require authors to call initEvent with the same parameters simply to reset these flags (and to make at least 3 implementations change). Implementations will have to change either way, see above. With what I am saying you can also catch get hold of the final value for non-synthetic events. That does not work if you reset it prematurely. The other option is resetting the canceled flag at the start of a synthetic dispatch invocation. Whether D3E needs EventException was covered in the discussion for ISSUE-179 (http://www.w3.org/2008/webapps/track/issues/179). Yes, and you have not replied to my latest comments on that issue: http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0047.html Meanwhile we have also made up the plan for exceptions -- everything is going to be DOMException -- and Gecko has already implemented the DOM4 behavior. I've noted your response to the group's resolution on this issue in the disposition of comments. I'll reply to the thread to ensure that's clear to anyone else reading the archives. This is not a sufficient reply to the new information I just brought forward. http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0066.html The efforts DOM4 makes here are great extensions to DOM L3 Events. These are not extensions. This is basic functionality that needs to be defined. We were fine without such definitions in DOM L2 Events. Even if DOM3 Events defined this, then I would consider that an extension to DOM L2 Events. I see no difference if this is left for DOM4 to define. We were not fine at all. It was one of the many bugs in DOM Level 2 Events. If you want to knowingly perpetuate this bug you have to spell that out in the draft so it is at least clear it is not defined. http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html I could see a future spec allow this given a good set of scenarios. DOM3 I believe DOM4 does this. But I don't see this as a requirement It's about how the feature is implemented today. The definition in DOM Level 3 Events does not match existing implementations and as Boris indicates in http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0071.html this might be a compatibility hazard. I'm sorry, what I wrote above wasn't meant to be in response to this issue. I pasted my response under the wrong thread. My response below (Ah, yes 'may only..) was in reference to this issue. This sentence in the spec wasn't ever intended to prohibit calling initEvent() after dispatch. Rather, it was intended to say that you must initialize it before dispatch. Calling it again after dispatch is allowed, and as you note it is implemented that way across browsers. The specification currently reads This method has no effect if called after the event has been dispatched. So I am not sure what you are talking about. Now, in regards to: http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0122.html This is a non-normative table that describes common target types for events defined in DOM3 Events. From above the table: Refer to the specification defining the language used in order to find those restrictions or to find event types that are not defined in this document. The following table provides a non-normative summary of the event types defined in this specification. Because it is non-normative, it does not forbid dispatching load events at XMLHTTPRequest, for example. Non-normative is not some license to write down nonsense. Please correct the text. 1.201 is not editorial either. And does not define the callback this value I noticed. A fragment sentence (editorial) caused the commenter (Rob Brackett) to not understand the intended behavior of the spec (which is interoperably implemented). I removed this ambiguity. The commenter agreed we weren't changing the specified behavior and was satisfied with the change: http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0045.html http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0058.html Defining that you
Re: [DOM3Events] CR
On Tue, 06 Sep 2011 21:04:33 +0200, Jacob Rossi jacob.ro...@microsoft.com 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 schep...@w3.org 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
[DOM3Events] CR
On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow art.bars...@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 and we still have not settled how to deal with exceptions on the web platform. -- Anne van Kesteren http://annevankesteren.nl/
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 art.bars...@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. 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
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 art.bars...@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
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 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
Mouse vs. Touch Events (was: [DOM3Events] CR)
Hi, Charles- (Renaming thread, because this is not relevant to moving DOM3 Events to CR) On 9/4/11 1:27 PM, Charles Pritchard wrote: 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 suggest you raise this in the context of the touch stuff in the Web Events WG (where we are doing the Touch Interface spec). 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. We discussed it here, but decided that that would be better dealt with in the new CSS transforms and SVG2 specs. Regards- -Doug
