29 Jul 2016

See also: IRC log


GaryKac, Johannes, Morgan, Grisha, Enrica, Dave, Chong, Ojan, Léonie, Chaals, esprehn


intro / agenda bash

<garykac> I'm taking notes at https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit#

<garykac> Everyone should have write access to the doc

drag and drop

- What should the order of the events be and in what spec should this be placed?

GK: We have these in UI Events. Where should they go? Don't mind.

JW: Don't want it in UI Events?

GK: Don't think it makes sense - should be in a "downstream" version - but don't feel strongly.

OV: What if the ordering impacts the UI Events

GK: Should be stated in drag and drop how they impact.

OV: e.g. dropevent fires before beforeinput. So does paste. So which of those two fires first. Does it matter?

GK: If we don't get interop will it cause a problem?

OV: Yes.

MS: Is there an event orchestration spec?

GK: Might make sense to have one for adding new things to.
... would be a list, basically

OV: Makes more sense for me to put these into UI Events

GK: Don't mind, but it makes UI Events never end.

OV: People propose a diff to the spec, when it gets implemented we merge it into the spec.

CMN: Need to write something down that tracks the overall order.

GK: Would rather that be event order alone…

RESOLUTION: GaryKac will maintain a spec for event order…

GK: How many drag and drop events?

OV: They should happen at the same time as copy/paste

JW: @@ missed

OV/Enrica: the dragging uses the copy/paste transport but doesn't interact.

JW: in dragging you can add to or change the data that moves, in editing you just want the html being dragged, mostly.

Enrica: you might want to manipulate - represent image differently…

OV: Ordering meets all these. Order that makes sense to me.. UI Events has keydown, beforeinput… drag events to me seem to fit in the same stage as keydown.

GK: Keypress is like beforeInput - cancelable

MS: Does canceling dragstart stop the subsequent parts of the drag?
... this is particularly key with key events

JW: If you cancel beforeinput for drag I would expect the whole process to stop.

GK: Drag events don't update DOM, so should not generate input so not beforeInput
... if I am modfing the DOM I don't need to fire an event.

OV: There are cases where drop and dragend modify content.

GK: When they implicitly do that…
... dragend not cancelable, drop is.

DT: Expect beforeInput to be after drop.
... are drop/dragend mutually exclusive?

GK: Is drop before DOM update?

DT: before
... if you clone, do you get a drop, a dragend as well?

MS: What's dragend for?

Enrica: Occurs no matter what - whether you successfully drop, or just decide to stop dragging.

DT: dragend is targeted at the source, drop at the target.

JW: If we only have a drop?

GK: nothing else implicitly updates the DOM

MS: What about dragover updating the DOM?

GK: Don't know of any implicit actions that would make that happen, it's only your own code.

JW: How do we specify where a drag comes from and goes to if we only have a drop?

GK: Beforeinpur, with this drop, should have the currentSelection and needs the target loction.
... does it have data telling you what will be changed?

JW: It tells you what will be injected, and you can take over doing that.

GK: Trying to think of analogy with cut/paste.

beforeInput you get one for the cut, and another for the paste.

MS: Drop triggers the paste...

OV: drag events don't modify anything, the drop is the only thing that modifies. drag* isn't modifying the DOM.

DT: On dragend you *might* get an operation, if it is a move…

JW: So when you drop you get a dragend and a drop. That gives you where it comes from and where it goes to.

GK: Which implies two beforeinputs, for the two pieces.
... what is the selection range for drop - source or target?

Enrica: Target

GK: So you get beforeinput, drop, beforeinput input.

OV: This is decided for us in implementation we just need to figure out what it is…

MS: Can the selection change during a drag?

GK: That's scary.
... it's why beforeinput uses static range.

MS: Select a word, click, drag, and somehow it changes in the interim. You expect a static range on drop of the selection when you began dragging.

GK: If it has been modified between then you get a mess.

DT: It has a live range behind it, so you get an adjusted static range when you ask.

OV: Seems like we need to do some more digging. I can't get dragging to fire in contentEditable in Chrome

JW: images can drag by default. everything else needs draggable attribute

OV: Drop happens before the input.

GK: We only get one input

OV: Only one drop.

GK: But there is a remove from one part, and input in the other.

JW: If not dragend, we need a beforeinput that gives us where it comes from

GK: Would like to have one pair of before+input, but it can't carry two ranges.


