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

Draft minutes: 22 February 2011 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 22 Feb 2011 12:16:44 -0500
Message-ID: <4D63EF7C.30207@nokia.com>
To: "public-webevents@w3.org" <public-webevents@w3.org>
The draft minutes from the February 22 voice conference are available at 
the following and copied below:


WG Members - if you have any comments, corrections, etc., please send 
them to the public-webevents mail list before March 22 (the next voice 
conference); otherwise these minutes will be considered Approved as is.

-Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                     Web Events WG Voice Conference

22 Feb 2011


       [2] http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0066.html

    See also: [3]IRC log

       [3] http://www.w3.org/2011/02/22-webevents-irc


           Art_Barstow, Josh_Soref, Cathy_Chan, Matt_Brubeck,
           Olli_Pettay, Laszlo_Gombos, Doug_Schepers, Sangwhan_Moon,




      * [4]Topics
          1. [5]Tweak Agenda
          2. [6]Issue-1 Resolve touch area re. radius and angle
          3. [7]Raised Issues
          4. [8]Issue-2 What should happen when a touch is dragged off
             the screen
          5. [9]Issue-3 Click event target after DOM mutation during
          6. [10]Issue-4 Does preventDefault on touchmove cause a
             dragging motion to fire a click event?
          7. [11]Issue-5 What events fire if an alert is performed
             within a touch sequence?
          8. [12]Issue-6 Touch targets in frames
          9. [13]Issue-7 Targets for touch events: Elements or Nodes?
         10. [14]AOB
      * [15]Summary of Action Items

    <scribe>  ScribeNick: ArtB

    <scribe>  Scribe: Art

    Date: 22 February 2011

    <smaug_>  finally

Tweak Agenda

    AB: I posted a draft agenda yesterday (
    0066.html ). The main idea is to focus the call on specific issues.
    Any change requests?

      [16] http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0066.html

Issue-1 Resolve touch area re. radius and angle

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

      [17] http://www.w3.org/2010/webevents/track/issues/1
      [18] 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>  [19]http://www.w3.org/TR/InkML/

      [19] http://www.w3.org/TR/InkML/

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

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

      [20] 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

    <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

    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

    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>  [22]http://www.w3.org/TR/css3-values/#angles

      [22] 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

    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>  [
    [23]http://www.w3.org/TR/SVG/types.html#InterfaceSVGAngle ]

      [23] http://www.w3.org/TR/SVG/types.html#InterfaceSVGAngle

    <scribe>  ACTION: olli investiage various angle-related work e.g.
    InkML, CSS, SVG, ... [recorded in

    <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

    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:

      [25] 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 (
    [26]http://www.w3.org/2010/webevents/track/issues/2 )

      [26] 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
    ... 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

    <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 (
    [28]http://www.w3.org/2010/webevents/track/issues/3 )
    ... any comments?

      [28] http://www.w3.org/2010/webevents/track/issues/3

    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

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

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

      [29] 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

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

      [30] 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
    ... 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 (
    [31]http://www.w3.org/2010/webevents/track/issues/6 )
    ... Andrew asks "How do touch events propagate when they begin on an

      [31] http://www.w3.org/2010/webevents/track/issues/6

    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>  [
    [32]https://developer.mozilla.org/en/DOM/element.setCapture ]

      [32] 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
    ... for now leave it Raised

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

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

      [33] http://www.w3.org/2010/webevents/track/issues/7

    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
    ... I can put text in the ED and then ask people if they have any

    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

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

    <mbrubeck>  interesting...

      [35] http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/events/EventTarget.html

    <scribe>  ACTION: barstow Issue-7 to open [recorded in

    <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


    <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
    ... perhaps 1-2 weeks after we resume calls, we will be in a
    position to talk about a First Public WD
    ... meeting adjourned

Summary of Action Items

    [NEW] ACTION: barstow Issue-7 to open [recorded in
    [NEW] ACTION: brubeck to address Issue-7 [recorded in
    [NEW] ACTION: doug follow up with the canonical guys re copyrights
    [recorded in
    [NEW] ACTION: moon do some investigation for Issue-2 [recorded in
    [NEW] ACTION: olli investiage various angle-related work e.g. InkML,
    CSS, SVG, ... [recorded in

    [End of minutes]
Received on Tuesday, 22 February 2011 17:17:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:53 UTC