Re: Adding implementor's note about event targets?

Hi All,

Starting with Rick's original text, applying Sangwhan's suggested 
changes, softening the one must to should and adding some format tags, I 
get:

[[
<div class="note"><div class="note-title"><span>Note</span></div><p 
class="">
User agents should ensure that all Touch objects available from a given 
TouchEvent are all associated to the same document that the TouchEvent 
was dispatched to. To implement this, user agents should maintain a 
notion of the current <em>touch-active</em> document. On first touch, 
this is set to the target document where the touch was created. When all 
active touch points are released, the <em>touch-active</em> document is 
cleared. All TouchEvents are dispatched to the current 
<em>touch-active</em> 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 <em>touch-active</em> document, 
then it is ignored entirely.
</p></div>
]]

(The format of the this new Note (which is non-normative by definition) 
would be identical to the Note in Section 7 
<http://www.w3.org/TR/2013/WD-touch-events-20130124/#mouse-events>.)

Is the above text OK?

Re where to put this Note in the spec, I don't have a strong preference 
so feedback is welcome. One possibility is to put it after Section 5.1 
in a new Section titled something like "Notes for User Agents". Another 
option is put it in a new section after Section 5.7. WDYPropose?

Re testing this behavior, given this is non-normative text, I don't 
think a test case is mandatory (although if someone wanted to create a 
test, that would be fine).

-Thanks, Art


On 3/6/13 12:03 PM, ext Rick Byers wrote:
> On Tue, Mar 5, 2013 at 9:43 PM, Sangwhan Moon <smoon@opera.com 
> <mailto:smoon@opera.com>> wrote:
>
>     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.
>
>
> Agreed this is really just clarification of an omission.  The fact 
> that multiple documents can't be referenced from one event follows 
> from the HTML5 security model (not sure which spec best covers this, 
> but presumably it's in HTML5 and/or others).  I don't think we need to 
> be prescriptive on exactly how this is enforced, perhaps most of the 
> text should be in a non-normative note?  Eg. I don't see any reason 
> why Presto's behavior should be considered invalid.
>
>     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)
>
>
> Thanks Sangwhan!  Assuming we go with most of the description in a 
> non-normative note, then the test should be pretty limited - I guess 
> just make sure that the TouchEvent object only has 
> touches/changedTouches entries for the touch in the same document. 
>  I'm not sure of the exact right balance here in getting good test 
> coverage but avoiding taking a dependency on an implementation detail 
> (eg. should we make sure Presto passes the test too?).
>
>     > 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 Monday, 11 March 2013 17:40:01 UTC