Re: IME events

On Mon, Jun 8, 2009 at 6:26 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> On 6/8/09 11:22 AM, Daniel Danilatos wrote:
>
>> Hey guys,
>>
>> [+Bono Hironori from Chromium]
>>
>> I've just had a lengthy email discussion about IMEs with
>> Nakano Masayuki of Mozilla. I think there's a few pieces missing so far
>> in diagrams [3] and [4] linked in the previous email. There's a few
>> points to discuss (hopefully in detail during the telcon)
>>
> Might be better to discuss (also) here so that people not attending telcon
> can participate too.
>

Of course!


>
>
>
>  but I'll just
>> raise a couple now, to see what thoughts people have for starters:
>>
>> 1) Non-key input (clicking an option in an IME menu, speech input, etc)
>>
>
> [3] and [4] were made to understand key event flow, so that is why they
> don't handle for example speech input.
>

Understood. (What thoughts do people have about the full IME story so far
though? If we're dealing with it at all, as with key events, we should deal
with it fully.)


>
>
>
>  2) TSF (http://msdn.microsoft.com/en-us/library/ms629032(VS.85).aspx)
>> for Windows involves requiring locking of the text whilst the IME makes
>> changes, then unlocking. I'd like to see the web app have some control
>> over this. For example, to prepare a section of the document for change,
>> and have a contract between the app and the browser about what parts are
>> OK to change and what aren't (otherwise it's back to relying on mutation
>> events if the app can't be certain about which parts of the DOM the
>> browser will touch and which it won't). This is an example of something
>> fairly complicated, I wonder what other kinds of IME APIs there are that
>> have similar complexities - I'm no expert.
>>
>> On a higher level note, the main thing I'd like to see is the web app
>> being able to preview and have control over any changes the browser
>> wishes to make to the DOM in a contentEditable region. That way mutation
>> events won't be needed at all for those use cases (they are barely
>> usable now anyway, because they (a) do not give much information about
>> user intent - did the user just type, or paste, or hit undo, who knows?
>> and (b) they are mostly after-the-fact, always non-cancelable, etc).
>>
>> Cheers,
>> Dan
>>
>> On Sat, Jun 6, 2009 at 10:49 AM, Doug Schepers <schepers@w3.org
>> <mailto:schepers@w3.org>> wrote:
>>
>>    Hi, Folks-
>>
>>    I will be hosting a F2F at my house next week, but we will be
>>    reconvening the telcons week after next, probably on Wednesday, June
>>    17 or Thursday, June 18.  Either day works for me, but finding a
>>    good time for everyone might be challenging: we typically have
>>    attendees from Finland (Olli Pettay of Mozilla), from US West Coast
>>    (Travis Leithead and Jacob ??, of Microsoft), US East Coast (myself,
>>    and sometimes some government folks who are helping with testing),
>>    and now Sydney, Australia (Dan Danilatos, of Google Wave). [1]
>>
>>    Olli says:
>>    "For me the best days are Wednesday and Thursday, 10:00am-01:00am
>> (EET).
>>      Monday and Tuesday evenings/nights are also possible."
>>
>>    Travis says:
>>    "Jacob and I are available for telecons 8-5 pm (perhaps a little
>>      later if needed)."
>>
>>    Pretty much any time on Wednesday or Thursday works for me (late
>>    afternoon is best).  Looking at TimeAndDate [2], it looks like 21:00
>>    UTC on Wednesday might work, if Dan is a morning person (otherwise
>>    it would be pretty cruel to him).
>>
>>
>>    The proposed agenda is (what else?) mutation events and a sane
>>    keyboard model.  The telcon will last one hour.  So, I would greatly
>>    appreciate keeping up the email dialog on mutation events (I will
>>    compile the use cases and requirements on the wiki, as they roll
>>    in).  It may be that we don't "solve" mutation events for DOM3
>>    Events, but put together another dedicated spec to address the use
>>    cases in another way, and caution people about the costs of mutation
>>    events.
>>
>>    In addition, I'm hoping that we have a flowchart of keyboard event
>>    models by that time, for both IE (Travis and Jacob are working on
>>    this), and if possible, for WebKit.  We have my rough draft of an
>>    idealized model [3], and Olli's more accurate Gecko model [4].
>>
>>    Dan, or anyone on your team, or anyone at all, could you work on a
>>    WebKit keyboard event model flowchart?
>>
>>    When I get them all, I'll normalize them for easy comparison, and we
>>    can work to produce a unified model that works as widely as
>>    possible.  If anyone wants to send in addition flowcharts for other
>>    implementations (including mobiles), that would also be welcome.  I
>>    don't know that we'll be able to solve the IME issues, but if we
>>    can, we will.
>>
>>    [1]
>>
>> http://www.timeanddate.com/worldclock/meetingtime.html?month=6&day=17&year=2009&p2=43&p3=101&p4=234&p5=240&iv=0
>>    <
>> http://www.timeanddate.com/worldclock/meetingtime.html?month=6&day=17&year=2009&p2=43&p3=101&p4=234&p5=240&iv=0
>> >
>>    [2]
>>
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=6&day=17&hour=21&min=0&sec=0&p1=43&p2=101&p3=234&p4=240
>>    <
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=6&day=17&hour=21&min=0&sec=0&p1=43&p2=101&p3=234&p4=240
>> >
>>    [3]
>>
>> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-keyflow.svg
>>    [4]
>>
>> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/keyflow-gecko.svg
>>
>>
>>    Regards-
>>    -Doug Schepers
>>    W3C Team Contact, SVG and WebApps WGs
>>
>>
>>
>