garykac: Call the W3C Bridge instead of the info I sent you...

6177616200

masayuki: You alive?

<masayuki> Travis: Yes. Thank you for inviting me.

<scribe> Scribe: Travis

<scribe> ScribeNick: Travis

<real_wez> Hello all

<garykac> travis: start by creating an agenda

<garykac> travis: then we need to talk about timelines for action items

<garykac> start with spec update

spec update

<garykac> started with existing dom3 spec

garykac: ... was being edited by hand. Required tedius changes
... coverted to ReSpec
... (with no changes)
... Then changed to ReSpec IDL
... Fixed some typos
... JS expands out the table now.
... waiting for new repro to be ready
... then we can start adding/explaining existing stuff
... CVS repo is moving to Mercurial for ease/convenience
... masayuki found some errors where some things weren't labelled
... this will put us in a better position moving forward.
... Found 15/20 issues that still need to be filed in bugzilla.
... a couple are significant, I can talk about them here once we get through our other items.
... the ReSpec is sittting locally...
... should be only a few days till it's ready.

I'd like to just wait until the Repro is ready to check it in.

Anything else on this topic?

garykac: Should be it; waiting until spec is ready before filing the next round of issues.

Bugs!

https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---&list_id=10169

I see 27 bugs, plus the 15/20 that Gary will deposit soon

I'd like a call for discussion on any of these bugs?

masayuki: Do you have any you'd like to talk about?

<masayuki> Yeah, there are a lot of issues for naming .key values.

<masayuki> If browser venderos can name it originally, it will break compatibility between browsers in the future.

garykac: We might get into bikeshedding on those...
... are there any larger issues?

<masayuki> Is vender prefixed name better for not predefined key names?

<garykac> I would rather define them in the spec if at all possible.

wes: Direction we were thinking with not defined key names is to add them into the spec; vendor prefixes are dangerous because they persist.

<garykac> It's hard to remove vender prefix once the've been added to some implementations.

real_wez: One topic to split up the key table into sections.

<masayuki> I think that web apps can remove vender prefix before comparing the values, that is difference from CSS's vendor prefix.

real_wez: yes, garykac had some thoughts on how to do this...
... like color keys (red,blue,...) ect. seems reasonable to have a key value for those
... right now, they're just all mixed into the jumbo table.
... garykac wanted to split into sections.

garykac: Right now the key table was one gigantic table.
... there was categories, but it didn't help much
... additionally, we're going to want to augment this table over time
... e.g., there's the Android bug to map the keys to Android..

<masayuki> And I want a rule for browser vendoers who want to add new key value. I'd like to suggest that file a bug for new key value before implementing it.

garykac: so having some easy way of adding sub-categories (addendums) to the spec without having to re-publish the w3c spec.

<garykac> Filing a bug for that is a good idea

That sounds good.

<real_wez> Agreed

garykac: That's how we'd track all these issues.
... if we forgot to add it to DOM3, then we may have to add it to some other place (UI Events?)

<real_wez> The Android keys example is a good one

<real_wez> There are a variety of Android devices

garykac: once we say we are done with DOM3, we are done--there should be some other means to augment.

<real_wez> From different manufacturers

<real_wez> And they all have different keys

<masayuki> FYI: Gecko's .key value mapping table: http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0079.html

garykac: We do want these to be interoperable, and just need to come up with a process.

<real_wez> So how do we allow those to be added in a way that's not super painful for vendors, and not super confusing for content?

garykac: we should get a bug filed to create that process.

real_wez: It's not just mappings, but new keys as well.