<ojan> hQKIIrVAoRIr9joAPs1otSittvJ9xBB1u9bTt6vkzoC/Kt/s9pteEUeGKdylhCJCkIuKvNDx1+wGVwduzGHzmeJ+gvD4xocAZeAA=

<ojan> http://jsbin.com/cezivejuyi/edit?html,js,console,output

<chaals1> MS: If you do 2 input events you may have to share logic between the two, which isn't desirable

<chaals1> CMN: But they are separated

<chaals1> MS: Knowing what they are might be useful

<ojan> above jsbin is broken here's the fixed oen http://jsbin.com/latatovotu/1/edit?html,js,console,output

<chaals1> GK: If you really care you can listen to drop…

<chaals1> … someone who listens to beforeinput but not drag would be OK.

<chaals1> MS: If you drag, then drop into the container if X is true of container and Y is true of being dragged

<chaals1> GK: If you care about that you're listening to DND events and you have all the info.

<chaals1> MS: You have to store the dragstart info and correlate

<chaals1> GK: Yes, you do now.

<chaals1> JW: When you get dragend you add data to datatransfer and then only handle the drop when you get that extra information.

<chaals1> MS: We're not trying to improve drag and drop, just figure out how it works already.

<chaals1> MS: beforeInput only ever has one range, so if you need two you need two events.

<chaals1> GK: And that's what the spec says...

<chaals1> OV: And not what browsers do.

<chaals1> … testcase shows order of events, logs innerHTML

<chaals1> in FF/safari/chrome te same thing happens which isn't according to spec, for dragging an image

<chaals1> GK: So you get drop, DOMupdate, input

<chaals1> … spec says if you drag text, it does a cut during text.

<chaals1> JW: if you make an element draggable does it make text inside it draggable?

<chaals1> OV: We need some more testing here.

<chaals1> … looks like the ordering is interoperable and spec is wrong.

<chaals1> CZ: If there is a different element we will have input for both.

<chaals1> MS: beforeinput on source or target?

<chaals1> OV: Seems like we could have drop event, beforeinput, input, dragend

<chaals1> … dragstart should go long before.

<chaals1> JW: So should dragend generate another beforeinput?

<chaals1> OV: We need tests to find out

RESOLUTION: check what really happens, and update HTML specs to match.

<garykac> Doc with notes: https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit#

<ojan> test case again: http://jsbin.com/latatovotu/1/edit?html,js,console,output

Clipboard events

GK: We don't want to repeat the readyStateChange problem with beforeInput having lots of switch stuff to figure out what it does

GL: I feel the same way. We fire beforeCopy etc

GK: They were removed
... because they were not that clear

JW: beforeCopy etc fired when you tried to get the context menu up, and you need to know whether to enable or disable copy etc.

GK: so if you have native UX for e.g. bold, these events were related to whether a control supported the function and wanted it enabled.
... backing up to give some history
... Keypress was deprecated to be replaced by beforeinput.
... as the only thing you listen to for DOM updates. So you didn't care whether the changes came from keyboard, handwriting input, speech reco, etc.
... as opposed to atomic events for every possible thing
... the choice helped for accessibility, because you won't miss a specific action like key

OV: We already have input.
... makes less sense for beforeinput and input to have mismatch

GK: Design is we have input, and beforeinput as catchall for any update to the DOM, instead of specific events trapping the user's action (not intent).
... a hybrid in the middle seems a bad idea.
... But don;t think this is a generic thing like readyState. Although people may say it is.

OV: hear Anne's point, and adding the inputtype has some risk of doing what Anne was worried about - having written an editor, I *want* to do what Anne doesn't want me to do - for me it is a feature not a bug.

DT: For adding event listeners you can have options - would we specify a filter? Before you add a listener, you filter the things and e.g. only listen for paste, instead of dealing with switch statements.

GK: What if you want to listen for 12 out of 20?

DT: this is where you want to e.g. listen for "enter", not all keys

MS: If you listen with a filter, does the event still fire more generally?

DT: Yes.
... we have a lot of performance hit because we're listening for the enter key and running a lot of JS to figure it out.
... note this is an idea, not a plan.

OV: Are you concerned about beforeinput in general, or specifically on clipboard

GL: Specifically on clipboard.
... beforeInput seems to want to do everything, beforeInput should be user-initiated, but cut/copy/paste might or might not be

GK: We could restrict beforeInput to only user-initiated DOM updates. Would be tricky spec…

OV: Same issue applies to input right?
... but it seems *really* strange for beforeinput and input not to match.

GK: We try to make beforeinput cancelable

[except IME]

