W3C home > Mailing lists > Public > public-webevents@w3.org > January to March 2013

Re: Adding implementor's note about event targets?

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 20 Mar 2013 18:42:09 +0100
Message-ID: <5149F4F1.1050807@helsinki.fi>
To: Rick Byers <rbyers@google.com>, Sangwhan Moon <smoon@opera.com>
CC: Arthur Barstow <art.barstow@nokia.com>, "public-webevents@w3.org WG" <public-webevents@w3.org>
On 03/01/2013 03:45 PM, 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?

Yes, matches Gecko. (and I believe Safari+Webkit too)



>
> 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).
>
> Rick
>
>
> On Thu, Feb 28, 2013 at 12:44 PM, Sangwhan Moon <smoon@opera.com> wrote:
>> Draft proposal:
>>
>> User agents must ensure a TouchEvent dispatched from a single
>> Document origin stays within the Document boundaries.
>>
>> In the event of the TouchEvent crossing Document boundaries,
>> only the original Document which the first touchstart event
>> of a single touch sequence was created will receive consequential
>> events, and all event targets of the TouchEvent must only expose
>> event targets within the same document.

Sound ok to me.


>>
>> I'm not sure where would be the best location for this to be placed -
>> for now I tacked it in the "List of TouchEvents types" section.
>>
>> Comments are welcome.
>>
>> Sangwhan
>>
>> On Feb 26, 2013, at 11:25 PM, Arthur Barstow wrote:
>>
>>> Sangwhan - this is one of two comments that is blocking the progression of this spec to Proposed Recommendation [LC-comments].
>>>
>>> Would you please either withdraw your comment or make a specific proposal by March 1?
>>>
>>> -Thanks, ArtB
>>>
>>> [LC-Comments] <http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-Jan-2013>
>>>
>>>
>>> On 1/30/13 1:53 PM, ext Sangwhan Moon wrote:
>>>> On Jan 30, 2013, at 8:39 PM, Arthur Barstow wrote:
>>>>
>>>>> On 1/30/13 12:17 AM, ext Sangwhan Moon wrote:
>>>>>> Bumping Art's comment from another place.
>>>>>>
>>>>>> Since there has already been cases where implementations had issues with event targets
>>>>>> in multiple frame documents, I've been thinking about adding a explicit but non-normative
>>>>>> implementor's note about event targets since the spec has been re-opened.
>>>>>>
>>>>>> Ideas?
>>>>> Please make a specific proposal (including where you think it should be inserted in  the spec) and is this a v1 and/or v2 proposal?
>>>> It should apply to both as it is a bit ambiguous at the moment, I'll write something more
>>>> specific and where it would probably belong best after giving it some thought.
>>>>
>>>
>>
>> --
>> Sangwhan Moon, Opera Software ASA
>>
>>
Received on Wednesday, 20 March 2013 17:43:05 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 20 March 2013 17:43:06 GMT