RE: [DOM3Events] Minutes from 2014-Apr-15 call [Was: Debrief after WebApps F2F?]

I agree. However, the question was about creating a component to track bugs for these documents. Should we have one or two components? I think just one is probably good if we need it at all…

From: Gary Kačmarčík (Кошмарчик) [mailto:garykac@google.com]
Sent: Thursday, April 17, 2014 12:56 PM
To: Travis Leithead
Cc: Arthur Barstow; wez@google.com; olli@pettay.fi; masayuki@d-toybox.com; kochi@google.com; www-dom@w3.org; hsteen@mozilla.com
Subject: Re: [DOM3Events] Minutes from 2014-Apr-15 call [Was: Debrief after WebApps F2F?]

I strongly prefer two separate documents because the key and code values are sometimes similar and potentially confusable. This can (will) be a problem if (when) people search the document for particular values - they can easily find themselves looking at values from the "other" part of the document and not realize it.

By having 2 separate documents we eliminate that source of confusion. It also make it easier to (unambiguously) point people to a document that contains the valid key (or code) values.

Having two documents is a small amount of extra work for us, but it makes the resulting documents much more useful.


On Thu, Apr 17, 2014 at 11:04 AM, Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>> wrote:
Gary, you had two documents (one for key values, one for codes). Should we have just one new component for both of these specs?

-----Original Message-----
From: Arthur Barstow [mailto:art.barstow@nokia.com<mailto:art.barstow@nokia.com>]
Sent: Wednesday, April 16, 2014 4:32 AM
To: "Gary Kačmarčík (Кошмарчик)"; Travis Leithead
Cc: wez@google.com<mailto:wez@google.com>; olli@pettay.fi<mailto:olli@pettay.fi>; masayuki@d-toybox.com<mailto:masayuki@d-toybox.com>; kochi@google.com<mailto:kochi@google.com>; www-dom@w3.org<mailto:www-dom@w3.org>; hsteen@mozilla.com<mailto:hsteen@mozilla.com>
Subject: [DOM3Events] Minutes from 2014-Apr-15 call [Was: Debrief after WebApps F2F?]

Hi All,

Here are the minutes from the April 15 call (and copied below):

   <http://www.w3.org/2014/04/15-webapps-minutes.html>

Since it now appears the PoR is to split up the spec, perhaps it would be helpful to create new Bugzilla components for the two new specs.
WDYT? If you agree, please give me the names of the new components and I'll ask Mike Smith to create them.

Re the Pointer Events spec and the UIEvents vs. D3E reference question, I'll take the action to followup with that group.

-Thanks, AB

    [1]W3C

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


                                - DRAFT -

                            DOM 3 Events Call

15 Apr 2014

    See also: [2]IRC log

       [2] http://www.w3.org/2014/04/15-webapps-irc


Attendees

    Present
           [Microsoft], +1.425.893.aaaa, +1.650.214.aabb,
           Travis_Leithead, Gary, kochi

    Regrets
    Chair
           Travis

    Scribe
           travil

Contents

      * [3]Topics
          1. [4]DOM3 Events at the F2F
          2. [5]Recent document updates.
      * [6]Summary of Action Items
      __________________________________________________________

    RRSAgent: this meeting spans midnight

    <masayuki> Will start the meeting soon, right? You wrote wrong
    time of Tokyo due to summer time.

    <masayuki> I realized it now :-)

    Ooops.

    Zakim: Microsoft is Travis

    Zakim: [Microsoft] is Travis

    Zakim: 1.425.89 is garykac

    <garykac>
    [7]https://docs.google.com/document/d/1mRTqY-2la5keSHhJUtEvSG3b

    rMe_W3KRlkLWFVbV9yM/edit?pli=1

       [7] https://docs.google.com/document/d/1mRTqY-2la5keSHhJUtEvSG3brMe_W3KRlkLWFVbV9yM/edit?pli=1


    <scribe> scribe: travil

    Zakim: 1.650.214 is kochi

    kochi: I was at the WebApps f2f and presented the IME api
    ... nothing much was discussed about DOM3, outside of what is
    in the minutes.

    garykac: I saw that, and wondered if there was any extra
    conversation.

    kochi: Gary, did you dial into the f2f meeing

    garykac: No, didn't know when to do so.

    <scribe> scribeNick: Travis

