<kochi_home> hello

<Travis> Hi!

<kochi_home> calling in soon.

Hello!

<garykac> Hallo

<Travis> https://docs.google.com/document/d/1pGo9hmOXCu71lnpXbqpTQNQP70DU9E-1tNN3yEWg5ig/edit?usp=sharing

<garykac> Item 1: Order of beforeinput and compositionupdate events

<garykac> Discussed in the doc, but there was a previous discussion that I missed where the opposite order was proposed.

Is beforeinput fired during composition?

<Travis> First issue: it's not always possible to cancel the IME with initial keydown (we don't think we can require that). We want to have it be a "best effort".

<Travis> Traditionally, keydown is the appropriate cancellation point.

<Travis> Do we have concensus on this point?

Firefox will be cancellable with keydown.preventDefault() on Windows and Linux. (on Mac, it's been so already)

<garykac> Is if guaranteed that we can always cancel the IME by canceling keydown?

<Travis> We can test with a wide variety of IME's, but some may not support it.

<garykac> I was under the impression that it was not *always* possible.

If keydown is fired *before* it's passed through IME, it's possible.

But I don't know it's possible on mobile platforms.

<Travis> Item 2: should keydown/up be fired during composition?

<kochi_home> yeah, on Android basically all on-screen keyboards are IME

<garykac> Item 2: should we send keydown/keyup events during composition

Idealy: shouldn't fire keydown/keyup during composition because some IMEs, e.g., hand writing system, never cause key events. So, handling keydown/keyup makes problem on some environment.

Historically, should be fired for not breaking the web.

<garykac> Masayuki: Just because handwriting systems don't send key events, doesn't mean that keyboards should send key events.

<garykac> compositon events are not *required* to have key events

<Travis> Consider the example of a simple-minded search box where the Enter keyup means "search". If during composition, the user presses the enter key to confirm a partial composition, the naive enter key handling could trigger a search (at the wrong time)

<garykac> but if they are coming from a keyboard, it's not unreasonable to include them

<Travis> Firefox does not fire them during composition. So is there really a risk of breaking the web?

garykac: I undersand it, but not all web application developers don't understand so, I guess.

Travis: We have some reports of such web sites.

<garykac> One downside of removing them, is that the initial keyup and the last keydown tend to get lost (since they occur during "composition").

<garykac> I would be happier if every keydown had a matching keyup event.

<garykac> masayuki: Some websites have complained about the lack of keydown/keyup events?

<garykac> Was it a lot of sites?

garykac: No so many. But I don't know the actual number.
... But they should use compositionupdate or input event.

Anyway, such web sites are not available from handwriting system.

<garykac> I don't think I'm concerned too much about the broken sites, because (as you say) they have accessibility issues (speech, handwriting) anyway

<Travis> If use finishes a composition and there would be a keyup without keydown, maybe we can simply just _not_ send the keyup after composition.

Travis: It's difficult because native keyup event is an independent event. So, it's difficult to know which keyup was pressed during composition.

<Travis> In general, we're concerned about having dangling keyup or keydown events in the flow involving composition events. There may be some ways to ratinonalize this bug swallowing or artificially emitting certain pairs.

<garykac> So, is there general agreeement that suppressing keyup/down during composition is a good idea? I don't feel strongly about it (other than the matching key down/up events)

<Travis> I think that the browser could figure that out based on state of composition.

<kochi_home> what about event for key presses that is not consumed by IME?

<Travis> Example?

<garykac> But Chrome and IE are currently sending the key events during composition, so the events are available (for common IMEs at least)

<kochi_home> hmm, most keys are consumed, but maybe PageUp etc?

<Travis> (Yes, and in IE's case it has caused problems with naive JS developers not realizing that they need to do filtering for languages that use IMEs.)

kochi_home: keypress event isn't fired for non-printable keys except Firefox

<Travis> Ditto.

<kochi_home> masayuki: what about keyup/down

<kochi_home> ?

<kochi_home> so, during IME composition, some non-IME key may generate keydown/up events?

<garykac> So, if the IME doesn't consume the key, it would pass it on?

<Travis> I'm not sure that an IME can "consume" the key completely.

kochi_home: Chrome does so. IE is complicated...

<Travis> Proposal then for Item 2 is to supress keydown/up events during composition and try to ensure beginning/ending keydown/up have appropriate pairings (or drop them).

<Travis> Item 3: if we don't adopt item 2 proposal, than some keydown/up pair during composition are not (in fact) cancellable. This problem goes away with the item 2 proposal.

<Travis> Item 4: Recommend beforeinput instead of keypress.

<Travis> We are all in agreement on this, I think.

Yes, but for it, beforeinput should be fired on non-editable element.

<garykac> What Event shoudl beforeinput and input be associated with.

<garykac> We had assumed that input would send an Event

<Travis> Item 5: What event type should beforeinput be? It needs to have some useful content in the event itself.

<garykac> But beforeinput needs to send more info than that

And beforeinput should have all information which is included keypress event.

<garykac> So, let's go with having a new event type: InputEvent

<Travis> Sounds good to me.

<garykac> That way we can add the fields we need to it.

agree.

I think we don't discuss about beforeinput at non-printable key combination, such as Ctrl+C.

I think that on such case, beforeinput should be also fired.

<Travis> Item 6: When does beforeinput fire in relation to composition update?

<garykac> Do we want beforeinput + updateDOM + compositionupdate + input

<garykac> or compositionupdate + beforeinput + updateDOM + input

<Travis> 'input' doesn't fire very consistently either during a composition, right?

IIRC, at the previous discussion, don't we agree with no dispatching beforeinput during compsoition?

<garykac> Effectively, this comes down to whether or not the DOM should be updated before compositionupate

I misunderstood?

<garykac> masayuki: Ojan mentioned a use case where beforeinput was always needed before the DOM was updated (by anyone, including composition)

garykac: Okay.

<garykac> The example was a app that needed to record state (like the cursor position) before any change so that the Undo chain stayed consistent.

<Travis> Seems like we all agree.

<garykac> It would be nice to remove the beforeinput, but I think that we need to keep it around since we need one place to hook to catch all pre-DOM-updates

Okay.

At previous discussion, we agreed with that compositionupdate should be cancellable. So, compositionupdate should be fired before updating DOM.

<kochi_home> yeah, if IE can follow the behavior.

<kochi_home> so cancelling composition update just cancels updating the DOM?

FYI: Even if browsers cancel DOM update, they need to assume that there is the latest composition string because some IME expect so. (E.g., TSF's IME)

<Travis> So, I think we want an order of beforeinput + compositionupdate + DOM update + input

<garykac> Next question: preference for beforeinput + compositionupdate + DOM + input vs. compositionupdate + beforeinput + DOM + input

<garykac> either way sounds good to me

<Travis> I prefer the former.

kochi_home: AFAIK, there is no platform which can cancel compositionupdate actually.

<garykac> I'll go with Travis' suggestion

<Travis> So, we need to note that beforeinput events during a composition sequence may not (and probably will not) work to cancel the DOM update.

<garykac> masayuki: Yes, we'll need to make sure the spec says that canceling isn't likely to work. Perhaps phrased as browsers should make a "best effort"

<kochi_home> masayuki: okay, cancelling compositionupdate is not so useful or confusing (to the system) anyway.

<Travis> Item 7: Which elements do fire the beforeinput/input events ?

How about compositionend vs. beforeinput? Which is important for the consistency event order.

<garykac> masayuki: I don't think the order matters. Can you think of a case where it does matter?

garykac: Simpler order is easy to understand :-)

Travis: I think it should be fired on all elements because keypress behaves so.

I meant beforeinput, not input.

input event is fired from internal editor. So, input cannot be fired from non-editable element.

<garykac> masayuki: If you add the "inputmode" flag to an element, then it will receive beforeinput and input events

<garykac> masayuki: by default, they're only sent to contenteditable, but other elements can request them

garykac: Sounds strange to me...

<Travis> I'm on board with not firing beforeinput (and input) on non-editable elements. Users can add inputmode (or make them editable if they want to see beforeinput/input).

garykac: And such behavior makes browser implementation complicated, I think.

<garykac> In general, we shouldn't be sending events to every single element type (as was done in the past).

<garykac> And it sounds like we have a mechanism ("inputmode") where elements can request to receive these events.

beforeinput is an event which notifies native key or IME input. So, I believe that such event must be fired on any focused element.

<kochi_home> yeah, if element has inputmode and is focused.

<garykac> So someone who is catching keypress on the <body> can add inputmode to receive these events, otherwise they won't.

<garykac> (sorry, bad edit, let me re-phrase)

Hmm, if we take such behavior, keypress isn't more useful for web developers?

keypress doesn't need inputmode setting which is additional work.

<garykac> So someone who is currently catching keypress on the <body> can update their code to the spec by adding inputmode to receive these events

<garykac> Switching to use beforeinput is already work that we're expecting people to do.

<garykac> Browsers will support keypress as long as websites still do these horrible things.

I don't feel it's reasonable. They need to set inputmode and add listener. Why do they need two setps for listening an event?

<Travis> Because with beforeinput, they're only interested in getting the events that really do generate input.

<garykac> But the switch to use beforeinput and adding "inputmode" on the element where they attach the listener is not unreasonable.

<Travis> keypress did not come with that guarantee.

<Travis> We're saying the keydown/up are the natural replacement for keypress -- in this scenario only.

So, before input isn't fired for non-text-input? Like Ctrl+C?

<Travis> (The scenario of watching for all key action on the keyboard on the body)

<garykac> beforeinput should fire anytime the DOM is about to be updated - regardless of what is making the change

<Travis> I don't think input is fired for a Ctrl+C either...

<Travis> Ctrl+V should fire beforeinput

<Travis> Undo/Paste should do it too.

Travis: I don't think so, Ctrl+V shouldn't cause beforeinput if it's not fired by all key combinations.
... because it's difficult to know whether an edit command is kicked by key event or not.

<Travis> Correct: if a keyboard mapping has the "paste" action using a different key pair, then it won't fire beforeinput.

<garykac> Ctrl-V by itself won't fire the event, but if the effect of ctrl-v is to cause a Paste, then the beforeinput/input events will fire.

Hmm, I don't think that before input shouldn't be fired for edit command.

Because it's cancelable, so, it's necessary to be fired synchronously.

<Travis> It sounds like we may still have some disagreement on when beforeinput will fire in relation to editing, but let's table that for now.

It means it may cause event loop by attacker.

<Travis> Next call: September 3rd, 2013

Travis: no problem for me.

<Travis> Masayuki, can you send your feedback to the mailing list so that we can continue this conversation?

Travis: Okay.

<Travis> Alright. Time's up!

<Travis> Thanks everyone for the discussion we made great headway.

Thank you.

<garykac> I'm going to update the doc/spec with the stuff we agreed on + some of proposals that we mostly have agreement on. That way we can discuss the details in context.

<kochi_home> Thanks!

<garykac> Thank you.

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)

No ScribeNick specified.  Guessing ScribeNick: masayuki
Inferring Scribes: masayuki

WARNING: No "Topic:" lines found.

Default Present: [Microsoft], +1.425.893.aaaa, garykac, kochi_home
Present: [Microsoft] +1.425.893.aaaa garykac kochi_home Travis_Leithead Gary_K Jianfeng_Lin

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: 21 Aug 2013
Guessing minutes URL: http://www.w3.org/2013/08/21-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