See also: IRC log
RRSAgent: this meeting spans midnight
Zakim: this is Dom3
<scribe> scribe: Travis
<masayuki> Hell.
<scribe> scribeNick: Travis
<masayuki> Hello.
garykac: Quite a few new bugs opened recently
Travis: Yep, I've tried to look over a few, but haven't gotten very far.
<garykac> WE should probably go over the new bugs first
<garykac> Let's make sure that they are all assigned.
Looking at: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23910
masayuki: proposed a relatively simple solution which I liked.
<masayuki> Travis: yeah, but I forgot the case with dead key...
<masayuki> Travis: I checked briefly now. The examples look ok to me.
Travis: (summarizes the bug
history)
... ending with masayuki's comment.
garykac: So, do we have to address this now, or can we punt?
<masayuki> Travis: Er, the keyup's key values are odd. After compositionend, the keyup's .key value should not be IMEKey.
<masayuki> Travis: and also keyup immediately after compositionstart should be IMEKey, I think.
garykac: If we change to this proposal, then this will break firefox. Is firefox OK with this?
Travis: Also, this is the corner case where the key events are not being suppressed.
<garykac> I'm not sure what the advantage is of sending IMEKey during composition - they keyup/down events don't seem useful at that point. We recommend suppressing these events why not just require suppressing these events rather than saying that you may generate (useless) IMEKey events?
travis: masayuki: I wasn't sure
if I should always bookend the key values for
consistency--though I found in later examples in the spec that
this is not a requirement :-)
... so you are correct
<garykac> To paraphrase: Right now we recommend suppressing keyup/keydown, but we allow it.
<garykac> Why bother allowing it if the events are only going to contain IMEKey?
I recommend, that we continue this discussion in the bug :-)
(So that we can move on...)
<garykac> sgtm
<masayuki> garykac: D3E defines that keydown and keyup events should be fired even during composition. Then, the .key value becomes problem with Japanese IME in Kana input mode and Chinese IME.
Travis: I thought it stated that they should be supressed (in the latest editor's draft)
<garykac> Section 5.2.7.5 : "During the composition session, all keydown and keyup events should be suppressed."
Where "should" is a strong requirement per the RFC
In https://www.w3.org/Bugs/Public/show_bug.cgi?id=24797
I think I have a clear direction, though WebIDL may have a problem...
And in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25359
<garykac> We know that they can't be suppressed in all cases, this is why we allow them to come through. If they can't be suppressed, why would we be able to change the fields to IMEKey? It seems at that point that we would be able to suppress the event.
I think I just need to add the annotations.
<masayuki> garykac: Oh, did you changed? Or I misunderstood?
<garykac> I don't think that's a change - although the section got reformatted when isComposing was added.
<masayuki> keydown and keyup should not be fired, the examples should clearify the keydown and keyup in the table during composition optional.
Yes.
(In the bug, I put in such a note in my table reproductions)
<masayuki> And I think that it should be defined in the section of keydown and keyup too.
<garykac> masayuki: yes, we should add that to keyup/keydown.
<garykac> Currently in the spec, we have a Note by the composition example: "Note: The keydown and keyup events shown in these examples would normally be suppressed during the composition session. They are included in these examples to make the user actions (pressing and releasing keys) more apparent."
<garykac> But we can make that more apparent by adding a comment in the table for each event.
Travis: masayuki: Given all this, the "DeadKey" still makes sense, but perhaps the "IMEKey" proposal does not?
<masayuki> Okay, but IE, Chrome and Safari are okay? IIRC, they dispatch keydown/keyup events even during composition.
<masayuki> Travis: Yeah, I agree.
Yes, from the IE perspective, we've wanted the key events supressed for some time :-)
(It was feedback from our EA language team)
garykac had a bug reactivated: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24739
<masayuki> Travis: I worry about the compatibility with older browsers of them.
(Yes, we'll have a plan for dealing with compat impact, I'm sure.)
The outcome of this bug is that a Sun keyboard would have a bunch of unique key .code values?
<garykac> For 24739, I have to double-check - it looks like I got confused between key and code values. I don't think that it's a problem to add 'code' values for these keys.
<masayuki> When I was working on Linux keyboard bugs, some Sun keyboard users reported their specific bugs. Therefore, I guess they may need independent .code value when they implement their own system.
<garykac> masayuki: BTW, outside of the alphanum keys, the other keys can be in different locations on different keyboards and share the same 'code'. E.g., a lot of PC laptop keyboard more around these keys.
<garykac> So it's not a problem for some of the 'code' values to be shared.
<masayuki> garykac: sounds odd to me... even though its rare case...
<garykac> Also, for example, the fact that low level codes for Stop and BrowserStop are the same rather than having 2 separate codes.
Alright. Now, we switch to look at the "new" bugs.
<garykac> masayuki: BTW, for 25373, do you have a preference for NoConvert vs. NonConvert? They should be consistent.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25373
-> assigned
(looked ok)
Now: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25210
<masayuki> garykac: Only Windows uses "NonConvert" for its virtual keycode name. Others use "Muhenkan". So, I like "NonConvert" better.
<masayuki> I meant no platfrom uses "NoConvert".
-> Assigned, change looks reasonable.
<garykac> OK. "NonConvert" is it then. For both key and code.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23167
garykac: This is placeholder for all the mobile keys.
<garykac> Arthur suggested adding a tag to bugs that are specific to the |key| and/or |code| tables.
<garykac> I was thinking something like [d3e-code] and [d3e-key] prefix for the bug title.
I like that.
<masayuki> Agree.
Looking at: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25368
garykac: Yep, and since travis filed it, he can fix it.
<garykac> Moving on to 25405....
<garykac> "Input event types"...
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25405
Looks like something I should be able to address...
(Took the bug)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25408
Link integrity--and some cleanup. Gary will take.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25366
We are wondering why this is cancellable too. :)
garykac: No default action. Yeah!
<garykac> :wondering why mousemove is now cancelable? What does that even mean.... weird...
<masayuki> Travis: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17626
Awesome.
<garykac> masayuki: wow! you filed that bug 2 years ago.
(So, it's still not cancelable in Firefox :-)
<masayuki> I forgot to fix it on Firefox, I can do it soon, though.
<garykac> ^_^
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23906
garykac: The solution for windows key madness. I just need to write it up and have masayuki review.
I assigned the bug.
<garykac> When I write it up, I'll assign the bug to masayuki so that he can review it.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25365
I assigned that one to me. A goof from an earlier draft that wasn't updated.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25363
Another good consistency find.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25358
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23908
That last one is clearly on Gary...
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23913
Long history on this one...
Gary took it.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24044
Gary took this.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25357
Travis will work on this.
<garykac> 25363 seems related to that one as well.
<garykac> All the bugs are assigned !
<garykac> We hope to get through most (if not all) of them by next week.
Gary and I will work on these and hopefully have some great progress to report next week.
We shall meet again next Tuesday?
<garykac> So... next Tuesday. Same bat time. Same bat channel.
<garykac> sgtm
<garykac> Thanks everyone. See you next week.
<masayuki> No problem.
<masayuki> Thanks and see you.
<garykac> bye
RRSAgent: make logs public
RRSAgent: please generate 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/surpressed/supressed/ Found Scribe: Travis Inferring ScribeNick: Travis Found ScribeNick: Travis Present: Travis Gary Masayuki WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 23 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/23-webapps-minutes.html People with action items:[End of scribe.perl diagnostic output]