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> 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]
> Sent: Wednesday, April 16, 2014 4:32 AM
> To: "Gary Kačmarčík (Кошмарчик)"; Travis Leithead
> Cc: wez@google.com; olli@pettay.fi; masayuki@d-toybox.com;
> kochi@google.com; www-dom@w3.org; 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
>