Web Events WG Voice Conference -- 22 Feb 2011

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 22 February 2011

<smaug_> finally

Tweak Agenda

AB: I posted a draft agenda yesterday ( http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0066.html ). The main idea is to focus the call on specific issues. Any change requests?

Issue-1 Resolve touch area re. radius and angle

AB: Issue-1 ( http://www.w3.org/2010/webevents/track/issues/1 ) and Action-11 ( http://www.w3.org/2010/webevents/track/actions/11 )

DS: it seems reasonable
... what they are suggesting
... I read the Canonical linux spec
... However, there are aspects I don't quite understand
... The document they pointed me to is copyrighted
... Must be careful about chaning it re copyright
... I don't want to introduce mistakes nor violate copright
... I have had some conversations
... and need to follow-up with them
... We must make sure we don't violate any copyright issues

OP: is there something like this in InkML spec?
... perhaps we can use their wording

DS: it's a good idea for us to align with InkML in general
... they do talk about angle in the spec

<sangwhan> http://www.w3.org/TR/InkML/

DS: but don't talk about it in quite the same way as the Linux docs

<shepazu> http://www.w3.org/TR/InkML/#orientation

DS: Think of their channels as our properties

<timeless> [ InkML channels ~ DOM properties

DS: InkML channels are not identical to our properties ]
... but for our purposes, we can consider them the same

<mbrubeck> It looks like InkML's OR ("rotation (counter-clockwise rotation about pen axis)") is equivalent to ABS_MT_ORIENTATION from the kernel multi-touch docs, in the case where tip=ellipse.

<scribe> ACTION: doug follow up with the canonical guys re copyrights [recorded in http://www.w3.org/2011/02/22-webevents-minutes.html#action01]

<trackbot> Created ACTION-16 - Follow up with the canonical guys re copyrights [on Doug Schepers - due 2011-03-01].

AB: we must be very careful re IP when looking at inputs from non WG members

DS: W3C IP commitments only cover IP from Members that were members of the WG that created the Recommendation
... For example, if W3C Member A is not a member of Web Events, any spec we create does not include a RF commitment from Member A
... has anyone else reviewed the Linux documentation i.e. kernel mulit-touch

MB: I think it is a straight fwd change to what we have spec'ed now
... they address some other things we may not need to specify to the same degree
... I have related action-11 and I hope to check something into the ED today
... being careful re copyright

AB: does anyone else have feedback on the Linux multi-touch spec?

JS: one thing we should look at are CSS specs that added angle stuff
... we may want to look at the various proposals
... I think animations, transitions or some other may have some stuff for us

<sangwhan> http://www.w3.org/TR/css3-values/#angles

JS: We should try to be consistent if/when it makes sense

DS: looking at the InkML diagram ...
... I'll see if I can reuse their diagram
... there are 2 different angles
... the angle perpendicular to the surface
... and the angle that is circle around the midpoint
... f.ex. if the device is vert and finger is vert
... but if finger comes from a side
... we may want to address that

JS: I thought we were only talking about the ellipse distortion; but it sounds like someone is raising the angle of incidence to the surface

MB: I think JS is raising a different issue
... angle of pen to surface

DS: agree we should try to be consistent with CSS
... and InkML and Geolocation Device Orientation
... perhaps we should get a summary of the various angle uses
... and include a recommendation
... can you do that Josh?

JS: I think we only care about the ellipse angle

DS: there are different things we can talk about re angles
... the units

<mbrubeck> s/I'm not particularly interested in covering it.//

<mbrubeck> I didn't say that.

DS: In SVG one can have radians or degrees
... we should decide how we are going to handle this
... I can't take on the "angle summary"
... Can you do that for CSS Josh?

JS: perhaps OP or SM can do that work

AB: can someone do the analysis Doug is recommending?

DS: I won't be here for the next 3 weeks
... [so we have some time ... ]

OP: ok, I'll look into this

<timeless> [ http://www.w3.org/TR/SVG/types.html#InterfaceSVGAngle ]

<scribe> ACTION: olli investiage various angle-related work e.g. InkML, CSS, SVG, ... [recorded in http://www.w3.org/2011/02/22-webevents-minutes.html#action02]

<trackbot> Created ACTION-17 - Investiage various angle-related work e.g. InkML, CSS, SVG, ... [on Olli Pettay - due 2011-03-01].

<timeless> i think mostly the issue is that for a DOM api we're only going to be able to expose properties with a single unit. so it's a matter of picking / recommending the best unit.

Raised Issues

AB: we have 5-6 "raised" issues. Before we look at them, I have a few lead in comments ...
... as we discussed last week, when an issue is created, it is automatically tagged with a "Raised" state. From that state it can advance to: "Open" which means we agree this is an issue; to "Postponed" if we agree it is an issue but will not address it in the version of the spec in which we are currently working; to "Closed" if we will not address the issue (ever).

<mbrubeck> Degrees have at least one advantage over radians, which is that common values can be represented exactly in floating-point arithmetic.

AB: why do we care about issue state? It is important, especially for those interested in our work but not directly contributing, to keep the state of the issues up-to-date.
... for the purposes of today, it would be good to review the Raised Issues and to at least get a sense of what, if anything, we want to do with the issue. That is, we don't necessarily need to "address" the issue during this call but we may want to, for example, assign one or more actions for an issue.

<sangwhan> Probably not the best option, but following the SVGAngle interface and indicating the unit type is also a option (although not pretty in ECMAScript)

<shepazu> Geolocation API WG's Device Orientation spec: http://dev.w3.org/geo/api/spec-source-orientation.html

Issue-2 What should happen when a touch is dragged off the screen

AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/2 )

MB: I think something like touch cancel should be defined
... not sure though we can mandate it
... may not be detectable on some hardware
... as such, think we need to do some research here
... to understand how this could be done on some hw

SM: resistive screens think pen left the screen

DS: but we have other screens to consider

SM: but if spec is directed to capative only then will be trick to do
... touch area needs to be predefined value
... from app dev view, only 1 pixel is detected

DS: I'm not suggesting we talk about 1 or the other
... we should talk about both
... and can have conditional characteristics
... e.g. "if device supports ... then must do ..."

SM: I can do some investigation here

<scribe> ACTION: moon do some investigation for Issue-2 [recorded in http://www.w3.org/2011/02/22-webevents-minutes.html#action03]

<trackbot> Created ACTION-18 - Do some investigation for Issue-2 [on Sangwhan Moon - due 2011-03-01].

Issue-3 Click event target after DOM mutation during touchstart

AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/3 )
... any comments?

MB: think this is part of a larger issue re how default events translate to clicks and other mouse events
... From an impl pov, click is based on touchend event so if insert new element
... <missed some stuff >
... Think we need to talk about when and how mouse events are fired for browser supporting touch events

AB: any actions for this?
... Does anyone want to help move it forward?
... Otherwise, we keep it Raised

DS: I'm interested in helping but can't take on extra tasks/actions now

Issue-4 Does preventDefault on touchmove cause a dragging motion to fire a click event?

AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/4 )

MB: this is part of the larger issue I just mentioned
... think we need a framework on how to address this

DS: yes, agree with MB

JS: I think Andrew is right that not blocking seems silly
... but it is too early to move this issue to another state

AB: ok; so let's leave it Raised for now

Issue-5 What events fire if an alert is performed within a touch sequence?

AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/5 )

OP: I updated the Issue some

JS: personally, don't want the UI to block
... A user triggering drag start won't want an alert to pop up
... gives a bad UI

MB: in spec, touchcancel there is some relevant text

JS: triggering events within an alert is bad

<mbrubeck> That's true

DS: how can this be done

JS: spec can say nested event loop results in an exception

SM: think that is a bit extreme

<mbrubeck> If we don't define alert() -> touchcancel, then there's no event loop

SM: spec could discourage this and that may be enough

MB: Andrew said every touch start should have a touchend
... makes sense

DS: if have a cancel, need to send a touchend

<sangwhan> +1

JS: do you want 1 event or both cancel and end?

DS: a touch cancel would have a default action of touch end event

OP: agree that makes sense
... need to define when if before or after alert
... XHR is a bit trickier; if synchronous, no events while it is handled
... should browser queue events?

<timeless> -- again, throwing is the simplest solution

<timeless> .. and it yields the best user experience :) ... plus it discourages sync XHR

