- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 16 Apr 2014 07:31:52 -0400
- To: "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>, Travis Leithead <travis.leithead@microsoft.com>
- CC: "wez@google.com" <wez@google.com>, "olli@pettay.fi" <olli@pettay.fi>, "masayuki@d-toybox.com" <masayuki@d-toybox.com>, "kochi@google.com" <kochi@google.com>, "www-dom@w3.org" <www-dom@w3.org>, "hsteen@mozilla.com" <hsteen@mozilla.com>
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
Received on Wednesday, 16 April 2014 11:34:19 UTC