DOM 3 Events Call

15 Apr 2014

See also: IRC log


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


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 :-)


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

DOM3 Events at the F2F

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.

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 "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


<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]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-04-16 11:21:40 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]