Re: DOM3 Events - additional editing help to move the spec forward
Hi Travis, on Tue, 29 May 2012 19:03:49 + Travis Leithead travis.leith...@microsoft.com wrote: Based on #1, we can't simply replace the current timestamp property on DOM events with a high-resolution time stamp--this would be a change (though perhaps not very impactful) to backward compatibility. Therefore, the only plausible action could be a new property (e.g., highResolutionTimeStamp or similar). 100% agree. However, I wonder what real value this would have. Typically events only fire within the scope of the current window and do not bleed out into other windows (Message and Storage events are notable exceptions)--so new Date() should be self-consistent (coming from the same script engine) even if other script engines are suffering from clock-skew. One issue that is present in IE, is Date objects that get serialized over from Web Workers--they can have a pretty big clock skew pretty quickly, but hypothetically performance.now() can cover those scenarios. Are there other specific use cases that you're finding where the timestamp property doesn't meet your needs? AFAIK, event.timeStamp is defined when the event is created, not when is dispatched. Thus, using new Date() as the first sentence of the callback function of the event could be problematic for two reasons: 1) If the event queue is not free when the event is created, creation and dispatching timestamps may differ. It would be nice to have both times: the timestamp of the creation of the event, and the timestamp when the event was dispatched. 2) Conversions between UNIX epoch based timestamps in milliseconds and monotonically increasing timestamps relative to the loaded page in microseconds could be tricky considering the former suffers problems that the later solves. As new APIs are adopting these new timestamps, IMHO it would be very positive to have the ability to work with DOM events in a coherent way with them (all monotonically increasing timestamps relative to the loaded page in microseconds). I will prepare the list of cases where this timestamp will be useful as James Robinson suggested. Thank you very much for your time ;-) -- Pablo Garaizar Sagarminaga Universidad de Deusto Avda. de las Universidades 24 48007 Bilbao - Spain Phone: +34-94-4139000 Ext 2512 Fax: +34-94-4139101
RE: DOM3 Events - additional editing help to move the spec forward
-Original Message- From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es] Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). It would be great to discuss this feature in future versions of the drafts mentioned before. I discussed this briefly with Jatinder Mann (who works on the High resolution timing spec--you might know him?). Based on that discussion it sounds like the high-resolution timestamp provides three features: 1. The timestamp is relative to the loaded page (not the Unix epoch) 2. The timestamp can be in microsecond resolution (a best effort-approach) 3. The timestamp is garuanteed to be monotonically increasing. Based on #1, we can't simply replace the current timestamp property on DOM events with a high-resolution time stamp--this would be a change (though perhaps not very impactful) to backward compatibility. Therefore, the only plausible action could be a new property (e.g., highResolutionTimeStamp or similar). However, I wonder what real value this would have. Typically events only fire within the scope of the current window and do not bleed out into other windows (Message and Storage events are notable exceptions)--so new Date() should be self-consistent (coming from the same script engine) even if other script engines are suffering from clock-skew. One issue that is present in IE, is Date objects that get serialized over from Web Workers--they can have a pretty big clock skew pretty quickly, but hypothetically performance.now() can cover those scenarios. Are there other specific use cases that you're finding where the timestamp property doesn't meet your needs?
Re: DOM3 Events - additional editing help to move the spec forward
On Tue, May 29, 2012 at 12:03 PM, Travis Leithead travis.leith...@microsoft.com wrote: -Original Message- From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es] Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). It would be great to discuss this feature in future versions of the drafts mentioned before. I discussed this briefly with Jatinder Mann (who works on the High resolution timing spec--you might know him?). Based on that discussion it sounds like the high-resolution timestamp provides three features: 1. The timestamp is relative to the loaded page (not the Unix epoch) 2. The timestamp can be in microsecond resolution (a best effort-approach) 3. The timestamp is garuanteed to be monotonically increasing. Based on #1, we can't simply replace the current timestamp property on DOM events with a high-resolution time stamp--this would be a change (though perhaps not very impactful) to backward compatibility. Therefore, the only plausible action could be a new property (e.g., highResolutionTimeStamp or similar). However, I wonder what real value this would have. Typically events only fire within the scope of the current window and do not bleed out into other windows (Message and Storage events are notable exceptions)--so new Date() should be self-consistent (coming from the same script engine) even if other script engines are suffering from clock-skew. One issue that is present in IE, is Date objects that get serialized over from Web Workers--they can have a pretty big clock skew pretty quickly, but hypothetically performance.now() can cover those scenarios. Are there other specific use cases that you're finding where the timestamp property doesn't meet your needs? The main value is that it makes it much easier to synchronize the event with various animations going on. The requestAnimationFrame API uses high resolution timers relative to the page load time, as does the performance.now() function. By putting time stamps of the same unit on events, it's much easier to do things like start animations when an event occurred, but do all rendering in requestAnimationFrame. I.e. it makes it easier to account for moving the animated item between the event occurs and when the rendering happens. Likewise it makes it easier to do things like hit detection to figure out where various objects on the screen were when an event occurs, accounting for partial movement between two rendered frames. / Jonas
Re: DOM3 Events - additional editing help to move the spec forward
On Fri, May 25, 2012 at 11:30 PM, Pablo Garaizar Sagarminaga garai...@deusto.es wrote: Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). Please come up with a list of cases where this timestamp would be useful and start a new thread on www-...@w3.org explaining your use cases and how you think this proposal would help. I agree that this could be quite useful. It would probably be handled as part of DOM4 events. - James It would be great to discuss this feature in future versions of the drafts mentioned before. Best regards, -- Pablo Garaizar Sagarminaga Universidad de Deusto Avda. de las Universidades 24 48007 Bilbao - Spain Phone: +34-94-4139000 Ext 2512 Fax: +34-94-4139101
Re: DOM3 Events - additional editing help to move the spec forward
Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). It would be great to discuss this feature in future versions of the drafts mentioned before. Best regards, -- Pablo Garaizar Sagarminaga Universidad de Deusto Avda. de las Universidades 24 48007 Bilbao - Spain Phone: +34-94-4139000 Ext 2512 Fax: +34-94-4139101
RE: DOM3 Events - additional editing help to move the spec forward
-Original Message- From: Travis Leithead Sent: Thursday, March 8, 2012 3:31 PM Hey folks, I'm joining Jacob Rossi to help work on editing the DOM L3 Events spec; I have some time to address some of the editorial last call comments, and I hope to move through them all pretty quickly. I know there are a variety of opinions out there regarding the DOM L3 Events spec, and what should be done with it. I'm going to start with the basis that it's a good spec. It provides a great deal of context into the event dispatch model (in the form of prose, versus the new algorithmic approach that has been popular since the HTML5 spec first hit the scene). It also describes basic concepts such as default actions and their effect on cancelable events, trusted events, etc., for which having a central reference is quite informative. In addition to the common event types, it also defines the elusive KeyboardEvent, a hallmark of this spec since the beginning. This spec is certainly aging. It's one of the oldest specs that is still in active development. I can see working drafts of DOM Level 3 events dating back to September 1st, 2000 [1]. Many, many folks have contributed to, reviewed, and provided feedback on this spec along the way. With the relatively youthful DOM4 spec poised to take the torch for the next round of DOM event functionality, I'd prefer to close up any lingering issues with DOM L3 Events, get it done (to Recommendation status), and turn my attention to DOM4. Getting DOM L3 Events to Rec is a very important milestone for UAs and implementations like IE, that have made a commitment to supporting this spec, have an existing implementation, and need a stable reference specification for our customers and partners. To support the goal of finishing DOM Level 3 Events (in light of the current work happening in DOM4), I'm jumping in to help Jacob finish addressing last call comments. I've interested in ensuring that the concepts and normative requirements of DOM Level 3 Events do not conflict with the existing model described in DOM4. In this way, I think DOM4 will be a natural succession from DOM Level 3 Events and will add to the richness of the eventing platform on the web. I've already made a few changes to the spec in regard to some existing last call comments [2]. I'm not done. I'll be officially working through bugs filed in the DOM3 Events component of the W3C Bug Tracker [3], and will be moving other issues from Tracker [4] into that system to make my life easier. Please file new comments as bugs, and I'll follow up there. Quick follow-up: To my knowledge all remaining Tracker issues and other feedback previously sent to Jacob have now been resolved in the Bugzilla component for DOM3 Events save one last issue. I'm currently working through the final issue (accessibility feedback) but didn't want to wait until that was resolved before sending this mail. The spec has been dramatically updated in the past 3 months, and should now be quite nicely aligned with DOM4's Events section. My plan, as mentioned at the March F2F meeting, is to resolve the last issue, then ask the chairs to start the LC process for this spec, with advancement to CR hopefully following soon thereafter. This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Also, if for some reason I missed responding to your previously written feedback, please re-send it or file a bug directly. DOM3 Events (Ed. Draft) http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html DOM4 Events section (WD) http://www.w3.org/TR/dom/#events Thanks, -Travis
Re: DOM3 Events - additional editing help to move the spec forward
On Fri, May 25, 2012 at 1:08 PM, Travis Leithead travis.leith...@microsoft.com wrote: -Original Message- From: Travis Leithead Sent: Thursday, March 8, 2012 3:31 PM Hey folks, I'm joining Jacob Rossi to help work on editing the DOM L3 Events spec; I have some time to address some of the editorial last call comments, and I hope to move through them all pretty quickly. I know there are a variety of opinions out there regarding the DOM L3 Events spec, and what should be done with it. I'm going to start with the basis that it's a good spec. It provides a great deal of context into the event dispatch model (in the form of prose, versus the new algorithmic approach that has been popular since the HTML5 spec first hit the scene). It also describes basic concepts such as default actions and their effect on cancelable events, trusted events, etc., for which having a central reference is quite informative. In addition to the common event types, it also defines the elusive KeyboardEvent, a hallmark of this spec since the beginning. This spec is certainly aging. It's one of the oldest specs that is still in active development. I can see working drafts of DOM Level 3 events dating back to September 1st, 2000 [1]. Many, many folks have contributed to, reviewed, and provided feedback on this spec along the way. With the relatively youthful DOM4 spec poised to take the torch for the next round of DOM event functionality, I'd prefer to close up any lingering issues with DOM L3 Events, get it done (to Recommendation status), and turn my attention to DOM4. Getting DOM L3 Events to Rec is a very important milestone for UAs and implementations like IE, that have made a commitment to supporting this spec, have an existing implementation, and need a stable reference specification for our customers and partners. To support the goal of finishing DOM Level 3 Events (in light of the current work happening in DOM4), I'm jumping in to help Jacob finish addressing last call comments. I've interested in ensuring that the concepts and normative requirements of DOM Level 3 Events do not conflict with the existing model described in DOM4. In this way, I think DOM4 will be a natural succession from DOM Level 3 Events and will add to the richness of the eventing platform on the web. I've already made a few changes to the spec in regard to some existing last call comments [2]. I'm not done. I'll be officially working through bugs filed in the DOM3 Events component of the W3C Bug Tracker [3], and will be moving other issues from Tracker [4] into that system to make my life easier. Please file new comments as bugs, and I'll follow up there. Quick follow-up: To my knowledge all remaining Tracker issues and other feedback previously sent to Jacob have now been resolved in the Bugzilla component for DOM3 Events save one last issue. I'm currently working through the final issue (accessibility feedback) but didn't want to wait until that was resolved before sending this mail. The spec has been dramatically updated in the past 3 months, and should now be quite nicely aligned with DOM4's Events section. My plan, as mentioned at the March F2F meeting, is to resolve the last issue, then ask the chairs to start the LC process for this spec, with advancement to CR hopefully following soon thereafter. This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Also, if for some reason I missed responding to your previously written feedback, please re-send it or file a bug directly. DOM3 Events (Ed. Draft) http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html DOM4 Events section (WD) http://www.w3.org/TR/dom/#events Yay! Awesome! Thanks for slugging through this work. Looking forward to LC soon! / Jonas
Re: DOM3 Events - additional editing help to move the spec forward
On Fri, 09 Mar 2012 00:30:34 +0100, Travis Leithead travis.leith...@microsoft.com wrote: I know there are a variety of opinions out there regarding the DOM L3 Events spec, and what should be done with it. I'm going to start with the basis that it's a good spec. It provides a great deal of context into the event dispatch model (in the form of prose, versus the new algorithmic approach that has been popular since the HTML5 spec first hit the scene). DOM has prose too, I added an introduction that explains the event model. It also describes basic concepts such as default actions and their effect on cancelable events, trusted events, etc., for which having a central reference is quite informative. Except the way it talks about default actions has been quite confusing, making people think it was somehow more tied to the event than it actually was. I've interested in ensuring that the concepts and normative requirements of DOM Level 3 Events do not conflict with the existing model described in DOM4. In this way, I think DOM4 will be a natural succession from DOM Level 3 Events and will add to the richness of the eventing platform on the web. That sounds great. Let me know how that goes! Ideally http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-events only lists event constructors I think. (It does not mention we removed CustomEvent.initCustomEvent() at the moment by the way.) -- Anne van Kesteren http://annevankesteren.nl/
RE: DOM3 Events - additional editing help to move the spec forward
-Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] It [DOM3 Events] also describes basic concepts such as default actions and their effect on cancelable events, trusted events, etc., for which having a central reference is quite informative. Except the way it talks about default actions has been quite confusing, making people think it was somehow more tied to the event than it actually was. Good feedback. I opened a bug to track reviewing that section and cleaning up anything that needs polish.
