See also: IRC log
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> 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
garykac: Looking at the minutes...
<garykac> Link to minutes: 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.
<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.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/big/Bug/ Found Scribe: travil Found ScribeNick: Travis Default Present: [Microsoft], +1.425.893.aaaa, +1.650.214.aabb Present: [Microsoft] +1.425.893.aaaa +1.650.214.aabb Travis_Leithead Gary kochi Got date from IRC log name: 15 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/15-webapps-minutes.html People with action items:[End of scribe.perl diagnostic output]