GL: I thought you can listen to the beforeCopy event

OV: That's a different beast. If you preventDefault, it prevents the copy item appearing in the right-click menu.
... happens when you pop up a right-click menu.
... and it's terrible.

GK: And it's gone from the spec

JW: Was only implemented in one browser, no?


<garykac> Issue where they were removed from the clipboard api spec: https://github.com/w3c/clipboard-apis/issues/25

<johanneswilm> Here is Hallvord asking to kill beforecopy https://readable-email.org/list/public-webapps/topic/clipboard-kill-onbefore-events

GL: If people generally want to have beforeInput instead of beforeCopy, we can go with that.

JW: It is paste that is similar to beforeInput - beforePaste is a different thing relevant to the menus and so on.

GK: Yes, paste is analagous to beforeInput - before DOM is updated, and cancelable.
... does paste always trigger input?

OV: modulo bugs, yes.

GK: Don't think we can get rid of paste, since it's been around, but we would like to replace it with beforeInput.
... if we could get rid of paste and cut, what happens to copy?
... leaving the three around is consistent in that regard.

GL: So if we go with this do we discourage web developers from listening to paste?

GK: i.e. we're deprecating them.
... we cannot do that for copy. So think we should keep paste and cut.

JW: Tried to get the two specs together last year. CLipboard said the browser must paste - cannot stop it. I.e. not cancelable.
... but we were trying to do it the other way around. So clipboard tried to make exception for contentEditable=true, not cE=[other values]

GK: So order would have to be beforeInput, cut/paste, input. Copy doesn't have before/input

JW: What if you cancel beforeCut? Does it not copy at all?
... I cannot cancel a copy to the cipboard - does canceling a cut send something to the clipboard?

GK: If you cancel beforeInput inputtype=cut then it should cancel the cutting operation?

JW: Trying to find correspondence between copy and cut…

GK: canceling beforeInput could just stop the impact on the DOM, and canceling cut stops the whole lt. But I want those two things to be consistent.
... if you consider clipboard buffer as part of the DOM, then you can claim some consistency.

