W3C home > Mailing lists > Public > public-webevents@w3.org > July to September 2011

Re: Input on ISSUE-16

From: Matt Brubeck <mbrubeck@mozilla.com>
Date: Tue, 09 Aug 2011 09:38:46 -0700
Message-ID: <4E416296.4020900@mozilla.com>
To: Sangwhan Moon <smoon@opera.com>
CC: public-webevents@w3.org
On 08/03/2011 06:16 AM, Sangwhan Moon wrote:
> We haven't reached a conclusion on ISSUE-16, which is the main reason
> why I've specifically avoided cases that have any assumptions on that
> for now, but after doing the example code my take on the issue is that
> all TouchLists should be thin - being collections of references pointing
> to individual touches.
>
> Bottom line - I think all of the asserts mentioned in ISSUE-16 should pass.

I disagree.  In particular, I feel strongly that the assert in 
ISSUE-16's second example should fail.  Here's the example:

window.addEventListener("touchstart", function(e0) {
    var touch0 = e0.touches[0];
    var id = touch.identifier;
    window.addEventListener("touchmove", function(e1) {
      var touch1 = e1.touches.identifiedPoint(id);
      assert(touch0 == touch1); // Should this be true?
    });
});

I think that re-using the Touch object it like this would surprise 
authors, because it requires the objects from an old event to mutate in 
response to a new event.  Mutating the same object would break code that 
keeps a reference to the previous object, for example to compare it to 
the next one:

   var deltaX = touch1.clientX - touch0.clientX;
   var deltaY = touch1.clientY - touch0.clientY;

Laszlo's research from action 46 indicates that WebKit does not re-use 
touch objects in this way, so if we change this then we risk breaking 
existing code that does things like the above.

Touch objects are immutable from the author's point of view (there's no 
way for authors to change their attributes).  I think it is beneficial 
for them to be immutable, period.  Perhaps as a resolution to this issue 
we should change the spec to require this.

As long as these objects are immutable, then the whole question of 
shared identity is relatively unimportant, because it would no longer 
affect code that looks only at the object's data.  (It would just affect 
code that directly compares identities, as in the ISSUE-16 examples.)
Received on Tuesday, 9 August 2011 16:39:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:53 UTC