16:55:56 RRSAgent has joined #editing 16:55:56 logging to http://www.w3.org/2016/07/29-editing-irc 16:56:10 chaals has changed the topic to: Editing APIs meeting: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-29-Editing.md 16:56:17 rrsagent, set logs world-visible 16:56:46 agenda+ intro / agenda bash 16:56:56 agenda+ drag and drop 16:57:03 agenda+ clipboard events 16:57:14 agenda+ history - undo/redo 16:57:29 agenda+ Non-cancelable event 16:57:37 agenda+ static ranges 16:57:56 agenda+ opt-in/out of editing features and menus 16:58:07 agenda+ relation to execCommand 16:58:24 agenda+ Data and dataTransfer attribute 16:58:43 agenda+ IME for european languages on long-press keyboard 16:59:08 agenda+ Virtual keyboard enter key text? 16:59:21 agenda+ adjust virtual keyboard type 16:59:31 agenda+ publishing drafts 17:02:13 zakim, next item 17:02:13 agendum 1. "intro / agenda bash" taken up [from chaals] 17:02:52 present+ GaryKac, Johannes, Morgan, Grisha, Enrica, Dave, Chong, Ojan, Léonie, Chaals 17:03:50 enrica has joined #editing 17:03:51 garykac has joined #editing 17:04:25 chongz has joined #editing 17:04:26 I'm taking notes at https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit# 17:04:33 Everyone should have write access to the doc 17:06:36 zakim, take up next item 17:06:36 agendum 2. "drag and drop" taken up [from chaals] 17:06:45 johanneswilm has joined #editing 17:07:09 - What should the order of the events be and in what spec should this be placed? 17:07:24 GK: We have these in UI Events. Where should they go? Don't mind. 17:07:37 JW: Don't want it in UI Events? 17:08:02 GK: Don't think it makes sense - should be in a "downstream" version - but don't feel strongly. 17:08:19 OV: What if the ordering impacts the UI Events 17:08:29 GK: Should be stated in drag and drop how they impact. 17:09:00 OV: e.g. dropevent fires before beforeinput. So does paste. So which of those two fires first. Does it matter? 17:09:14 GK: If we don't get interop will it cause a problem? 17:09:18 OV: Yes. 17:09:30 MS: Is there an event orchestration spec? 17:09:41 GK: Might make sense to have one for adding new things to. 17:09:57 … would be a list, basically 17:10:07 OV: Makes more sense for me to put these into UI Events 17:10:08 dtapuska has joined #editing 17:10:17 GK: Don't mind, but it makes UI Events never end. 17:10:34 OV: People propose a diff to the spec, when it gets implemented we merge it into the spec. 17:11:00 CMN: Need to write something down that tracks the overall order. 17:11:10 GK: Would rather that be event order alone… 17:11:53 RESOLUTION: GaryKac will maintain a spec for event order… 17:14:04 GK: How many drag and drop events? 17:15:26 OV: They should happen at the same time as copy/paste 17:15:31 JW: @@ missed 17:16:48 OV/Enrica: the dragging uses the copy/paste transport but doesn't interact. 17:17:15 JW: in dragging you need the data that moves, in editing you just want the html being dragged, mostly. 17:17:44 s/need/can add to or change/ 17:18:05 Enrica: you might want to manipulate - represent image differently… 17:19:43 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. 17:20:00 GK: Keypress is like beforeInput - cancelable 17:20:22 MS: Does canceling dragstart stop the subsequent parts of the drag? 17:20:42 … this is particularly key with key events 17:20:57 JW: If you cancel beforeinput for drag I would expect the whole process to stop. 17:21:11 GK: Drag events don't update DOM, so should not generate input so not beforeInput 17:21:29 … if I am modfing the DOM I don't need to fire an event. 17:21:39 OV: There are cases where drop and dragend modify content. 17:21:46 GK: When they implicitly do that… 17:21:54 … dragend not cancelable, drop is. 17:22:08 DT: Expect beforeInput to be after drop. 17:22:24 … are drop/dragend mutually exclusive? 17:22:47 GK: Is drop before DOM update? 17:22:52 DT: before 17:23:03 … if you clone, do you get a drop, a dragend as well? 17:23:14 MS: What's dragend for? 17:23:42 Enrica: Occurs no matter what - whether you successfully drop, or just decide to stop dragging. 17:24:13 DT: dragend is targeted at the source, drop at the target. 17:24:18 JW: If we only have a drop? 17:24:28 GK: nothing else implicitly updates the DOM 17:24:47 MS: What about dragover updating the DOM? 17:25:00 GK: Don't know of any implicit actions that would make that happen, it's only your own code. 17:26:42 JW: How do we specify where a drag comes from and goes to if we only have a drop? 17:26:59 GK: Beforeinpur, with this drop, should have the currentSelection and needs the target loction. 17:27:13 … does it have data telling you what will be changed? 17:27:24 JW: It tells you what will be injected, and you can take over doing that. 17:27:37 GK: Trying to think of analogy with cut/paste. 17:27:48 beforeInput you get one for the cut, and another for the paste. 17:28:08 MS: Drop triggers the paste... 17:28:59 OV: drag events don't modify anything, the drop is the only thing that modifies. drag* isn't modifying the DOM. 17:29:22 DT: On dragend you *might* get an operation, if it is a move… 17:29:41 JW: So when you drop you get a dragend and a drop. That gives you where it comes from and where it goes to. 17:29:54 GK: Which implies two beforeinputs, for the two pieces. 17:30:13 … what is the selection range for drop - source or target? 17:30:22 Enrica: Target 17:30:45 GK: So you get beforeinput, drop, beforeinput input. 17:31:05 OV: This is decided for us in implementation we just need to figure out what it is… 17:31:16 MS: Can the selection change during a drag? 17:31:22 GK: That's scary. 17:31:33 … it's why beforeinput uses static range. 17:32:11 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. 17:32:27 GK: If it has been modified between then you get a mess. 17:32:58 DT: It has a live range behind it, so you get an adjusted static range when you ask. 17:33:52 OV: Seems like we need to do some more digging. I can't get dragging to fire in contentEditable in Chrome 17:34:31 JW: images can drag by default. everything else needs draggable attribute 17:34:39 OV: Drop happens before the input. 17:34:44 GK: We only get one input 17:34:48 OV: Only one drop. 17:34:59 GK: But there is a remove from one part, and input in the other. 17:35:58 JW: If not dragend, we need a beforeinput that gives us where it comes from 17:36:17 GK: Would like to have one pair of before+input, but it can't carry two ranges. 17:36:54 http://plexode.com/eval3/#s=aekVQXANJVQMbAx1yAUpFHlBLQk8BRFBPVUaiJkVKVUJDTUYfR1BQPU+yHUpOSJeZPQObnaNUVbsBVFNEHruQVVFUGxAQSg9XtkZQREVPD6BOEFFQU1VTQqgQFhkZFBNAFBERWesRux+ytEK5mpxPTUpPTAFJKZGI7HAZCKhFI7CPEDBxYIxDJioBxWKhGKYOiisIhVDZPUJGeJmS5UAL1fT8AJVKABIrhJAdCByeSzJ8vmKyAYNAZLSKTMABXpPFpQJAJIwKAJcWQBT6hKhQVgPJtDooPKpaKJGBs/fAPNAKDiyLzzjtcIRFIomK6kKotJTAUkVBIIl 17:36:54 hQKIIrVAoRIr9joAPs1otSittvJ9xBB1u9bTt6vkzoC/Kt/s9pteEUeGKdylhCJCkIuKvNDx1+wGVwduzGHzmeJ+gvD4xocAZeAA= 17:37:39 http://jsbin.com/cezivejuyi/edit?html,js,console,output 17:38:03 chaals1 has joined #editing 17:38:21 rrsagent, draft minutes 17:38:21 I have made the request to generate http://www.w3.org/2016/07/29-editing-minutes.html chaals1 17:38:39 rrsagent, make log public 17:40:04 MS: If you do 2 input events you may have to share logic between the two, which isn't desirable 17:40:27 CMN: But they are separated 17:40:35 MS: Knowing what they are might be useful 17:40:35 above jsbin is broken here's the fixed oen http://jsbin.com/latatovotu/1/edit?html,js,console,output 17:40:45 GK: If you really care you can listen to drop… 17:41:07 … someone who listens to beforeinput but not drag would be OK. 17:41:30 MS: If you drag, then drop into the container if X is true of container and Y is true of being dragged 17:41:46 GK: If you care about that you're listening to DND events and you have all the info. 17:42:02 MS: You have to store the dragstart info and correlate 17:42:07 GK: Yes, you do now. 17:42:27 JW: When you get dragend you add data to datatransfer and then only handle the drop when you get that extra information. 17:43:30 MS: We're not trying to improve drag and drop, just figure out how it works already. 17:43:53 MS: beforeInput only ever has one range, so if you need two you need two events. 17:44:03 GK: And that's what the spec says... 17:44:08 OV: And not what browsers do. 17:44:32 … testcase shows order of events, logs innerHTML 17:44:59 in FF/safari/chrome te same thing happens which isn't according to spec, for dragging an image 17:45:16 GK: So you get drop, DOMupdate, input 17:45:40 … spec says if you drag text, it does a cut during text. 17:46:11 JW: if you make an element draggable does it make text inside it draggable? 17:46:31 OV: We need some more testing here. 17:46:47 … looks like the ordering is interoperable and spec is wrong. 17:46:59 CZ: If there is a different element we will have input for both. 17:47:09 MS: beforeinput on source or target? 17:47:56 OV: Seems like we could have drop event, beforeinput, input, dragend 17:48:02 … dragstart should go long before. 17:49:45 JW: So should dragend generate another beforeinput? 17:50:04 OV: We need tests to find out 17:51:05 RESOLUTION: check what really happens, and update HTML specs to match. 18:06:42 morgan has joined #editing 18:07:57 enrica has joined #editing 18:08:51 Grisha has joined #editing 18:09:24 rrsagent, draft minutes 18:09:24 I have made the request to generate http://www.w3.org/2016/07/29-editing-minutes.html chaals1 18:09:53 Doc with notes: https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit# 18:10:17 johanneswilm has joined #editing 18:10:41 test case again: http://jsbin.com/latatovotu/1/edit?html,js,console,output 18:11:11 chaals has changed the topic to: Editing APIs meeting: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-29-Editing.md / https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit# / http://www.w3.org/2016/07/29-editing-minutes.html 18:11:24 Topic: Clipboard events 18:11:37 LJWatson has joined #editing 18:11:49 GK: We don't want to repeat the readyStateChange problem with beforeInput having lots of switch stuff to figure out what it does 18:12:07 GL: I feel the same way. We fire beforeCopy etc 18:12:12 GK: They were removed 18:12:19 … because they were not that clear 18:12:59 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. 18:13:31 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. 18:13:38 …backing up to give some history 18:13:51 … Keypress was deprecated to be replaced by beforeinput. 18:14:26 … 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. 18:14:50 … as opposed to atomic events for every possible thing 18:15:19 … the choice helped for accessibility, because you won't miss a specific action like key 18:15:25 OV: We already have input. 18:15:47 … makes less sense for beforeinput and input to have mismatch 18:16:16 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). 18:16:23 … a hybrid in the middle seems a bad idea. 18:16:45 … But don;t think this is a generic thing like readyState. Although people may say it is. 18:18:28 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. 18:19:32 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. 18:19:43 GK: What if you want to listen for 12 out of 20? 18:20:00 DT: this is where you want to e.g. listen for "enter", not all keys 18:20:13 MS: If you listen with a filter, does the event still fire more generally? 18:20:22 DT: Yes. 18:20:55 … 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. 18:21:01 … note this is an idea, not a plan. 18:21:28 OV: Are you concerned about beforeinput in general, or specifically on clipboard 18:21:32 GL: Specifically on clipboard. 18:22:01 … beforeInput seems to want to do everything, beforeInput should be user-initiated, but cut/copy/paste might or might not be 18:22:41 GK: We could restrict beforeInput to only user-initiated DOM updates. Would be tricky spec… 18:22:41 OV: Same issue applies to input right? 18:22:56 … but it seems *really* strange for beforeinput and input not to match. 18:23:04 G: We try to make beforeinput cancelable 18:23:08 [except IME] 18:23:14 s/G:/GK:/ 18:23:26 GL: I thought you can listen to the beforeCopy event 18:23:46 OV: That's a different beast. If you preventDefault, it prevents the copy item appearing in the right-click menu. 18:23:56 … happens when you pop up a right-click menu. 18:24:08 … and it's terrible. 18:24:22 GK: And it's gone from the spec 18:24:30 JW: Was only implemented in one browser, no? 18:26:03 [testing...] 18:26:35 Issue where they were removed from the clipboard api spec: https://github.com/w3c/clipboard-apis/issues/25 18:26:41 Hee is Hallvord asking to kill beforecopy https://readable-email.org/list/public-webapps/topic/clipboard-kill-onbefore-events 18:27:14 s/Hee/Here 18:27:29 Grisha_ has joined #editing 18:28:27 GL: If people generally want to have beforeInput instead of beforeCopy, we can go with that. 18:29:04 JW: It is paste that is similar to beforeInput - beforePaste is a different thing relevant to the menus and so on. 18:29:28 GK: Yes, paste is analagous to beforeInput - before DOM is updated, and cancelable. 18:29:46 … does paste always trigger input? 18:29:52 OV: modulo bugs, yes. 18:30:14 GK: Don't think we can get rid of paste, since it's been around, but we would like to replace it with beforeInput. 18:30:23 … if we could get rid of paste and cut, what happens to copy? 18:30:32 … leaving the three around is consistent in that regard. 18:30:51 GL: So if we go with this do we discourage web developers from listening to paste? 18:30:58 GK: i.e. we're deprecating them. 18:31:17 … we cannot do that for copy. So think we should keep paste and cut. 18:31:51 JW: Tried to get the two specs together last year. CLipboard said the browser must paste - cannot stop it. I.e. not cancelable. 18:32:22 … but we were trying to do it the other way around. So clipboard tried to make exception for contentEditable=true, not cE=[other values] 18:33:02 GK: So order would have to be beforeInput, cut/paste, input. Copy doesn't have before/input 18:33:31 JW: What if you cancel beforeCut? Does it not copy at all? 18:34:01 … I cannot cancel a copy to the cipboard - does canceling a cut send something to the clipboard? 18:34:12 rniwa has joined #editing 18:34:28 GK: If you cancel beforeInput inputtype=cut then it should cancel the cutting operation? 18:34:58 JW: Trying to find correspondence between copy and cut… 18:35:47 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. 18:36:32 … if you consider clipboard buffer as part of the DOM, then you can claim some consistency. 18:39:23 [So, what's more surprising: incosistency between beforeinput.inputtype-cut and cut, or cut and copy?] 18:41:42 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. 18:42:48 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? 18:44:07 … 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. 18:44:58 GL: Think user would be surprised if the stuff they cut isn't removed but still gets into the clipboard. 18:46:06 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. 18:49:41 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. 18:50:19 JW: Want to make sure we can do this, because there is user-initiated requirements. 18:51:51 MS: So why do we have beforeinput *and* cut? 18:52:07 GK: Because we cannot get away with removing cut/copy/paste from the web :( 18:53:37 … and so someone can handle beforeinput and always manage to get the events they need. 19:03:31 rniwa has joined #editing 19:13:41 morgan has joined #editing 19:35:34 morgan has joined #editing 19:39:57 Grisha has joined #editing 19:41:03 LJWatson has joined #editing 19:46:09 enrica has joined #editing 19:46:41 johanneswilm has joined #editing 19:57:21 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 19:58:45 OV: input fires in editable regions, but key events fire wherever things can be focused. 19:59:27 GL: If we fire input, we fire beforeinput… 19:59:47 OV: Yeah. at some point we might want to relax that, but will require author opt-in 19:59:53 zakim, next item 19:59:53 agendum 3. "clipboard events" taken up [from chaals] 20:00:00 zakim, next item 20:00:00 agendum 3 was just opened, chaals 20:00:05 zakim, close item 3 20:00:05 agendum 3, clipboard events, closed 20:00:06 I see 10 items remaining on the agenda; the next one is 20:00:06 4. history - undo/redo [from chaals] 20:00:17 OV: who implements undo API? 20:00:31 GL: We do in Edge. 20:00:41 OV: Thought we did, but apparently not 20:00:53 EC: nor webkit 20:01:20 OV: Like cut copy paste: input already fires, our hands are tied. 20:01:41 … should the browser try to work out what changes were made? Think the answer is no. 20:01:56 GL: People who want undo will track their own, rather than go for literally everything. 20:02:22 OV: Wait, misunderstood. If JS modifies the DOM should it go into the history? 20:02:28 GL: What's the use case? 20:02:42 JW: Your editor handles a bunch of stuff, but you pass undo/redo to the browser to handle. 20:03:18 GL: So if you have a browser stack and your own, you want to make sure they don't get interleaved wrong. 20:03:51 JW: Is it possible to let the browser handle undo/redo? 20:04:05 GK: sounds analogous to cut/copy/paste 20:04:23 OV: We wrote a spec to do this, but don't see anyone implementing it. 20:04:31 … browsers are not interoperable here anyway last I looked. 20:04:48 JW: So if I am going to start handling undo I need to handle the lot, right now. 20:05:05 OV: Yes. It would be great to have a standard for that, but won't be now, and is orthogonal to beforeInput. 20:05:18 JW: So beforeinput doesn't have targetrange for undo/redo 20:05:41 GK: Yes, because the info is coming from somewhere else. If you call it, I don't think it is helpful info. 20:05:47 MS: So what does beforeinput have? 20:06:01 GK: fires before the change, has type, don't think there is any other info. 20:06:19 MS: We just want something we can cancel, and handle it ourself. 20:07:23 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. 20:07:33 GK: is undo/redo cancelable? 20:07:37 OV: Should be. 20:07:47 GL: Don't think we fire undo event. 20:07:58 GK: So if nobody implemented it, let's not add the event. 20:08:48 … you can find when undo happened because of undo/redo already, you always get an input. 20:09:25 GL: if we preventDefault an undo, what happens to the undo stack? 20:18:49 CMN: Think it makes sense that if you preventDefault on an undo action the stack should be popped. 20:19:00 [most people: no, that makes no sense] 20:19:09 EC: You should delete the stack 20:19:26 GK: that saves memory. But in the future it means we cannot make an undo manager. 20:19:34 rniwa has joined #editing 20:20:24 RESOLUTION: We don't want undo/redo events outside beforeInput 20:21:14 RESOLUTION: precventDefault on an undo means "don't apply this, no change to the DOM, no change to the undo stack" 20:21:32 s/precv/prev/ 20:21:32 chaals: /me hi's chaals! 20:21:51 agenda? 20:21:59 zakim, next item 20:21:59 agendum 4. "history - undo/redo" taken up [from chaals] 20:22:10 JW: This is about moving stuff from input events to UI. 20:22:23 zakim, close item 4 20:22:23 agendum 4, history - undo/redo, closed 20:22:24 I see 9 items remaining on the agenda; the next one is 20:22:24 5. Non-cancelable event [from chaals] 20:22:28 zakim, next item 20:22:28 agendum 5. "Non-cancelable event" taken up [from chaals] 20:22:53 GK: We need input events never cancelable, or sometiimes, e.g. in IME, it might not work. 20:23:05 JW: for simplicity we said it is never cancelable. 20:23:23 … problem is we write editors for latin that don't work with composition. We want to make that easier. 20:23:44 GK: We have to make an exception for composition, and we should pick the easiest way to make it happen 20:24:03 OV: On the down side, that means in Android nothing is ever cancelable. Other than that, it would be great. 20:24:14 GK: The reality is "it is possibly not cancelable". 20:24:40 OV: If the isComposing flag is true, then Input is possibly not cancelable 20:24:50 GK: And that is in UIEvents 20:25:25 [We would like to make the two specs say the same thing…] 20:25:35 OV: Android may not make it cancelable at all. 20:26:00 … use case is where you write your own editor you want to control everything. 20:26:22 JW: e.g. collaborative 20:26:43 OV: pragmatic thing is to say If composing is true it's not cancelable - for now… 20:27:20 CZ: The very last thing can be cancelable. 20:27:32 … you are finished, the browser is inserting text. 20:28:19 … 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 20:28:40 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. 20:29:20 resehttps://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html 20:30:06 -> https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html keyboard event viewer 20:31:48 OV: if you type into an IME, and the preventDefault, should the stuff I typed remain? 20:31:57 GK: No, it's temporary stuff for the IME. 20:32:53 DT: So I presume the line would stay there… 20:33:00 OV: Staying in IME composition? 20:33:18 DT: The line indicating you're in IME would be there 20:37:24 「pぁいんg」アロウンdウィthイメ 20:39:42 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… 20:40:02 GL: We update DOM before composition 20:40:16 … now we fire compositionUpdate, and the DOM is not updated yet. 20:40:28 GK: We agreed where we would put beforeInput 20:40:38 GL: We were different, agreed we would change to match everyone else 20:40:44 OV: And we had a bug, as well. 20:41:38 … didn't have a final compositionUpdate before compositionEnd. 20:42:33 GK: compositionStart / End don't do updates, only compositionUpdate which have beforeInput, and at the end there is compUpdate, befInput, input, compEnd. 20:42:40 s/GK/OV/ 20:43:11 … so the last beforeInput in that stream, if prevented, will undo the whole composition back to the compositionStart 20:43:24 JW: If you can cancel it, then by definition you're at the end. 20:43:46 GL: When is isComposing flag set? 20:44:02 OV: In each of these cases. 20:45:48 GK: How do I know if we are catching the last thing? 20:46:06 JW: Spec says you have to delete everything and add it again. And Chrome does. 20:46:23 CZ: Doesn't have to be the latest text, could be the english text. 20:46:45 GK: But for japanese that's irrelevant if you're in kana already. 20:46:56 OV: Consistency across here is good. 20:47:19 GK: So in japanese we delete then reinsert as a way to know that we're at the end of the composition. 20:47:26 [testing] 20:48:09 GK: We could optimise away the replacement in some IMEs 20:48:37 OV: The majority of people writing editors don't understand any IMEs. So you're better not having inconsistency, or they break stuff 20:48:55 GK: So we have to have a redundant event, for Japanese. 20:49:11 MS: Why no different type? 20:49:47 GK: We never had a type, in the past. We could say "type=finalComposition" - which sounds nicer 20:49:53 JW: That sounds saner. 20:50:32 OV: This might be good enough to spec it like this and be happy with it. 20:51:28 … so if isComposing is true, and type != finalCompositionStateThingPlaceShedForCycles, then it isn't cancelable. Then we get something that will work for developers. 20:53:38 [break coming fast] 20:54:01 [question about why to have inComposition, and how to stop developers from breaking things by accident] 21:07:22 enrica has joined #editing 21:17:19 morgan has joined #editing 21:17:48 johanneswilm has joined #editing 21:32:51 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. 21:33:42 … and if canceled DOM goes back to how it was before startComposition... 21:34:01 OV: Does that work for Android? You can start composition on existing text. 21:34:47 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… 21:35:17 [so there is spec update to be done, and testing on Android] 21:35:24 zakim, next item 21:35:24 agendum 6. "static ranges" taken up [from chaals] 21:36:10 GK: proposal is consistent with what RNiwa said… 21:36:16 rniwa: ^^ 21:36:26 EC: We were in favour of static ranges. Otherwise we are all fine. 21:36:55 JW: What's the plan for where it lives 21:37:13 GK: Range is a separate spec. static range is probably going to be another thing on its own. 21:37:49 OV: there isn't a spec yet, right? 21:38:02 … maybe we should have one before we ship. 21:41:11 ASIDE: what happens if you undo/redo within composition… [needs testing] 21:41:49 GK: So we take static ranges through the process, I'll edit it. 21:44:09 Topic: data and dataTransfer 21:44:11 agenda? 21:44:19 zakim, close item 6 21:44:19 agendum 6, static ranges, closed 21:44:20 I see 7 items remaining on the agenda; the next one is 21:44:20 7. opt-in/out of editing features and menus [from chaals] 21:44:28 zakim, close item 9 21:44:28 agendum 9, Data and dataTransfer attribute, closed 21:44:29 I see 6 items remaining on the agenda; the next one is 21:44:29 7. opt-in/out of editing features and menus [from chaals] 21:44:51 OV: data property should give same content as datatransfer.getdata text/plain 21:44:58 JW: OK, no problem. 21:45:08 OV: Do all beforeInputs have dataTransfer? 21:45:15 JW: not now but we can make that so. 21:45:31 OV: or we can make them have only one. 21:45:36 GL: undo doesn't have anything 21:46:06 JW: Now only clipboard and DND have this - the only one with data is insertText. I can expand it… 21:46:43 … bold, italic, etc has a targetRange but no data or transferData 21:46:52 s/dataTransfer/transferData/ 21:46:58 s/dataTransfer/transferData/ 21:47:13 OV: insertNonText ? 21:47:25 JW: Was replaceContent, and people agreed to change it 21:47:57 OV: nonText is weird. Something like insertComplicatedStuff, or HTML, or whatever. This is bikeshedding, but I don't like the current colour. 21:50:36 … do we really need it at all yet? 21:51:20 JW: a spellcheck that replaces stuff running across element boundaries, not from a user typing. 21:52:31 CMN: Maybe a live translation system. 21:55:02 MS: I see value between a user input event and something done by another system like spellcheck. 21:56:25 GK: So to return to the data / transferData issue - do we have both? Is there transferData everywhere that is nice for consistency? 21:56:39 OV: What about bold… there are nonsensical place to have it. 21:57:20 DT: transferData seems heavyweight for things that don't need it. 21:57:45 OV: DnD and CCP (cut copy paste) need it. Also insertRichStuff would. 21:58:01 JW: Seems odd that there are data sometimes and transferData others. 21:58:47 OV: We could put both onto DnD, CCP, and insertRichStuff and insertText, with data as a shortcut. 21:58:53 GL: The redundancy bugs me a bit 21:58:56 OV: me too. 21:59:22 GL: how often will it be used? 21:59:30 OV: Depends on the command… 21:59:49 … if they are doing transferData on insertText, that's stupid expensive. 22:00:20 … propose: insertText has data, DnD and CCP get transferData. 22:00:35 DT: We have a table in the spec to show which ones are valid? 22:00:39 JW: Yep. 22:01:03 rrsagent, this meeting spans midnight 22:01:47 GK: so insertText has transferData = null. 22:02:06 OV: We need to be sure its transferData or dataTransfer... 22:02:09 [scribe agrees] 22:02:25 [It is dataTransfer] 22:02:56 JW: There is a different name for it in clipboard API 22:03:17 GL: So for CCP and DnD, data will be null. 22:03:20 For the notes if the spec could have a table that looks similar to this: https://w3c.github.io/pointerevents/#pointer-event-types 22:04:00 RESOLUTION: CCP and DnD have dataTransfer an data=null, insertText is vice versa. 22:04:18 zakim, next item 22:04:18 agendum 7. "opt-in/out of editing features and menus" taken up [from chaals] 22:04:32 GK: There is no good technical answer here :( 22:05:04 DT: This applies to virtual keyboard, whether there is a bold option, etc. 22:06:02 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. 22:06:15 OV: You can use inputmode with the input event, but otherwise no… 22:06:26 EC: iOS does this driven by input type. 22:06:32 DT: Same class of problem. 22:06:51 JW: Especially problematic that menus pop up we cannot remove, but try to do things the user cannot use. 22:07:10 GK: New feature is released - what does current code do - are they opted in or do they update their code to get the feature? 22:07:45 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? 22:08:08 MS: People want to lock down some options, and don't want a context menu to bypass that and offer other stuff. 22:08:23 GL: What if we have a binary - you can disable formatting buttons. 22:08:37 OV: High priority is which virtual keyboard - that's what people want. 22:09:02 EC: Would be the same for the entire element - you won't switch keyboard as you move around the block. 22:09:30 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. 22:10:36 MS: You can't just disable the context menu to stop bold appearing because you want e.g. copy 22:10:50 EC: Ideally you have a set of commands and let the application choose which ones are available. 22:12:05 … This isn't the same as the keyboard problem. 22:12:11 CMN: Can we use inputmode? 22:12:43 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. 22:13:09 DT: You might want e.g. autocapitalise. On Android you roll these into flags for the keyboard. 22:14:42 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. 22:15:03 DT: iOS has ascii, phonepad, email, twitter, phone number, etc... 22:15:34 OV: Let's take the intersection of iOS+Android, and then add things if people convince us 22:17:12 CMN: We can replace inputmode as specced - and unimplemented - with this. It's a simple list of labels and keys that should be there. 22:17:24 OV: Sure, unless that upsets people and we can change the name. 22:17:46 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. 22:18:54 … on a more fine-grained basis. Is it possible to have a command to disableAll, and enable(individual) menu components? 22:19:17 GK: So by default you opt in to new features, although you can opt out of everything and choose everything you want. 22:19:36 OV: Apple are the only ones who do this now, so they should make a proposal and everyone else will say "sure"... 22:19:54 … think we should wait for Apple's proposal 22:20:24 … having opt-out all and then opt back in, is super painful. 22:20:33 GK: There isn't an obviously right answer. 22:20:58 GK: Does that block anything or is it orthogonal and not holding anything. I think and hope so. 22:21:27 JW: editing software developers want this, but no it doesn't interfere with standards work - only reality. 22:22:11 RESOLUTION: We're waiting for Apple's proposal to discuss at TPAC regarding opt in/out of commands. 22:24:01 RESOLUTION: We will spec up the list of inputmode (or whatever we call it) for selecting keyboards. 22:24:32 garykac has joined #editing 22:24:34 -> https://w3c.github.io/html/sec-forms.html#input-modalities-the-inputmode-attribute in W3C HTML 22:24:52 zakim, next item 22:24:52 agendum 8. "relation to execCommand" taken up [from chaals] 22:24:57 GK: OMGNo! 22:25:29 JW: Made a proposal about reasonable execCommand things - but not all of them are there. If things are missing, please speak up. 22:25:44 GK: seems like a small number should come over. 22:25:55 GL: Think it is close to 37 things. 22:26:06 GK: Think most don't have corresponding beforeinputtypes. 22:26:20 https://github.com/w3c/editing/issues/79 22:26:48 OV: All we need command types for are things built in to the user agents that the user can trigger 22:26:52 s/79/110/ 22:27:44 OV: 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. 22:27:55 GK: And spec should not require implementing them all to conform. 22:28:00 OV: LGTM. 22:28:14 zakim, next item 22:28:14 agendum 10. "IME for european languages on long-press keyboard" taken up [from chaals] 22:29:03 JW: You hold down a key, and then you get a menu for accented characters. If we cancel on keydown, that breaks. 22:29:49 … if we preventDefault on getting the 'e' we don't get the menu. 22:33:54 DT: if you do the preventDefault on beforeInput instead of on keyDown, the problem goes away... 22:35:33 Grisha has joined #Editing 22:38:24 RESOLUTION: Use preventDefault on beforeInput instead, and magically the world will be better. For now. 22:45:17 present+ esprehn 22:45:58 johanneswilm has joined #editing 23:00:28 Topic: MozActionHint 23:00:40 DT: Lets you adjust the text of the enter key on virtual keyboard. 23:00:57 … iOS has some predefined ones, with this you can set values. 23:01:10 … want to make this work on Android. 23:01:28 … specified on the input field - will have to specify something similar for HTML, so it effects cE 23:02:07 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… 23:02:13 EC: I'll dig it out. 23:02:26 RESOLUTION: make it so (sort out mozActionHint) 23:03:56 Topic: Publishing or leaving things asleep 23:04:05 OV: static range needs a spec first. 23:04:21 JW: contentEditable modes isn't sleeping but maybe should be moved forward. 23:04:27 … input events too. 23:54:31 chaals has joined #editing 23:54:56 rrsagent, draft minutes 23:54:56 I have made the request to generate http://www.w3.org/2016/07/29-editing-minutes.html chaals 03:47:44 morgan has joined #editing 14:44:07 chaals has joined #editing 14:53:31 chaals has joined #editing 15:12:55 chaals1 has joined #editing 17:37:29 chaals has joined #editing 19:54:14 chaals has joined #editing 21:00:05 chaals has joined #editing 21:58:21 chaals has joined #editing 21:37:55 morgan has joined #editing 07:57:03 chaals has joined #editing