<garykac> ACTION: create bug in Bugzilla to figure out the best way to have addendum key tables (eg: for Android) [recorded in http://www.w3.org/2013/05/07-webapps-minutes.html#action01]

<trackbot> Error finding 'create'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

<garykac> masayuki: Thanks for sharing the mapping table. We'll be looking at that to make sure the spec covers as much as possible.

I see the KeyboardEvent.locale bug...

<kochi> Does the 'locale' issue apply to all inputevent, composition events?

<garykac> The locale field needs to be specified properly in the DOM3 spec.

garykac: Yes, it's too general at the moment.

real_wez: masayuki made the point that it's not clear when you have a custom layout

<kochi> if so, it also applies to IME API spec.

real_wez: if you have users with their own changed keyboard

<garykac> wez: Masayuki brought up point of custom keyboards - what is the proper way to handle that

real_wez: if we're relying on that layout and JS to understand layout--makes it much more fragile.

garykac: it's a keyboard event, not a core event--applies not to composition event.
... locale (we have a bug tracking that)

<masayuki> Travis: composition event has .locale too.

real_wez: would we be better off having a way to get the current state of the keyboard?
... a code to keyvalue, low-level API?
... would be harder for implementors.

masayuki: Yes, same general problem for composition events too. (It's too general)

<kochi> travis, masayuki: then it also applies to IME API as it is basically combined with composition events

<garykac> ugh. yes. CompositionEvents have locale as well. :-(

<real_wez> If you look at the note on the "locale" field what you see is that it makes clear that it's not necessarily "correct" in a lot of cases

<real_wez> So my question is what is "locale" _intended_ to solve? :)

<masayuki> I tried to implement .locale on Gecko at the end of April. However, on Mac, we cannot get country/area code. So, on Mac, nobody can return "en-US" like IE. Just "en".

<garykac> masayuki: that's sad to hear.

<garykac> we need to have a locale spec that can actually be implemented on all platforms

kochi: To predict LTR/RTL key based on locale (another use case)

real_wez: Is it the case that the locale can be associated with the window, not the events.
... does it help?

<garykac> does that help?

real_wez: It helps know the state of the input system.

<masayuki> I'm not sure whether we can implement .locale on Linux. I have a hint for that https://bugzilla.mozilla.org/show_bug.cgi?id=680832#c8 but I don't check it actually.

<garykac> We'll want to have a proof-of-concept on each platform before signing off on the locale spec

IME API will expose locale as a state object on an input context. Might be worth considering this in the big picture.

<garykac> is the locale exposed by the IME API is a BCP-47 string?

kochi: The locale should be BCP47 based. (on the IME API)

<garykac> kochi: it should be

<kochi> IME API defines it is BCP-47 string

garykac: locale might be the riskiest part of the spec, since it's the least understood (by me)
... one other big thing:
... what we do with keypress vs textinput (and the char attribute)
... keypress is deprecated
... textinput was removed because HTML5 input event subsumed it's behavior.
... but it doesn't work quite the same way
... I think we need to add textinput back in. For folks currently using keypress
... additionally, if keypress is deprecated, then char attribute is useless
... if we don't have keypress then the char discussion are irrelevant.
... textinput event just gives you data (the string)

The keydown/up events describe the char that will happen, no?

garykac: Dead keys violate this assumption (can cause multiple keypresses)
... in the common case you can, but in general no you can't.

<garykac> There isn't a 1-1 correspondence between keydown/keyup and keypress

<masayuki> Travis: textinput event you said is fired *before* text editor's content is changed?

garykac: What we have in the spec is that dead keys should be implemented as composition events!
... (I was surprised by this.)
... section 2.2.3

<garykac> 6.2.3 Dead keys

<garykac> http://www.w3.org/TR/DOM-Level-3-Events/#keys-DeadKeys

masayuki: Yes, that is correct.

<garykac> YEs, the textinput can be canceled because it happens before the text field is updated

<masayuki> Okay, thank you.

masayuki: there was some weirdness in the examples (combining circumflex unicode instead of dead_acute)
... These examples need fixing

Anyone else want to discuss a bug or bug category?

garykac: keypress and char is my biggest open question.

<masayuki> me too.

real_wez: DOM3 event seems to indicate that char is valid on keyup/down, but is not generally the case outside of latin characters

garykac: you'd have to have JS implement a full IME just to figure it all out.

real_wez: given that composition events have to indicate that character event has been generated...
... one option is to fold the composition event model into the textinput model

garykac: What's nice is that you listen to one event. But with composition events, you have a begin/end pair.
... you end up with two events. Unless we allow the compositionend event existed without a start.
... I've heard folks don't want to fire more events than necessary.

I agree too

real_wez: We could drop char entirely if we have a separate event that contains the "char".
... with char on keydown/up, you can use that to see if those will generate character input or not; but in general, it's not reliable.

<masayuki> For i18n and better a11y of Web Apps, textinput approach is better since it doesn't depend on input device.

real_wez: composition events give that information via another route. So the key -> character mapping is not always clear.

<real_wez> You mean better than keypress+char?

garykac: New question

<masayuki> real_wez: yes.

<real_wez> OK, I totally agree :)

garykac: instead of using textinput, what about compositionend by itself?

It doesn't semantically feel right...

real_wez: Could adress this by a new compositiontext...

<masayuki> Travis: compositionstart and compositionend pair is important for some apps which want to stop its handler during composition.

garykac: But pressing 'k' , it seems too complex for an entire composiion event sequence.

<garykac> The 'composition' part seems semantically wrong to me

<real_wez> Right; we wouldn't actually get rid of compositionstart

So, we could confuse apps that expect a pair of events.

garykac: So noted.

<real_wez> We'd just rename compositionend to compositiontext and then generate that stand-alone for simple input like Latin-1

<garykac> BTW, I'm not sure if I like the proposal - I just wanted to throw it out there to get opinions.

<real_wez> Yes, confusing apps that already understand composition could be an issue

<garykac> One thing I like about it is that it might encourage more apps to properly support composition events.

<masayuki> Hmm, renaming compositionend sounds risky. It might be used on some websites already.

<garykac> masayuki: agreed

<garykac> It's probably too late to consider at this point

real_wez: If you're doing composed input (dead keys), you'd be generating more events (textintput, keypress, etc.)

garykac: (looking back; textinput removed in 2012, added in 2003)

<masayuki> it might be better that textinput event is fired immediately before compositionend event.

Would like to popup from bugs...

What are the next steps and when should we reconvene to talk about progress

garykac: Some of the bugs are editoral, some are naming discussions

<masayuki> Then, web apps can cancel the composition with the textinput event.

garykac: others are bigger bugs which require more thought.
... discussion will probably happen in the bugs.
... I'd like to prune down the list (maybe 10)?

I had proposed meeting every 2 weeks.

garykac: Most concerned about locale stuff.

Anyone we can enlist for locale help (BCP47)?

garykac: I'm not sure I know anyone who's an expert there.

real_wez: Boils down to what is locale for?

garykac: We could remove locale.
... that complicates the UI Events getKeyCaps method.
... I haven't thought too much about that.
... who else wanted locale?
... anyone know what motivated it?

Wondering if anyone would object to pulling it out of the spec?

garykac: I can track that as a bug to file.
... How well did this telco time work for our friends from Japan?

<masayuki> I have no idea of a way to use .locale... So, I agree to drop it from the spec.

<real_wez> :D

<garykac> ^_^

masayuki: Does this time work for you?

(Time to have a telco)

real_wez: Is this a good work model?

garykac: We'll have to make it work :-|

real_wez: We should probably focus more on IRC next time...

<masayuki> Travis: This time is not bad. If more one hour later, it's better. But perhaps, it's too late for some locales.

I can make one hour later work...

<garykac> We're going to try to have the wiki set up so that we can propose agenda items before the next meeting

I will setup a wiki for an agenda... put notes from the telco there.

Any last comments?

kochi: Quick update on IME API
... taking MS feedback

<garykac> I'll be adding more bugs in bugzilla so that all issues are being tracked there.

This is scribe.perl Revision: 1.137  of Date: 2012-09-20 20:19:01  
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 "Present: ... " found!
Possibly Present: ArtB FYI IPcaller Lachy Microsoft ScribeNick aaaa garykac glenn https kochi marcosc masayuki real_wez smaug trackbot travis wes wez
You can indicate people for the Present list like this:
	<dbooth> Present: dbooth jonathan mary
	<dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0076.html
Got date from IRC log name: 07 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/07-webapps-minutes.html
People with action items: create