Re: Adding implementor's note about event targets?

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?
>
> 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)?

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

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?

-Thanks, ArtB



>
> 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.
>>
>> 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 Tuesday, 5 March 2013 18:14:01 UTC