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

Re: Adding implementor's note about event targets?

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 20 Mar 2013 15:37:44 -0400
Message-ID: <514A1008.4090302@nokia.com>
To: Rick Byers <rbyers@google.com>, Sangwhan Moon <smoon@opera.com>
CC: "public-webevents@w3.org WG" <public-webevents@w3.org>
On 3/20/13 1:42 PM, ext Olli Pettay wrote:
> 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 went ahead and checked in a change that includes the text proposed 
earlier [1]. This commit puts the Note in a new non-normative section 5.2.

Changeset: <https://dvcs.w3.org/hg/webevents/rev/6f2c52cd50f6>

Sangwhan, Rick - for the purposes of the LC comment tracking, please let 
us know if this is acceptable or not, and in case it is not, please 
propose text that will address your concerns.

-Thanks, Art


>> 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 19:38:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:34 UTC