[D3E] Draft minutes from 7-May-2013 call [Was: Re: WebApps DOM3 Events Wiki page]

[ Sorry for the cross-posting. Going forward, let's please use www-dom 
for D3E discussions, minutes, etc. ]

On 5/7/13 9:06 PM, ext Travis Leithead wrote:
>
> Hey folks,
>
> I just posted the raw minutes to the DOM 3 Events wiki page:
>
> http://www.w3.org/2008/webapps/wiki/DOM3Events
>
> http://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings
>
> The page itself is a derelict from ages past, and I haven’t made much 
> of an effort to clean it up, but it does have a new section for 
> Meetings, and a place to propose an agenda.
>
> The minutes span the mightnight rollover on some server, so they are 
> not contiguous, and I failed to find a way to automatically stich them 
> together, so they are in two parts. Art, I’d love any pointers to how 
> to clean them up… J
>

I merged the two IRC logs into minutes 
<http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html>, 
copied below.

(I'll try to get someone from the Team to copy these minutes to `date 
space` i.e. .../05/07-webapps-minutes.html.)

-AB

W3C <http://www.w3.org/>


  - DRAFT -


  DOM 3 Events


    07 May 2013

Agenda <http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0076.html>

See also:IRC log <http://www.w3.org/2013/05/07-webapps-irc>


    Attendees

Present
    Travis_Leithead, Gary_Kacmarcik, Masayuki_Nakano, Wez(Google),
    Takayoshi_Kochi
Regrets

Chair
    Travis
Scribe
    Travis


    Contents

  * Topics
    <http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#agenda>

     1. spec update
        <http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#item01>
     2. Bugs!
        <http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#item02>
  * Summary of Action Items
    <http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#ActionSummary>

------------------------------------------------------------------------

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 
inhttp://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>. 
<http://www.w3.org/2008/webapps/track/users%3E.>

<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 
thathttps://bugzilla.mozilla.org/show_bug.cgi?id=680832#c8but 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.


    Summary of Action Items

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

[End of minutes]
------------------------------------------------------------------------

Received on Wednesday, 8 May 2013 11:16:21 UTC