DOM3 Events at the F2F

    garykac: Looking at the minutes...

    <garykac> Link to minutes:
    [8]http://www.w3.org/2014/04/10-webapps-minutes.html


       [8] http://www.w3.org/2014/04/10-webapps-minutes.html


    <garykac> What is PointerEvent's dependency on UIEvents?

    garykac: notes say there is a dependency on UIEvents spec???

    <garykac> If it's |buttons|, I believe we have all that in D3E.

    Travis: I think this was for the 'buttons' change to support
    the value of -1 (where it was previously defined as an unsigned
    long
    ... I updated the spec for that.

    <garykac> We should confirm that and let them know they depend
    on D3E now.

    garykac: also note about plan to split the spec...

    <garykac> From the f2f, there was agreement to break out the
    |code| and |key| tables if that can speed up the spec.

    Travis: This was the WG acknowledging that anything to speed up
    the process of finishing the spec

    <garykac> All three docs (D3E, co]de-values and key-values)
    will live in the same Hg repository for now.

    Travis: It was suggested that a registry or wiki would do, but
    we think another rec-track doc is sufficient and only adds
    minor overhead.

Recent document updates.

    <garykac> The doc above has the latest status of the bugs

    <masayuki_> I think that it's better we can change the code/key
    table even if we found some new bugs in the table *after* D3E
    finished.

    garykac: masayuki_: I agreee

    <garykac> Exactly, that's why we want to do that - it'll make
    updating the tables a lot easier

    garykac: Now, noting that lots of old bugs in the doc are
    fixed!

    <garykac> At the bottom of the doc are the closed bugs. Please
    review them (later!) and make sure there's nothing overlooked
    when they were fixed.

    <garykac> Question: In 5.2.7.5 "Key Events During Composition".

    <masayuki_> Yeah, I'll review the closed bugs and I'll comment
    some bugs which ask some questions from garykac or Travis.

    <garykac> I'm wondering if we should change "SHOULD be
    suppressed" to "MAY be suppressed"?

    <masayuki_> I think so > "SHOULD" vs. "MAY".

    <masayuki_> "SHOULD" is good for "keypress".

    <garykac> Well, keypress is deprecated ^_^

    <garykac> In the doc, let's start at the bottom of the list
    (since those are the newer ones)

    <garykac> Bug 25359 - Use [Unforgeable] and [NewObject]
    annotations in D3E

    <garykac> I *think* this is straightforward, but I wonder if
    there are other new annotations that we should be using.

    <masayuki_> Yeah, but it's clearer for authors if we define
    keypress event's reference behavior.

    <garykac> Travis: are you familiar with these annotations

    Yes.

    <garykac> I can easily fix isTrusted and createEvent, but I
    want to make sure we update any other cases as well.

    <garykac> Travis suggests updating this bug to note that we
    need to compare D3E with D4 and make sure the IDL matches

    <garykac> (I just updated the bug to note that we need to
    compare with D4)

    <garykac> Bug 25358 - "Context info: UIEvent.view" sometimes
    only has defaultView

    <garykac> This requires that we double check and verify the
    correct values - I don't know offhand.

    <garykac> Should all of these allow 'null'?

    The view should always be a Window (abstractView) if the event
    is Trusted.

    scribe: Since these can be trusted/untrusted, the view
    attribute can always be null.

    <garykac> I've updated the bug to note that we'll be changing
    it to allow null.

    <garykac> 25357 - Target for event type is not complete

    <garykac> Bug 25210 - Targets for abort event is correct?

    <garykac> For 25357 - I updated the bug to note that we need to
    update the tables to be consistent.

    <garykac> For 25210, we need to make it consistent with what
    HTML5 says.

    <garykac> Bug 24797 - We've fixed this, so this is no longer a
    D3E issue. I'll be resolving (again) with a note that the
    Window vs. WindowProxy issue should be addressed in a more
    appropriate doc.

    <garykac> Bug 24044 - How do browsers decide combining
    character from non-combining character at computing .key value
    of dead key?

    <garykac> I need to think more about this, so we should move on
    to the next one.

    <garykac> Bug 23913 - beforeinput should be fired only when the
    DOM change is caused by direct input by keypress or composition

    <masayuki_> I think that using DeadKey is smart since authors
    can get input value with input/beforeinput/compositionupdate
    events.

    <garykac> Consensus (as far as I can tell) is that we shouldn't
    fire beforeinput/input for execCommand

    <garykac> We don't currently discuss execCommand anywhere in
    the D3E - I suppose that I can just add a note in the
    InputEvent section about this.

    <masayuki_> About bug 23913, I think that if browser thinks
    "dangerous" to dispatch beforeinput at some cases, browser
    shouldn't dispatch beforeinput. I.e., before should be defined
    with "MAY".

    <masayuki_> Then, even with execCommand, browsers might be able
    to dispatch beforeinput safely.

    <garykac> WE should define the dangerous cases if we can. Most
    of the time it is clearly not dangerous, so saying MAY doesn't
    seem right.

    <garykac> What other dangerous situations are there other than
    execCommand?>

    <masayuki_> I'm not familiar with "dangerous" cases... Olli or
    Boris of Mozilla might know about it...

    Script modifications to the value of an input element wouldn't
    trigger beforeinput, correct?

    I guess the idea that execCommand is a proxy for a user input,
    then that makes it dangerous.

    <masayuki_> Anyway, I need to implement beforeinput
    experimentaly, first...

    Real automation systems like WebDriver would still cause the
    event to fire though.

    We just want IME systems to also fire it.

    <garykac> I'm happy have a "when not to fire beforeinput/input"
    section that listing the situations when it's not appropriate.
    We could start with execCommand and add to it.

    I think that sounds good to address this concern.

    <garykac> I would hope that automation systems would fire these
    events (otherwise testing will be hard).

    <masayuki_> I strongly believe that "input" should be fired
    always since current browsers implement so.

    <masayuki_> I don't think that beforeinput and input should
    always be fired as a pair.

    <garykac> beforeinput and input are supposed to be fired as a
    pair - the DOM has already been updated by the time the input
    event it sent. beforeinput is the last change to look at the
    DOM before the update.

    <masayuki_> Anyway, it might be better to keep this discussion
    in bug 23913.

    <garykac> Yes, but the discussion died down and no one
    responded (>sniff<) to my call for comments.

    <garykac> But keeping the conversation in the bug sgtm

    <masayuki_> Yep, I'm sorry about that...

    <garykac> Is there anything else to discuss before we stop?

    <masayuki_> FYI: I'm implementing KeyboardEvent.code now.

    <masayuki_> FYI #2: I implemented KeyboardEvent.isComposing and
    InputEvent.isComposing.

    <garykac> BTW, masayuki, thank you for filing all those great
    bugs

    <masayuki_> Of course, on Firefox.

    <masayuki_> garykac: you're welcome.

    <garykac> OK. I think that we're done for today.

    <garykac> I'm hoping to close out more bugs for next time,

    <garykac> Should we meet next week? Same time?

    RRSAgent: please make the minutes

    <garykac> Travis says that next week sounds good.'

    RRSAgent: make minutes public

    RRSAgent: make logs public

    <masayuki_> I'm ok to meet next week.

Summary of Action Items

    [End of minutes]



On 4/15/14 11:20 AM, ext Gary Kačmarčík (Кошмарчик) wrote:
> sgtm
>
> Relevant part from the F2F 10 April 2014 minutes:
> http://www.w3.org/2014/04/10-webapps-minutes.html

>
>
> Art: if folks are interested in moving this spec forward, please step
> up as always ... DOM3 Events ... we don't have the editors around
> either ... will be a third LC ... 12 bugs ... some concerns since
> HTML5 has a normative ref for it ... and would make life easier if
> DOM3 Events was a REC ... since it's not going to happen anytime soon
> ... I've been pushing this soec to go back to LC
>
> Marcos: what's the dependency?
>
> Robin: it's about the event types
>
> Art: UIEvents is blocked on D3E
> ... Pointer Events depends on UIEvents ... Glenn expressed interest in
> moving forward D3E ... plan is to split out features that would
> prevent it to move forward
>
> Adrian: plan to split out key names/values
>
> Adrian: and proceed
> ... primary reason is that changing will happen to those anyway ...
> also want to review various mobile platforms and their keyboards