Re: Adding implementor's note about event targets?

On Tue, Mar 5, 2013 at 9:43 PM, Sangwhan Moon <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
>
>