RRSAgent: this meeting spans midnight

<scribe> scribe: Travis

<scribe> scribeNick: Travis

waiting for others to join...

<masayuki> Travis: Hello.

Hi! Glad you could make it!

We've been making some progress on the bugs this past week.

Regarding bug 24044: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24044

I think the solution is to add the key value "DeadKey" correct?

<masayuki> A dead key process causes a set of composition events. So, web apps can get the inputting value of dead key sequence even if .key value is "DeadKey".

Right. Through the "data" value of the compositionevent objects.

<masayuki> Therefore, I think that "DeadKey" is simple solution for the issue.

Me too.

<masayuki> It's hard to define a mapping table for combining characters <-> non-combining character...

I'm looking at the key events tables now, to try and find where to slot in this new value...

Welcome gary!

<masayuki> Hi, gary.

<garykac> We can start with https://www.w3.org/Bugs/Public/show_bug.cgi?id=25338

<garykac> Clear vs. NumLock

<garykac> I think that Clear is better because NumLock implies a locking state for the key.

<garykac> I don't think that this causes problems since the Mac has no NumLock key

<masayuki> garykac: I agree, but they are same physical key at least with USB HID spec.

<garykac> USB spec has both Keypad NumLock/Clear (53) and Keypad Clear (D8)

<garykac> So we could go either way.

Looks like this on my current keyboard: http://www.bing.com/images/search?q=microsoft+sculpt+number+pad&FORM=HDRSC2#view=detail&id=F9469927A0E2504497E3C941499BD5C903520074&selectedIndex=22

<masayuki> garykac: Yeah. I confirmed that the clear key on Mac keyboard is NumLock key, not the Keypad Clear.

If Clear == NumLock, what codes should my keyboard report for these?

<garykac> The Clear key on the Mac reports itself using the same code as Windows NumLock

<garykac> We still need to keep the NumpadClear around (for the keypad that Travis just posted).

<garykac> But if it makes life easier to have the Mac Clear key use the same |code| value as Numpad, then that's fine with me

<garykac> I've updated the bug to note that I'll change it so Mac Clear = NumLock. I'll have to add a comment explaining why that is the case.

<masayuki> garykac: Thanks. If web apps need to distinguith the behavior, they should use .key which should return "Clear" only on Mac.

<garykac> sgtm

<garykac> Masayuki: I didn't get a chance to fix 23906 (accelKey), but I want to have that written up for you to review by next week.

<masayuki> garykac: no problem.

I just looked over bug 25477, and assigned to myself--pretty trivial update to the KeyboardEvent.init* method.

<masayuki> I backed out the KeyboardEvent.initKeyboardEvent() from Firefox 31 (Nightly).

<masayuki> I.e., we decided that we'd never support it.

I have no problem with that :)

Now looking at: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23913

<masayuki> Yeah, web apps should use event constructor on IE and Firefox...

<garykac> For 23913 (beforeinput firing), it sounds like we need to add a note that beforeinput may not be cancelable when it is unsafe (or if the IME does not permit it).

<masayuki> sgtm

<masayuki> If so, unsafe beforeinput's preventDefault() just change defaultPrevented attribute? or not change the value?

<masayuki> mousemove's preventDefault() changes only defaultPrevented value. So, I think it's no problem, it changes only defaultPrevented value.

What does "unsafe" mean--I'm not sure...

Ah, comment 16..

<masayuki> For example, Firefox thinks during setting .value is unsafe.

<garykac> It would be nice to define "unsafe" situations in the spec, if possible.

<garykac> Re: beforeinput preventDefault behaving the same as mousemove preventDefault. sgtm

<masayuki> garykac: Yeah, but I'm not sure exacely when Firefox thinks it's unsafe. And it needs to refer a lot of other specs...

<garykac> Ugh. ^_^

"unsafe" refers to dispatching a synchronous event during a pre-existing script stack, such as one changing the .value of an input?

<garykac> Then having an example unsafe scenario to use in the spec description would be good.

<garykac> Probably execCommand or .value would be a good example.

<masayuki> We should ask Smaug (Olli) about it...

<garykac> masayuki: do you talk to him frequently? or should we ping him on the bug?

<masayuki> garykac: I'll email him about it and request to write comment into the bug.

<garykac> masayuki: thanks!

<garykac> Travis make a comment drawing parallels between beforeinput and mutation events...

(Gary and I discuss execCommand a bit)

<garykac> masayuki: if beforeinput doesn't fire for modification made by scripts or execCommand, does that cover all the problem cases?

<masayuki> garykac: I guess so, but I'm not sure.

<garykac> so user actions (including cut/paste) always result in beforeinput/input, but scripted dom modifications will not generate beforeinput. (Should 'input' not fire as well in this case?)

<masayuki> input should be fired for compatibility with current browsers.

<garykac> Ah. good point. so 'input' sticks around in that case.

<garykac> Does 'input' fire for script events, or only for execCommand?

<garykac> masayuki: ^^ (question about FF)

When I tested, input did not fire for regular script modifications, but I didn't check execCommand.

<garykac> I'm fine suppresses 'input' in those cases as well -- unless we need to keep it around to match current behavior.

<masayuki> IIRC, input event is fired for all changes. However, it's fired immediately after it becomes safe if the change occurs during unsafe.

<garykac> The alternative to not firing beforeinput in those cases is to explicitly state that the event is not cancelable in those cases. Then the 'beforeinput' event could be fired asynchronously and not cause problems.

(I think we've all learned a lot today--this is great.)

<garykac> It's the same amount of work to spec: (1) don't fire these events in these situations vs. (2) these events are not cancelable in these situations

My preference, is not to have "magical" cancelability, but to simply not dispatch it under certain conditions.

<garykac> We already have 'variable cancelability' with beforeinput during composition.

<garykac> so, beforeinput is cancelable (unless it isn't) :-(

<garykac> Since beforeinput is cancelable primarily to support being a replacement for 'keypress', we also could simply state that it is only cancelable for key events. I don't know if that's OK or not.

<garykac> (for user generated key events)

I think it has more utility than that.

<garykac> Probably. I just wanted to throw that out there.

Perhaps the goal should be to have beforeinput and input pairs (always). And when it's not safe to make beforeinput cancelable, then it becomes non-cancelable.

<garykac> I like having beforeinput and input always occurring in pairs. I'm perfectly happy with it being non-cancelable to avoid problems.

(non-safe could be defined in terms of already being in a beforeinput event handler...

(or being in any script at all)

<garykac> The trick will be to write that into the spec in a clear and understandable way.

<garykac> Anyway, it's after 6pm.

Yep. Great progress today.

<garykac> 'Til next week then?

Yep, see you next week!

<masayuki> sgtm.

<garykac> thanks!

<masayuki> See you!

me because the conference is over :(

yeah.

RRSAgent: make logs public

RRSAgent: please make 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)

Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis

WARNING: No "Topic:" lines found.

Default Present: [Microsoft], +1.425.936.aaaa, garykac
Present: [Microsoft] +1.425.936.aaaa garykac Travis

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: 30 Apr 2014
Guessing minutes URL: http://www.w3.org/2014/04/30-webapps-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report