[So, what's more surprising: incosistency between beforeinput.inputtype-cut and cut, or cut and copy?]

MS: Cancel is generally understood as a "binary operation", but in this case there are 4 possible outcomes of it, so figuring out which of those is the "obvious and useful" one is hard.

JW: When cut happens you make your own copy not on clipboard, but you also want to see that in the clipboard. Then we don't know where the paste goes - what if it goes off to a different app?
... so in your own app you use your private clipboard, but you put the other stuff into the clipboard so it can be used outside the app.

GL: Think user would be surprised if the stuff they cut isn't removed but still gets into the clipboard.

JW: If the user cuts something you want that into their clipboard, but you are going to handle it if it is all use within your app.

CMN: what Grisha says. Everywhere else, a failed cut doesn't affect clipboard, so we shouldn't introduce anomalous behaviour. Canceled cut should not copy to the clipboard, either in beforeInput or in cut.

JW: Want to make sure we can do this, because there is user-initiated requirements.

MS: So why do we have beforeinput *and* cut?

GK: Because we cannot get away with removing cut/copy/paste from the web :(
... and so someone can handle beforeinput and always manage to get the events they need.

RESOLUTION: cut and beforeinput with inputtype=cut are cancelable, canceling stops anything going to the clipboard, paste the same, there is no beforeInput for copy, and this is for anything that is not contenteditable=false

OV: input fires in editable regions, but key events fire wherever things can be focused.

GL: If we fire input, we fire beforeinput…

OV: Yeah. at some point we might want to relax that, but will require author opt-in
... who implements undo API?

GL: We do in Edge.

OV: Thought we did, but apparently not

EC: nor webkit

OV: Like cut copy paste: input already fires, our hands are tied.
... should the browser try to work out what changes were made? Think the answer is no.

GL: People who want undo will track their own, rather than go for literally everything.

OV: Wait, misunderstood. If JS modifies the DOM should it go into the history?

GL: What's the use case?

JW: Your editor handles a bunch of stuff, but you pass undo/redo to the browser to handle.

GL: So if you have a browser stack and your own, you want to make sure they don't get interleaved wrong.

JW: Is it possible to let the browser handle undo/redo?

GK: sounds analogous to cut/copy/paste

OV: We wrote a spec to do this, but don't see anyone implementing it.
... browsers are not interoperable here anyway last I looked.

JW: So if I am going to start handling undo I need to handle the lot, right now.

OV: Yes. It would be great to have a standard for that, but won't be now, and is orthogonal to beforeInput.

JW: So beforeinput doesn't have targetrange for undo/redo

GK: Yes, because the info is coming from somewhere else. If you call it, I don't think it is helpful info.

MS: So what does beforeinput have?

GK: fires before the change, has type, don't think there is any other info.

MS: We just want something we can cancel, and handle it ourself.

RESOLUTION: currently, you can rely on the browser totally, you can do your own thing and take care of it all, but trying to have a mix of the two is likely to have bad outcomes.

GK: is undo/redo cancelable?

OV: Should be.

GL: Don't think we fire undo event.

GK: So if nobody implemented it, let's not add the event.
... you can find when undo happened because of undo/redo already, you always get an input.

GL: if we preventDefault an undo, what happens to the undo stack?

CMN: Think it makes sense that if you preventDefault on an undo action the stack should be popped.

[most people: no, that makes no sense]

EC: You should delete the stack

GK: that saves memory. But in the future it means we cannot make an undo manager.

RESOLUTION: We don't want undo/redo events outside beforeInput
... preventDefault on an undo means "don't apply this, no change to the DOM, no change to the undo stack"

<rniwa> chaals: /me hi's chaals!

history - undo/redo

JW: This is about moving stuff from input events to UI.

Non-cancelable event

GK: We need input events never cancelable, or sometiimes, e.g. in IME, it might not work.

JW: for simplicity we said it is never cancelable.
... problem is we write editors for latin that don't work with composition. We want to make that easier.

GK: We have to make an exception for composition, and we should pick the easiest way to make it happen

OV: On the down side, that means in Android nothing is ever cancelable. Other than that, it would be great.

GK: The reality is "it is possibly not cancelable".

OV: If the isComposing flag is true, then Input is possibly not cancelable

GK: And that is in UIEvents

[We would like to make the two specs say the same thing…]

OV: Android may not make it cancelable at all.
... use case is where you write your own editor you want to control everything.

JW: e.g. collaborative

OV: pragmatic thing is to say If composing is true it's not cancelable - for now…

CZ: The very last thing can be cancelable.
... you are finished, the browser is inserting text.
... e.g. I have editor, don't want user to edit text. Using IME makes it uncancelable, but when the user tries to insert text I cancel that

JW: So I let you use the IME, handle the composition, and then when you hand it to me I can decide what to do.

<Grisha> resehttps://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html

-> https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html keyboard event viewer

OV: if you type into an IME, and the preventDefault, should the stuff I typed remain?

GK: No, it's temporary stuff for the IME.

DT: So I presume the line would stay there…

OV: Staying in IME composition?

DT: The line indicating you're in IME would be there


OV: if you preventDefault while in composition, at the end of it when you can, you remove all the artefacts of what was being done in composition…

GL: We update DOM before composition
... now we fire compositionUpdate, and the DOM is not updated yet.

GK: We agreed where we would put beforeInput

GL: We were different, agreed we would change to match everyone else

OV: And we had a bug, as well.
... didn't have a final compositionUpdate before compositionEnd.
... compositionStart / End don't do updates, only compositionUpdate which have beforeInput, and at the end there is compUpdate, befInput, input, compEnd.
... so the last beforeInput in that stream, if prevented, will undo the whole composition back to the compositionStart

JW: If you can cancel it, then by definition you're at the end.

GL: When is isComposing flag set?

OV: In each of these cases.

GK: How do I know if we are catching the last thing?

JW: Spec says you have to delete everything and add it again. And Chrome does.

CZ: Doesn't have to be the latest text, could be the english text.

GK: But for japanese that's irrelevant if you're in kana already.

OV: Consistency across here is good.

GK: So in japanese we delete then reinsert as a way to know that we're at the end of the composition.


GK: We could optimise away the replacement in some IMEs

OV: The majority of people writing editors don't understand any IMEs. So you're better not having inconsistency, or they break stuff

GK: So we have to have a redundant event, for Japanese.

MS: Why no different type?

GK: We never had a type, in the past. We could say "type=finalComposition" - which sounds nicer

JW: That sounds saner.

OV: This might be good enough to spec it like this and be happy with it.
... so if isComposing is true, and type != finalCompositionStateThingPlaceShedForCycles, then it isn't cancelable. Then we get something that will work for developers.

[break coming fast]

[question about why to have inComposition, and how to stop developers from breaking things by accident]

GK: Is beforeInput cancelable or not? Yes, except when isComposing is true… except that the last beforeInput sent, just before the endComposition, and that will have a special type.
... and if canceled DOM goes back to how it was before startComposition...

OV: Does that work for Android? You can start composition on existing text.

RESOLUTION: beforeInput is cancelable except when isComposing is true… except that the last beforeInput sent, just before the endComposition, and that will have a special type. Note this is subject to matching Android reality…

[so there is spec update to be done, and testing on Android]

static ranges

GK: proposal is consistent with what RNiwa said…

rniwa: ^^

EC: We were in favour of static ranges. Otherwise we are all fine.

JW: What's the plan for where it lives

GK: Range is a separate spec. static range is probably going to be another thing on its own.

OV: there isn't a spec yet, right?
... maybe we should have one before we ship.

ASIDE: what happens if you undo/redo within composition… [needs testing]

GK: So we take static ranges through the process, I'll edit it.

data and dataTransfer

OV: data property should give same content as datatransfer.getdata text/plain

JW: OK, no problem.

OV: Do all beforeInputs have transferData?

JW: not now but we can make that so.

OV: or we can make them have only one.

GL: undo doesn't have anything

JW: Now only clipboard and DND have this - the only one with data is insertText. I can expand it…
... bold, italic, etc has a targetRange but no data or transferData

OV: insertNonText ?

JW: Was replaceContent, and people agreed to change it

OV: nonText is weird. Something like insertComplicatedStuff, or HTML, or whatever. This is bikeshedding, but I don't like the current colour.
... do we really need it at all yet?

JW: a spellcheck that replaces stuff running across element boundaries, not from a user typing.

CMN: Maybe a live translation system.

MS: I see value between a user input event and something done by another system like spellcheck.

GK: So to return to the data / transferData issue - do we have both? Is there transferData everywhere that is nice for consistency?

OV: What about bold… there are nonsensical place to have it.

DT: transferData seems heavyweight for things that don't need it.

OV: DnD and CCP (cut copy paste) need it. Also insertRichStuff would.

JW: Seems odd that there are data sometimes and transferData others.

OV: We could put both onto DnD, CCP, and insertRichStuff and insertText, with data as a shortcut.

GL: The redundancy bugs me a bit

OV: me too.

GL: how often will it be used?

OV: Depends on the command…
... if they are doing transferData on insertText, that's stupid expensive.
... propose: insertText has data, DnD and CCP get transferData.

DT: We have a table in the spec to show which ones are valid?

JW: Yep.

GK: so insertText has transferData = null.

OV: We need to be sure its transferData or dataTransfer...

[scribe agrees]

[It is dataTransfer]

JW: There is a different name for it in clipboard API

GL: So for CCP and DnD, data will be null.

<dtapuska> For the notes if the spec could have a table that looks similar to this: https://w3c.github.io/pointerevents/#pointer-event-types

RESOLUTION: CCP and DnD have dataTransfer an data=null, insertText is vice versa.

opt-in/out of editing features and menus

GK: There is no good technical answer here :(

DT: This applies to virtual keyboard, whether there is a bold option, etc.

GL: developers want to turn on or off things that they don't do, or give context to the UA asking for numeric keyboard, or I'm editing plaintext and there is no need for bold etc.

OV: You can use inputmode with the input event, but otherwise no…

EC: iOS does this driven by input type.

DT: Same class of problem.

JW: Especially problematic that menus pop up we cannot remove, but try to do things the user cannot use.

GK: New feature is released - what does current code do - are they opted in or do they update their code to get the feature?

OV: Don't think we should support arbitrary commands. Does it make a difference to support bold+italic but not underline, vs have rich formatting or not?

MS: People want to lock down some options, and don't want a context menu to bypass that and offer other stuff.

GL: What if we have a binary - you can disable formatting buttons.

OV: High priority is which virtual keyboard - that's what people want.

EC: Would be the same for the entire element - you won't switch keyboard as you move around the block.

JW: You also get the menu showing up that you didn't want. It covers stuff and users can't get to things they want.

MS: You can't just disable the context menu to stop bold appearing because you want e.g. copy

EC: Ideally you have a set of commands and let the application choose which ones are available.
... This isn't the same as the keyboard problem.

CMN: Can we use inputmode?

OV: Not sure it matches well - although nobody ships inputmode any more so maybe we can er-use it. Or call it keyboardType - someone needs to make a list of the types that we want.

DT: You might want e.g. autocapitalise. On Android you roll these into flags for the keyboard.

CMN: the problem is this is a big list that is very context-specific so you get whatever a few developers understood and missed out on various others.

DT: iOS has ascii, phonepad, email, twitter, phone number, etc...

OV: Let's take the intersection of iOS+Android, and then add things if people convince us

CMN: We can replace inputmode as specced - and unimplemented - with this. It's a simple list of labels and keys that should be there.

OV: Sure, unless that upsets people and we can change the name.

JW: From editors I heard that people wanted to get rid of the menu, but Ryosuke proposed a way to get rid of the commands.
... on a more fine-grained basis. Is it possible to have a command to disableAll, and enable(individual) menu components?

GK: So by default you opt in to new features, although you can opt out of everything and choose everything you want.

OV: Apple are the only ones who do this now, so they should make a proposal and everyone else will say "sure"...
... think we should wait for Apple's proposal
... having opt-out all and then opt back in, is super painful.

GK: There isn't an obviously right answer.
... Does that block anything or is it orthogonal and not holding anything. I think and hope so.

JW: editing software developers want this, but no it doesn't interfere with standards work - only reality.

RESOLUTION: We're waiting for Apple's proposal to discuss at TPAC regarding opt in/out of commands.
... We will spec up the list of inputmode (or whatever we call it) for selecting keyboards.

-> https://w3c.github.io/html/sec-forms.html#input-modalities-the-inputmode-attribute in W3C HTML

relation to execCommand


JW: Made a proposal about reasonable execCommand things - but not all of them are there. If things are missing, please speak up.

GK: seems like a small number should come over.

GL: Think it is close to 37 things.

GK: Think most don't have corresponding beforeinputtypes.

<garykac> https://github.com/w3c/editing/issues/110

OV: All we need command types for are things built in to the user agents that the user can trigger
... Think a bunch of the ones included might not be implemented. The point is not to come up with a whole new set of names - use the same names.

GK: And spec should not require implementing them all to conform.


IME for european languages on long-press keyboard

JW: You hold down a key, and then you get a menu for accented characters. If we cancel on keydown, that breaks.
... if we preventDefault on getting the 'e' we don't get the menu.

DT: if you do the preventDefault on beforeInput instead of on keyDown, the problem goes away...

RESOLUTION: Use preventDefault on beforeInput instead, and magically the world will be better. For now.


DT: Lets you adjust the text of the enter key on virtual keyboard.
... iOS has some predefined ones, with this you can set values.
... want to make this work on Android.
... specified on the input field - will have to specify something similar for HTML, so it effects cE

GK: We got a lot of input from Android because we could find documentation. Think the key values we have work everywhere but couldn't find them for iOS, so if you can help us find them…

EC: I'll dig it out.

RESOLUTION: make it so (sort out mozActionHint)

Publishing or leaving things asleep

OV: static range needs a spec first.

JW: contentEditable modes isn't sleeping but maybe should be moved forward.
... input events too.

Summary of Action Items

Summary of Resolutions

  1. GaryKac will maintain a spec for event order…
  2. check what really happens, and update HTML specs to match.
  3. cut and beforeinput with inputtype=cut are cancelable, canceling stops anything going to the clipboard, paste the same, there is no beforeInput for copy, and this is for anything that is not contenteditable=false
  4. currently, you can rely on the browser totally, you can do your own thing and take care of it all, but trying to have a mix of the two is likely to have bad outcomes.
  5. We don't want undo/redo events outside beforeInput
  6. beforeInput is cancelable except when isComposing is true… except that the last beforeInput sent, just before the endComposition, and that will have a special type. Note this is subject to matching Android reality…
  7. CCP and DnD have dataTransfer an data=null, insertText is vice versa.
  8. We're waiting for Apple's proposal to discuss at TPAC regarding opt in/out of commands.
  9. Use preventDefault on beforeInput instead, and magically the world will be better. For now.
  10. make it so (sort out mozActionHint)
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/07/29 23:55:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/need/can add to or change/
Succeeded: s/G:/GK:/
Succeeded: s/Hee/Here/
Succeeded: s/precv/prev/
Succeeded: s/GK/OV/
Succeeded: s/dataTransfer/transferData/
Succeeded: s/dataTransfer/transferData/
Succeeded: s/79/110/
No ScribeNick specified.  Guessing ScribeNick: chaals
Inferring Scribes: chaals
Present: GaryKac Johannes Morgan Grisha Enrica Dave Chong Ojan Léonie Chaals esprehn

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: 29 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/29-editing-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]