AB: any actions for Issue-5? Anyone want to help move it forward?

Issue-6 Touch targets in frames

AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/6 )
... Andrew asks "How do touch events propagate when they begin on an iframe?"

MB: is this addressed by some other spec?
... e.g. DOM events spec?

DS: I don't think DOM events spec addresses this

OP: correct, no spec defines event target

DS: seems like HTML since that is where frames are defined

MB: think they should be dispatched to elements within the frame
... don't think it would controversial if we define this

JS: think about narrow ad
... may have a security issue here

DS: it is related to setCapture
... which is an API/method to say all events are targeted at this element until I say releaseCapture

<timeless> [ https://developer.mozilla.org/en/DOM/element.setCapture ]

DS: if have 100x100 iframe and then move to another iframe, which events does the iframe get?
... are mouse moves for outer frame
... from sec perspective, when it exits iframe, there should be no more events
... unless there is a touch cancel or touch moves back
... but that could be a new touch event

JS: if device is fixed screen and app knows it
... based on event, app could figure where it is on the page
... this can permit a disclosure (leak)

AB: should we move this to Open (we will address) or leave it Raised?
... for now leave it Raised

Issue-7 Targets for touch events: Elements or Nodes?

AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/7 )
... this is from Andrew "Targets for touch events, Elements or Nodes?"

