Minutes: DOM3 Events Telcon, 13 October 2010

The minutes for the DOM3 Events Telcon of 13 October 2010 can be found here:

  http://www.w3.org/2010/10/13-webapps-minutes.html

Or as text below:

              Web Applications Working Group Teleconference

13 Oct 2010

    See also: [2]IRC log

       [2] http://www.w3.org/2010/10/13-webapps-irc

Attendees

    Present
           Shepazu, Janina_Sajka, Gregory_Rosmaita, Michael_Cooper,
           Rich, Joseph_Scheuhammer, Olli_Pettay, Art_Barstow, Travis,
           tonychang, MikeSmith

    Regrets
    Chair
           shepazu

    Scribe
           jrossi

Contents

      * [3]Topics
          1. [4]MouseEvent.getCoordsAt
          2. [5]Missing .key values
      * [6]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 13 October 2010

    <Travis> Having a bit of trouble calling in... hang tight.

    <Travis> OK.

    <oedipus> monday's discussion on DI and DOM3 at PF call:
    [7]http://www.w3.org/2010/10/11-pf-minutes.html

       [7] http://www.w3.org/2010/10/11-pf-minutes.html

    <smaug_> I think

    <tonychang> I'm 1.650.253.aaaa

    <tonychang> Zakim 1.650.253.aaaa is tonychang

    <tonychang> err

    <tonychang> Zakim +1.650.253.aaaa is tonychang

    <MikeSmith> tonychang, you need a comma

    <MikeSmith> . Zakim,

    <tonychang> MikeSmith: thanks

    <MikeSmith> cheers

    <shepazu> scribeNick: Jacob

    <MikeSmith> "First Call" instead of "Last Call"…

    <inserted> scribe: jrossi

    shepazu: This is the first Last Call....intended to be feature
    complete last call, not the document last call.
    ... Apple proposal for UI events for ARIA.

    <shepazu>
    [8]http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/U
    serInterfaceIndependence.html

       [8] 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

    shepazu: The UIRequestEvent, first interface (Sect. 2), the const
    list is not intended to be a set of constants that come up with that
    event. Rather, it's a set of events that use that interface. For ex,
    MouseEvent hase mousemove/mousedown/etc.
    ... I think this would be useful. Love to see it in D3E. So we could
    see an arrangment such that instead of a keyboard evt with key ==
    Undo, we could see an actual Undo Event.
    ... the undo evt could happen before the keyboard event for the undo
    key

    Travis: Small concern: a series of high level semantic events (the
    fire as a result of intended meaning by end user, "the result of a
    particular default action"). Nowhere in D3E (w/ exception of click)
    do we have the concept of a meta-event. My concern is they dont
    really jive with the rest of the events which are currently spec'd
    in our draft (which are more low-level events tied to the likes of
    hardware actions, etc).
    ... Clearly value in these events. I just don't see that we just try
    to graft those into the spec with our current focus.

    shepazu: Planning on making a new WG (Touch Interface WG). The
    intent there is to manage touch interface, but also some higher
    level events too. Possibly renaming WG to something like Touch
    Interface and Abstract Events WG
    ... So that is another possible venue for similar sorts of things.
    ... related proposal by Google, around textInput event to change it
    to beforeInput and abstract it out to capture all sorts of changes
    to the document (undo, redo, etc). Not necessarily in semantic
    terms, but functionally.

    <smaug_> there is some background noise

    <anne> HTML5 defines undo/redo events

    richardschwerdtfe: Couple points: one thing that I wish we had
    better tools on mobile devices, but this is the one thing that's
    really prohibiting us from producing a good mobile device. Keyboards
    on mobile dont always map correctly. Higher level events would allow
    for manipulating better and allow us to be more accesible. I wish I
    had some of the events earlier on.

    Travis: To add on to that, w/ D3E today to make your app accesible
    you have to write your code directly to the input devices you have
    available (keyboard, mouse) and on some platforms touch.

    tonychang: From Google, details on beforeInput. I think
    UIRequestEvent is fine and will meet a lot of the simliar needs of
    beforeInput.
    ... beforeInput was trying to be one evt you listen for that
    captures all possible inputs.
    ... downside of UIRequestEvent is that you have to subscribe to a
    bunch of events (Undo/Redo/etc) to get all input

    <shepazu> ?

    travis: I think we have to be realisitic. Any spec that tries to
    define semantic evts is going to be incomplete. We need figure out
    what the key events that capture the main scenarios we have are.

    shepazu: wishes this approach had been taken 15 yrs ago. My concern
    is that this will take up a really long time (min, several months)
    to come to agreement. I think that conversation needs to happen. I
    am concerned that it happens in the scope of D3E.
    ... I'd like to hear people's reaction to that. Excellent work,
    excellent ideas. We could have these higher events and we agree it
    would make it easier.
    ... But I think we could agree that the conversation won't be
    settled in the next month and a half.

    Travis: It's been 10 years in the making (D3E). Let's get these
    things done. But I am sensitive to the accesibility needs to have
    these completed.

    richardschwerdtfe: How would the module track for dom events work?

    <smaug_> jrossi: do you have microphone near keyboard?

    shepazu: It wouldn't be a D3E module. It would be some other spec
    that uses D3E. D3E underlies things like SVG, HTML5.

    yeah, muted the mic. better?

    <smaug_> better, thanks

    shepazu: It also goes into a few low level evts.

    <smaug_> er, no

    must be something else

    shepazu: Example, event propagation, contstruction of events,
    dispatching, etc. It's the architecture of events and a few
    particular events on top of that.
    ... This new events spec would not talk about the architecture that
    D3E lays as a framework. It would simply define a set of interfaces
    and events, the order in which they're fired, etc. So just the evts
    themselves and not the mechanisms.
    ... Logistically, we could start iterating on the spec to come to a
    conclusion while we're still working on D3E.
    ... Probably be ready for first public WD before the 2nd D3E last
    call.
    ... Key factor, unlike a lot of other specs, this has the interest
    of Google,Microsoft, other browser vendors.
    ... with that, things could happen very quickly.

    richardschwerdtfe: Seems like a reasonable approach.

    shepazu: Does anyone have a problem with that approach?

    richardschwerdtfe: In line with what you're thinking, we could
    actually use all the ARIA spec and make it applicable for mobile.

    shepazu: Don't understand...

    <oedipus> [9]http://www.w3.org/WAI/PF/aria-practices/

       [9] http://www.w3.org/WAI/PF/aria-practices/

    richardschwerdtfe: We could take the define the relation between
    device input events and application control with accessibility in
    mind.

    <oedipus> [10]http://www.w3.org/WAI/PF/aria/

      [10] http://www.w3.org/WAI/PF/aria/

    shepazu: Topic interests me. Would be interested in being one of the
    editors; but probably not the only one.
    ... I'm hearing general agreement that htis work is worthwhile.

    richardschwerdtfe: alignment with last call?

    shepazu: I think that's useful. Talk about this potential spec and
    have it's first public WD align with the real Last Call for D3E for
    gap analysis. Make sure D3E doesn't define something that hampers us
    latter.
    ... I would expect 1st public WD sometime in Jan.
    ... I think that's doable. Especially if we get Google and Apple
    togethre to talk about these things.

    <smaug_> background noise is getting even worse :(

    MichaelC: Which WG owns this?
    ... still a webapps thing? maybe somebody from PS? joint
    publication? How do we get all the right people at the table?

    shepazu: I think PF is needed. But also whoever else we need to have
    the right people here to find common ground.
    ... I'd be happy to technically join the PF WG.

    Rich: We're also going to use the D3E architecture as well, correct?

    shepazu: Yes, but most groups use D3E as a fundamental grounding for
    their events. That's just an assumption.
    ... Some groups don't use dom events, but we're trying to bring them
    into the fold to.

    MichaelC: I wouldn't want this to have the flavor of an accesibility
    only spec.

    <smaug_> to get more input from browser implementors, webapps wg
    should be actively involved

    shepazu: Wouldn't want to slow this down by making it go through a
    new charter revision.
    ... Wouldn't want to be in Touch WG because of IP issues.
    ... But I agree if it were best if it weren't seen simply as
    accesibility.

    richardschwerdtfe: In terms of PF charters, can we do this in PF?

    MichaelC: It's not chartered to do something like this. But we could
    charter this as an informal related thing. But we can deal with that
    offline.

    Resolution: We will deal with high level intentional events in a
    separate spec that builds on DOM3 Events.

    shepazu: Intend to do it in a timeframe that overlaps with the real
    last call of D3E.
    ... Probably need to have some email about scroll request and wheel
    events.

    <MikeSmith> getting Chris Fleizach on a telcon might be worthwhile
    too

    shepazu: with regards to beforeInput and this directio we're taking,
    does it make sense to you that we would look at this in a larger
    scope?

    tonychang: yes, this seems fine to me. The end goal is the same. How
    we get there....I don't have a strong preference.

    shepazu: Let's talk about graphics. mouse getCoordsAt()

MouseEvent.getCoordsAt

    Travis: when you transform an element, most properties are relative
    to viewport.

    shepazu: (doesn't agree)

    Travis: the ones that aren't are the ones we want to talk about.

    shepazu: (sees the light)

    Travis: The offset are relative to the coordinates of the element.
    So what how should those be affected by transforms?
    ... Why on MouseEvents instead of just doc?
    ... Unles mouse event provides some sort of info that isn't
    intrinsically available.

    <shepazu>
    [11]http://jwatt.org/svg/tmp/mouse-relative-positioning.svg

      [11] http://jwatt.org/svg/tmp/mouse-relative-positioning.svg

    jrossi: I don't think mouse events are the only place you deal with
    the issue of translating coordinates between different contexts (the
    viewport, transformed elements, etc)

    shepazu: Agreed. It's surprisingly difficult to do this in a way
    that's logical and makes sense. It's unintuitive even after much
    work on SVG.
    ... I code SVG by hand and yet I don't remember this.
    ... The key part is that you have to get clientX/clientY. Generally
    this comes from the mouse. But sometimes it's just some generic
    point.
    ... should have been screenX/screenY but...

    Travis: one example: getClientBoundRect

    jrossi: needs to be abstracted from SVG.

    shepazu: nothing SVG-specific, other than where concept of
    transforms originated. We can define in a way that you pass in a
    "point object" (regardless of type) or even the x and y and get back
    a point object.
    ... not taking in a point would actually be nice. Could be seen as a
    point contructor....pass in x/y and returns point object.

    Travis: write it out like an API.....please?

    <Travis> document.getElementById('transformedElement').transformedX;

    <Travis> document.getElementById('transformedElement').transformedY;

    <Travis> ??

    <smaug_> This all should perhaps go to
    [12]http://dev.w3.org/csswg/cssom-view/

      [12] http://dev.w3.org/csswg/cssom-view/

    <shepazu> Point DocumentInterface.getGlobalCoords(x, y);

    Point getCoordsAt(x,y,element)

    <Travis> Element.transformedClientX;

    Travis: data is local to the element, right? It's the element that's
    transformed that's relative to. Why not put it on element itself?

    jrossi: like on on Element, if you had elm you could just say
    elm.getCoordsAt(x,y)

    smaug_: seems quite natural to go in css-om

    <Travis> CSSOM-Views; seems like the right place to me too.

    shepazu: I can see that. Only concern, would like to see this
    defined and in browsers. IE9?

    Travis: tight timeline, can't commit, would need to discuss
    internally
    ... workaround is available

    shepazu: workaround is somewhat obtuse

    <MikeSmith> shepazu: ↑

    shepazu: would like to take a stab at defining this in D3E. Wouldn't
    mind marking as "at risk" and it could be taken out in Last Call and
    go in css-om?

    smaug_: Why do you want to have it in D3E?
    ... But what part goes in events? Doesn't make sense that D3E events
    is the place for this?

    jrossi: agrees

    shepazu: Put another way,...

    Travis: <sings>

    shepazu: <joins in>
    ... I think that putting it in D3E events might persuade MSFT to
    implement.

    Travis: probably can't justify putting it in already. Fundamentally
    seems wrong to ram in through D3E.

    <smaug_> jcraig: the ARIA part of the meeting started over an hour
    ago

    Travis: Our SVG folks are interested in this. Could work with Anna
    to put this in CSS-Om.

    shepazu: I'll recommend this goes in SVG/CSS transforms spec.

    Travis: could mention we debated it and felt that it wasn't an
    events-related issue and felt like it was better suited for Element

    shepazu: Feel like MouseEvent is missing this thing. Would like to
    put these as attributes on the MouseEvents rather than separate
    method.

    <MikeSmith> scribe: jrossi

    Travis: I think we're wise to push to another location so that the
    details could be more paid attention to.

    Resolution: We will suggest this lives in CSS-OM or CSS/SVG
    Transforms spec.

    shepazu: Wondering if we should take another shot at DOMActivate in
    this other events spec.

    Travis: Certainly valid. Once again would want to understand why
    click isn't dragged back in the mix.

    shepazu: Click doesn't do everything. If you just want to listen to
    an activation, click is cumbersome.

    Travis: but now we'll be firing more specific events, hopefully,
    with this new spec

    jrossi: yes, DOMActivate seemed too generic to me. More specific
    events with more meaning (in this new spec) will be more useful.

    <shepazu> [13]http://www.w3.org/2008/webapps/track/products/2

      [13] http://www.w3.org/2008/webapps/track/products/2

Missing .key values

    shepazu: Issues raised by Microsoft

    or not actually raised.....emailed to list...

    shepazu: happy to add back multiple, also think there's some remote
    control type things that could be added

    <shepazu> ISSUE-149?

    <trackbot> ISSUE-149 -- The multiply and other key values are
    missing -- raised

    <trackbot> [14]http://www.w3.org/2008/webapps/track/issues/149

      [14] http://www.w3.org/2008/webapps/track/issues/149

    Resolution: add "multiply" back. Need to discuss if add and plus are
    the same thing.

    <shepazu> trackbot: end telcon

Summary of Action Items

Received on Wednesday, 13 October 2010 18:43:57 UTC