<garykac> Kacmarcik

Today we will be reviewing the issue noted in the latest editors draft:

https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

<garykac> Going through the ED and looking for "issue ": https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

ISSUE 2: normative order for events

How interoperable is the listed order?

garykac: Not sure. Need to verify
... bug mentions that order is different from Opera/Chrome+Safari/IE are all different

We should re-evaluate the order in recent versions of IE/Chrome/Firefox.

Moving to the third issue: what else is needed for InputEvent type

scribe: I suspect that we could live with the current definition. We should propose this for D3E to the list and move on.

<masayuki> It depends on what's the purpose of beforeinput.

Next Issue (4): Relation to editing spec.

me Masayuki are you on the call?

<kochi_home> hello

<masayuki> No, I just on IRC.

<garykac> We're going through the ED: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

<garykac> We're looking at Issue #4

<kochi_home> garykac: thanks

We think that for issue4, we would leave this burden up to the editing spec itself.

<garykac> sgtm

Issue 5

<masayuki> beforeinput has a default action at least modifying the DOM.

The tables look OK (for what they are)

garykac: Good point.

<scribe> Scribe: Travis

<garykac> For issue 5, I don't think we need to add Document to the list

<scribe> ScribeNick: Travis

<garykac> masayuki: Yes, I'll add that.

<kochi_home> ah, earthquake hits here...

!!

now on issue 6

<garykac> DOM_LOCATION _MOBILE and _JOYSTICK

<masayuki> I agree with that they are not needed.

<masayuki> If the location is unknown, to use _STANDARD?

<garykac> I don't think that '-1' as a value is useful. I think _STANDARD is a good enough default

<garykac> masayuki: yes

OK, Issue 7

NumLock key location

Spec was ambiguous, but implementations now agree.

We will update the spec.

<garykac> We're going to update the spec to match the implementations:

now issue 8-

locale

<masayuki> NumLock key may be placed on standard position like notebook PC.

<garykac> IF we move the locale into UIEvents, then we'll still have some implementations out there (at least IE)

<garykac> It would be nice to clarify what exactly should be in locale, and that's more than we probably want to do for DOM3

Needs to be more clearly specified--we agree to move to UI Events spec for additional clarification

<garykac> I'll move locale into UIEVents

<kochi_home> sounds good

now issue 9: when compositionupdate is fired

<masayuki> Sounds good. It's too complicated.

The spec now defines this, we should review it.

<garykac> For issue #9, I updated the spec to specify when the event should fire. Please review the text and let me know if you have comments.

<kochi_home> so do we agree compositionupdate should occur before DOM is updated?

<kochi_home> (the earthquake was M6.9...)

garykac: will add more detail to the key events during composition (regarding synthetic key insertion)

<kochi_home> masayuki: issue 12

<kochi_home> masayuki: do you think the order of composition events look good to you?

Now on issue 11.

<masayuki> let me check...

<garykac> For issue 11: Should compositionend still fire when compositionstart is canceled?

<garykac> I don't have a preference

<garykac> Is there a reason to fire it (or a reason to not fire it)?

IE should have an observable behavior (as it's cancellable)

Spec currently says to fire the compositionend event even after cancelling start.

<garykac> I wrote the spec to always fire the compositionend. We can leave it that way unless there's a reason to change it.

kochi_home: preference to fire the composition end event as speced.

<kochi_home> issue 12

now on issue12- DOM order of composition update

<garykac> The draft is written to say: beforeinput + compositionevent + DOM-update + input

issue 12's text seems to match my expectations

on issue 13

<garykac> For issue #13, I added an example. Are there any other examples that we should include in the spec?

(modifier key combos that we may have missed)

<masayuki> I like compositionupdate + beforeinput better.

<masayuki> Ctrl+Shift key is pressed, the key value becomes uppercase?

<garykac> We have the uppercase example with 'Q'

<kochi_home> masayuki: are you on the call?

<masayuki> kochi_home: no.

masayuki: On CU + BI better, is this because you never expect compositionupdate to be cancelled?

<garykac> Ah You'd like a control + shift example added?

<kochi_home> masayuki: ah, ok.

<masayuki> garykac: yes, for clearer spec.

<garykac> masayuki: ok. I'll add it.

<masayuki> garykac: Thanks, then, I'll work on implementing .key value for printable keys on Gecko.

<masayuki> And I'll post some feedback.

masayuki: any rationale for your opinion earlier on compositionupdate before beforeinput?

<masayuki> Travis: compositionupdate is a notification of native IME change, and beforeinput is a notification of to change the DOM. So, I feel compositionupdate kicks beforeinput is natural order.

<garykac> ok. I'll update the draft to be cu + bi + DOM + input

I agree with masayuki's preference.

On issue14 - maxlength requirement

<garykac> Perhaps 30 (or 31) would be better.

A limit seems reasonable.

<masayuki> maxlength limitation is applied for untrusted events?

I wouldn't think so.

<masayuki> Then, browser should have non-fixed string buffer in KeyboardEvent?

<garykac> Ok. Then we won't specify a limit.

I think it might be better without specifying a limit

(Especially one that is UA enforced)

<garykac> For issue #15, I'll need to investigate and give more info before we can talk about that.

<masayuki> SGTM, but it should be allowed to cut keyname for security.

<masayuki> garykac: on Linux, Super and Hyper is usually mapped to Win-logo key. However, Meta key is mapped to another key (e.g., shift + alt)

Issue 16 - use of ' ' or 'Spacebar'

<garykac> To test: https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html

<garykac> (that last URL was for Travis)

<masayuki> Windows and Mac have space key's keycode. However, Linux doesn't have it.

<masayuki> So, Linux needs complicated code for setting "Spacebar".

I'm OK with making spacebar's key value ' ' (not special)

<masayuki> Travis: I agree with it.

IE will need to change our implementation to match, but we'll have to change other stuff too :-)

<garykac> That would probably be the most consistent.

<garykac> I'll update the draft with our comments and add any new issues.

We got through issues 1 - 16 today.

garykac: will make spec updates based on today's call.

<garykac> Once we clear out all the issues, we'll be able to send the draft our more broadly.

<masayuki> garykac: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=21118#c3 for issue 17 ;-)

Next teleconference?

Should we meet in two weeks?

<garykac> 2 weeks from now?

<masayuki> it's okay for me.

<garykac> kochi: when is your next earthquake planned?

<garykac> There's a button to file bugs for any issues that people find.

<kochi_home> haha

OK. Next call is on Sept. 17

<garykac> sounds good,

<garykac> g'bye

<masayuki> see you.

rssagent, please publish 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: Travis, garykac, kochi_home
Present: Travis garykac kochi_home Travis_Leithead Gary_Kac

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: 04 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/04-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