SM: think it should be aligned with mouse events

MB: PPK talked about this on the list
... he thinks it is a bug that has not been fixed
... I don't know if this is accurate
... think there is consensus on the list that Elements should be the target
... I can put text in the ED and then ask people if they have any objections

DS: I'm OK with this

MB: there could be some cases for Node target
... but I doubt most web authors would use it

AB: I'm OK with Matt's proposal

<scribe> ACTION: brubeck to address Issue-7 [recorded in http://www.w3.org/2011/02/22-webevents-minutes.html#action04]

<trackbot> Created ACTION-19 - Address Issue-7 [on Matt Brubeck - due 2011-03-01].

<mbrubeck> interesting... http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/events/EventTarget.html

<scribe> ACTION: barstow Issue-7 to open [recorded in http://www.w3.org/2011/02/22-webevents-minutes.html#action05]

<trackbot> Created ACTION-20 - Issue-7 to open [on Arthur Barstow - due 2011-03-01].

<mbrubeck> "The EventTarget interface is implemented by all Nodes in an implementation which supports the DOM Event Model."

AB: and if no objects to Matt's proposal, Issue-7 will be closed

<smaug_> mbrubeck: what is interesting in that? In Gecko all Nodes implement EventTarget

AOB

<mbrubeck> smaug_: Oh yeah, I guess that makes sense, for things like mutation events.

AB: with Doug going away for 3 weeks, I think we should this time to work on the known issues
... and not have any calls until Doug returns
... Is this OK?

MB: OK

OP: OK

SM: OK

<smaug_> timeless: yes, seems to be you

AB: next call will be March 22
... so everyone, please work on the Open and Raised issues and Open Actions
... perhaps 1-2 weeks after we resume calls, we will be in a position to talk about a First Public WD
... meeting adjourned

- DRAFT -

Web Events WG Voice Conference

22 Feb 2011

Attendees

Contents