Re: Adding implementor's note about event targets?

Rick and Art,

Thanks for the feedback.

On Mar 6, 2013, at 3:12 AM, Arthur Barstow wrote:

> On 3/1/13 9:45 AM, ext Rick Byers wrote:
>> Thanks for pushing on this Sangwhan, I agree having some wording is
>> valuable given the issues we've had.
>> 
>> I want to make sure I understand what the wording means (and ideally
>> matches our implementation).  When you say 'touch sequence' you mean
>> the sequence of events for a given touchID, right?  Don't we want to
>> be stronger than that - making restrictions across multiple touches?
>> Perhaps something along the lines of the following (with improved
>> wording - this is rough):
>> 
>> User agents must ensure that all Touch objects available from a given
>> TouchEvent are all relative to the same document that the TouchEvent
>> was dispatched too.  To implement this, user agents should maintain a
>> notion of the current touch-active document.  On first touch, this is
>> set to the target of the touch.  When all active touch points are
>> released, the touch-active document is cleared.  All TouchEvents are
>> dispatched to the current touch-active document, and each Touch object
>> it contains refers only to DOM elements (and co-ordinates) in that
>> document.  If a touch starts entirely outside the currently
>> touch-active document, then it is ignored entirely.
>> 
>> Does this match all the implementations?  I'm pretty sure this is what
>> Chrome does.  Olli?

Looks good to me. Possible adjustments, to make it a bit clear for readers
with less background knowledge on the context:

- TouchEvent are all relative to the same document that the TouchEvent
+ TouchEvent are all associated to the same document that the TouchEvent

- was dispatched too.  To implement this, user agents should maintain a
+ was dispatched to.  To implement this, user agents should maintain a

- set to the target of the touch.  When all active touch points are
+ set to the target document where the touch was created.  When all active touch points are

This matches Chrome (and the new Opera Mobile beta) and I think Safari
as well. Firefox I'm not sure - Presto doesn't match this behavior though.

>> I'm ok with the wording being less prescriptive, but it should have
>> something like the first sentence above at least (this is the key
>> restriction).
> 
> From the process perspective, if any new normative UA requirement is added, the spec will need to return to Last Call Working Draft. However, if this is more about clarifying behavior that is already widely implemented, then this could be viewed as a bug that requires some new text to clarify.
> 
> So, which is it (new requirement or clarification needed)?

It's closer to clarifying behavior that is already widely implemented. Presto
doesn't do it exactly as described, but that's probably not that big of a issue.

Presto allows multiple "touch-active documents", which is different from what
others are doing, but hopefully nobody will rely on that behavior. 

> Do we have a test for this? If not, who is willing to write a test?

No, we do not have a test for this. Depending on the timeframe that we need it
I can commit to writing one. (I'm fully booked until the end of next week, so after that)

> And yes, it would be good to get feedback from all of the implementations including all libraries we know about. Scott, what's the jQuery perspective here?

Hopefully the libraries shouldn't have to care about this, but probably better to
get a comment from Scott.

-- 
Sangwhan Moon, Opera Software ASA

Received on Wednesday, 6 March 2013 02:44:08 UTC