[D3E] minutes from 2 September 2014 call

The minutes from the September 2 D3E call are in the following (and 
copied below):

<http://www.w3.org/2014/09/02-webapps-minutes.html>

-AB


    [1]W3C

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

                                - DRAFT -

                             SV_MEETING_TITLE

03 Sep 2014

    See also: [2]IRC log

       [2] http://www.w3.org/2014/09/03-webapps-irc

Attendees

    Present
           Travis, masayuki, garykac

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Travis

Contents

      * [3]Topics
          1. [4]Touch/Mouse soup on the web
      * [5]Summary of Action Items
      __________________________________________________________

    <scribe> Scribe: Travis

Touch/Mouse soup on the web

    garykac: Sites basically say, if touch, use touch (don't use
    mouse). If mouse, don't use touch
    ... breaks a lot of sites.
    ... There was a proposal to extend mouse with some touch thing.
    ... Seems related to input event's "who fired you"?
    ... adding a boolean to input event for similar reasons could
    be a solution.

    <garykac> For context:
    [6]http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0100.
    html

       [6] http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0100.html

    (If things are a little scattered, it's because we haven't been
    at this for a few weeks now... :-)

    <garykac> For more context:

    <garykac> We had a request recently to include the
    KeyboardEvent info in the input events.

    <garykac> The user stated that they wanted the key event info
    available in the input event so that they could write a single
    handler, but the real problem was that they couldn't handle
    both events (key and input) because they would end up
    double-handling all the key events.

    <garykac> The specific example given was distinguishing between
    input events from key events vs. cut/copy/paste from context
    menu.

    <garykac> We could add 'isDerivedFromTouchEvent' and
    'isDerivedFromKeyEvent' boolean properties to handle these
    cases.

    <garykac> The context link I gave earlier was about
    distinguishing between 'real' mouse events and touch-generated
    mouse events, but the problem is very similar to our case.

    <garykac> (edit: I said 'isDerivedFromTouchEvent' above but I
    meant something like 'isDerivedFromMenuEvent')

    In general, it looks like there is a problem of not having
    enough context in a generic 'input' (or even beforeinput)
    event.

    <garykac> And actually Rick's proposal uses
    'derivedFromXxxEvent' -- whatever we choose, we should be
    consistent with the naming.

    It seems that authors want to simplify and use only one event
    to handle all the types of input modalities from various
    sources. Naturally, having the right context will be important.

    <masayuki> I think that the mouse event case is useful but I
    have no idea why it's useful for input event for distinguishing
    key vs. menu because just handling input event is enough. This
    is different from mouse vs. touch case.

    <masayuki> And "menu" is too specific...

    <garykac> It's not exactly the same, but the motivation was
    related: not wanting to double-handle events.

    <garykac> I'm not convinced it's important to resolve this, but
    I wanted to bring it up.

    <masayuki> The mosue events derived from touch device are fired
    for emulation. So, it could be just |MouseEvent.isEmlated|. And
    also WheelEvent too?

    Gary and I are discussing what one bug I could focus on fixing
    this week; the "define when it's safe to fire beforeinput" is
    the one we've selected.

    <garykac> We also need to start thinking about tests and
    testing since that will inform the spec. We want the spec to
    document the order in which events fire (as much as we can).

    <garykac> WRT 26611 (adding Zoom event), I think that we'll
    need to punt that into UI Events.

    <garykac> I like it, but there are a number of small issues
    that will need to be resolved that will distract us from
    finishing the core of DOM3Events.

    <masayuki> garykac: I agree.

    I have no specific agenda for anything else to discuss as a
    group. Is there anything else (masayuki) that we should spend
    our time on today?

    Going once?

    <garykac> Meet again in 2 weeks?

    <garykac> At that time, we should go through the bugs and
    review our status.

    <masayuki> No. But let me tell about that I'm wating bug 24739,
    bug 26141 and bug 26218 for updating our D3E implementation.

    Works for me; should give me some time to address that D3E bug.

    <garykac> OK. We'll look at those first thing next time. I'll
    try to look them over between now and then.

    <garykac> Thanks!

    See you all in two weeks!

    <masayuki> See you!

Summary of Action Items

    [End of minutes]

Received on Wednesday, 3 September 2014 11:10:52 UTC