00:40:24 jyasskin has joined #webapps 01:36:28 I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html xiaoqian 02:06:20 meeting seems to have ended sorta abruptly 02:07:26 in medias res 03:56:08 Florian has joined #webapps 04:30:41 grisha has joined #webapps 06:34:24 grisha has joined #webapps 06:35:32 grisha has joined #webapps 07:15:57 johanneswilm has joined #webapps 07:23:31 dom has joined #webapps 07:37:27 wilsonpage has joined #webapps 08:01:39 enrica has joined #webapps 08:03:03 weinig has joined #webapps 08:06:42 chaals has joined #webapps 08:07:35 Florian has joined #webapps 08:18:01 weinig has joined #webapps 08:18:43 grisha has joined #webapps 08:20:54 rssagent, pointer 08:21:31 rssagent, help 08:22:53 rniwa has joined #webapps 08:27:08 Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan 08:30:01 johanneswilm has joined #webapps 08:30:04 trackbot, start meeting 08:30:06 RRSAgent, make logs public 08:30:08 Zakim, this will be DOM3 08:30:09 Meeting: Web Applications Working Group Teleconference 08:30:09 Date: 24 August 2015 08:30:51 trackbot, point 08:30:51 Sorry, Florian, I don't understand 'trackbot, point'. Please refer to for help. 08:30:56 trackbot, pointer 08:30:56 Sorry, Florian, I don't understand 'trackbot, pointer'. Please refer to for help. 08:31:01 rssagent, point 08:31:02 rssagent, pointer 08:31:37 Meeting: Editing TF face to face 08:32:38 rssagent, log 08:32:55 https://github.com/w3c/editing/issues/77# 08:33:14 rrsagent, pointer 08:33:14 See http://www.w3.org/2015/08/24-webapps-irc#T08-33-14 08:34:01 Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan 08:34:18 Scribe: Florian 08:34:36 wilsonpage has joined #webapps 08:35:32 tantek has joined #webapps 08:35:56 Agenda: https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting 08:36:05 Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan, tantek 08:36:18 hello 08:36:53 PiotrekKoszulinski has joined #webapps 08:39:46 Enrica: Should we keep talking about multirange selections? 08:40:00 Florian: let's do that when we have mozilla on the phone later today 08:40:47 Chair: chaals 08:41:56 chaals has joined #webapps 08:42:33 Johannes: Ehsan will call at 2pm. We will talk about selection normalization then as well. 08:43:18 Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan, tantek, chaals 08:44:08 chaals1 has joined #webapps 08:44:28 rrsagent, draft minutes 08:44:28 I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html chaals1 08:45:33 scribe: chaals 08:45:45 agenda? 08:45:50 zakim, agenda? 08:45:57 Agenda: https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting 08:46:27 chaals1 has changed the topic to: Editing TF f2f. Ping us for remote connection. minutes: http://www.w3.org/2015/08/24-webapps-minutes.html 08:47:52 Topic: input events 08:48:34 https://github.com/w3c/editing/issues/72 08:48:43 JW: looking at issues 71 and 72, wonder if we should change the name of events, or keep it but make it clear that this is only for cE, or deal with input/textarea events (later?) 08:48:56 … stuff do deal with selection should be in the selection API. 08:49:12 … but they need the intention of what the user wanted to do… 08:49:20 s/71 and 72/72 and 73/ 08:49:29 RN: Fine to spec in selection. 08:49:57 … caret is a type of selection… 08:50:21 JW: What about name - does it apply to input fields as well? 08:50:59 RN: interesting question - what happens in a multi-range selection. Do we fire beforeinput events with multiple ranges, or multiple single events one per range? 08:51:03 JW: don't mind 08:51:23 FR: Think it is better to have a single event with all the data to eenable doing smart things 08:51:29 SW: so targetRanges? 08:51:39 Johan: then we need an array for the ranges. 08:51:47 … you can delete at multiple locations 08:52:04 RN: There isn't a way to insert different characters in different locations 08:52:20 FR: You can put the same data in multiple places at once... 08:52:31 SW: But it is the same data and three targetRanges 08:53:10 JW: So we need targetranges? 08:53:12 [yes] 08:53:54 JW: Input on what to do with input? 08:54:12 FR: This is pretty different, making it apply is odd. The name is confusing. 08:54:20 EC: Call it the editing event? 08:54:30 JW: beforeEditing? 08:54:39 EC: yeah, beforeEdit … 08:54:53 JW: Only applies to contenteditable, right? 08:55:08 PK: We have beforeinput on ce=true 08:55:19 s/beforeinput/input/ 08:55:41 JW: Input events have change and input. ce has input and what we call this... 08:55:46 SW: Problem? 08:55:58 FR: beforeinput doesn't work on input elements 08:56:24 [what the input event does] 08:57:52 https://developer.mozilla.org/en-US/docs/Web/Events/input 08:59:49 FR: There is already a beforeinput event 09:00:00 JW: This spec has different fields for the event 09:01:37 … so can we override the other event, or should we call ours something else - beforeEdit? 09:01:46 … don't mind which. 09:01:55 FR: Ours is supposed to be the same as the general one, no? 09:02:01 http://w3c.github.io/editing/input-events.html 09:02:08 JW: Thought so, but seems not. 09:03:11 EC: In webkit we fire input events for input/textarea events... 09:03:31 … so they seem to be disjoint. 09:03:41 … Why don't we go completely disjoint? 09:05:36 JW: Think it is a good idea to have a different name. 09:06:35 PK: We should check other browsers too... 09:08:00 [should we use the input event? no, having multiple events of the same name leads to confusion] 09:08:19 PK: There is apparently input n ce in firefox but seems broken 09:08:21 http://jsfiddle.net/hxh4ybsf/ 09:09:07 Johan_S_rlin has joined #webapps 09:13:56 [does pgup pgdn move the caret? Sometimes, but not others] 09:14:58 SW: We could spec it, but it would never fire in Safari 09:15:19 RN: it needs to fire in selection... 09:15:40 … so if we spec it that means we would need to support it 09:15:51 EC: Moving caret by a page isn't deterministic… 09:17:18 CMN: Not unusual for a user to do that though 09:17:33 SW: Wonder if we should be linking up everything that platforms can do. 09:18:01 … we *could* implement this - but think we're ratholing something that isn't that important. 09:18:39 RN: We wouldn't trigger this from user actions 09:18:52 SW: But if authors want to make something, good luck to them. 09:20:37 RESOLUTION: remove caret, and put it in beforeselectionchange in selection API 09:21:21 RESOLUTION: We call the relevant events edit and beforeedit (instead of overloading input) 09:21:44 EC: If we do this let's have home, start/end of doc, etc etc 09:22:16 RN: Home is line boundary, ctrl-home is document boundary 09:24:11 EC: So we are left with the things that are not selection… insert/replace char/text/content, un/do 09:24:41 RN: Why do we need different things for replacing text or content? 09:25:01 JW: Don't suppose we do. Lets get rid of replaceText and make it content. 09:26:00 RN: Might want to add another boolean for spellchecking 09:26:48 CMN: Does it matter? 09:27:04 EC: If you want to do visualisation ... 09:27:16 RN: IME will also do replacecontent 09:28:07 FR: The boundary between typing and spellchecking is fluid 09:28:37 EC: So this comes from the browser saying it wants to autocorrect something? 09:30:29 [is there a fingerprinting issue with noting something is autocorrected?] 09:32:27 [probably - you can see the dictionary, and how often people are making mistakes. But what's the real problem?] 09:32:37 SW: Don't think there is a real problem here 09:32:45 FR: What's the value in doing this? 09:32:58 PK: e.g. so you don't move the selection there 09:33:13 JW: That's why replacecontent should not move the caret. 09:33:44 SW: This would also happen on dictation, where words that were put there are updated later. 09:35:41 [When you replace content, the offset for the cursor is probably different…] 09:36:25 weinig has joined #webapps 09:36:57 JW: Whatever the common behaviour is when content is replaced, keep doing that… 09:37:48 https://github.com/w3c/editing/issues/25 09:37:49 JW: MS Office team want to know the source for the edit event… #25 09:39:06 lya: if you have a floatingUI that comes up when you select something, you need to know how the selection happens 09:39:24 FR: so you get different behaviour depending on whether you used keyboard or mouse? 09:39:39 Ilya: Are they asking for this to be specified 09:39:48 JW: yes… 09:43:02 [do they need to know what they are actually asking here - what a given keyboard event will actually fire…] 09:44:44 SW: issue is that we don't support progressive enhancement and we need a viable way for that to happen… 09:45:17 FR: A browser may have an event type, but not actually fire it ever… 09:47:34 CMN: feature detection breaks… 09:48:14 SW: This is hard because our events fire after the old event, so you don't know if it will trigger the new event… 09:48:32 EC: Why not do something similar with execcommand - would that be crazy? 09:48:47 SW: Not for knowing the source of the event, but that is a different problem. 09:49:13 … hard part is knowing the set of sources 09:49:33 EC: We could have an enum that we can extend. 10:07:18 johanneswilm has joined #webapps 10:08:16 weinig has joined #webapps 10:10:06 Topic: can we do progressive enhancement… 10:10:11 SW: remains an open issue. 10:10:12 grisha has joined #webapps 10:10:19 CMN: there are a lot of gotchas, too 10:10:31 s/Ilya/Grisha/G 10:10:51 Topic: Can we put the source? 10:10:59 JW: That's not so hard, right? 10:11:07 FR: listing things isn't a great idea 10:11:09 PiotrekKoszulinski has joined #webapps 10:11:38 Grisha: So we need a table of accelerators to fire a function… who maintains that? 10:11:43 JW: Your browser. 10:12:22 FR: That's the problem with the list - you don't know what to do with a source you didn't know about in advance 10:14:32 CMN: see also Brian Kardell's input-modality proposal in WICG 10:14:40 RN: Can we have a relatedEvent? 10:14:56 SW: Sometimes. But not if find causes a selection. 10:17:13 CMN: We don't really want authors listening to device-specific events, because they make a mess of it… 10:17:36 FR: Authors should not have to care about dev-specific events, but they should be able to care… 10:19:15 SW: Don't think supporting this is high priority 10:19:37 CMN: Maybe not, and it will probably be misused more than well used, but authors really really want it all the time :( 10:21:14 RN: If you have a timer to check whether an intention is for a particular keydown, we cannot guarantee the association. 10:21:41 SW: Having a pointer to the event that caused something, or null, might be enough. 10:21:51 RN: That would more or less address the use case. 10:22:20 FR: There is a risk that people will make assumptions about why they get null… 10:22:36 SW: Don't think it is a huge issue 10:23:13 RN: What if a combination of events were the cause of a single DI event? 10:23:27 SW: last one? Still don't think this is an important problem to solve. 10:24:33 RN: You want to prollyfill, so if there is a ctrl-C you set a timer to see if it fired a copy… and if it didn't, you fire one. 10:27:14 JW: you want to know what things are working... 10:28:06 weinig has joined #webapps 10:28:46 SW: So #19 and #25 are the same thing? 10:30:31 CMN: similar… 10:30:47 FR: So the relatedEvent thing is probably not that bad... 10:34:12 TC: Maybe you really should record a use case of supporting polyfills 10:35:28 RESOLUTION: have a relatedEvent to point to the UI event that caused a DI event to be fired. 10:38:29 Filed https://github.com/w3c/editing/issues/78 10:39:11 Topic: Deleting content 10:39:31 Grisha: is there a reason to have the 3 different delete events? 10:39:49 JW: If people click delete button or backspace, you have different things happen. 10:40:12 … if you build track changes you get the intent to delete forward, move the caret 10:40:46 EC: can we have one delete event and use attributes? Ditto for insertCharacter/Line 10:41:23 RN: There is a difference between line break and paragraph break. 10:42:18 … don't think we want to collapse lines and characters - and would like to have a way of inserting a paragraph. Agree that we should have forward/backward as an attribute on the delete event. 10:43:17 weinig has joined #webapps 10:45:16 [A use case for delete backwards - tracking changes means that the delete thing doesn't remove the content, but marks it and moves the caret backwards] 10:52:26 EC: When do we fire deleteContent? 10:52:33 RN: A default of keypress 10:52:43 FR: The default will be forward or backward 10:53:23 … we don't need deleteContent if it is only for an edge case 10:53:38 EC: So if someone presses an "h", what do I fire? 10:56:43 [insertcharacter, or replacecharacter] 10:56:58 weinig has joined #webapps 10:57:13 CMN: with a delete event that has forward/backward, if it has neither then it is basically replace with nothing 10:59:20 FR: The problem is if you are listening for delete, when sometimes what is fired is a replace with empty, then you get complexity. 11:00:19 weinig has joined #webapps 11:01:09 RESOLUTION: one delete event with data for forward/backward 11:02:21 FR: Typing/replacing at caret/selection uses insert, doing it elsewhere uses replace 11:02:34 RESOLUTION: We want to be able to insert newline or new paragraph 11:03:40 [lunch] 11:55:01 weinig has joined #webapps 11:56:05 enrica has joined #webapps 11:56:26 chaals has joined #webapps 12:04:00 Present+ Ehsan(videconf) 12:04:07 Florian has joined #webapps 12:04:33 Present+ Johannes, Johan, Chaals, Ryosuke, Grisha, Piotr, SamW, Enrica, SimonS, Tantek 12:04:41 Topic: selections 12:05:01 Ryosuke: If we allow JS to set selection, can we always render a selection caret? 12:06:22 … we currently do normalisation of selection endpoints, but going forward we want to change that. 12:06:48 EA: Gecko tries to be permissive, ask where the selection goes and try to get a caret there. 12:07:19 … there are edge case bugs, but we restructured this a few years ago which helped in a bunch of situations for getting carets where we couldn't. 12:07:45 … So things are better, but it isn't perfect yet. It is impossible to predict every possible place to put the caret. 12:08:13 RN: Would you be OK with not doing normalisation? 12:08:54 ehsan has joined #webapps 12:09:03 the audio feed stopped 12:09:06 Is Gecko okay with not normalizing selection when JavaScript modifies it 12:09:06 rniwa: ^ 12:09:19 yes, in the abstract sense :) 12:09:20 rrsagent, draft minutes 12:09:20 I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html chaals 12:09:58 PiotrekKoszulinski has joined #webapps 12:10:11 RN: Current proposal is not to normalise selection when JS modifies it. 12:10:23 … do we need to specify a guarantee of wher the caret can be? 12:10:29 smaug has joined #webapps 12:10:37 … e.g. we cannot render a caret in an element with display none. 12:10:54 … also in a japanese IME in composition there is often no caret. 12:11:04 … Can these be specified? 12:11:22 EA: Harder cases are where selection goes into part ofthe DOM that is obscured by another element. 12:11:43 examples of where the caret doesn't go or doesn't render: https://bug873883.bmoattachments.org/attachment.cgi?id=751510 12:11:57 … Or where user places caret next to an image. Should we render it on the border of the image? 12:12:19 … How does it combine with background colour of image… 12:12:41 … There are some other tricky cases. The button element - should it go inside it or not? 12:13:13 … there is a text node underneath it, so it makes sense to be able to edit that, or it is a form control and it makes no sense to allow editing it… 12:13:39 … there is value in specifying how the browser deals with these situations. We can normalise things, or list the possible cases… 12:14:40 JW: e.g. can't get between two canvas elements immediately adjacent in Firefox, can go between SVGs, but cannot in Chrome, etc... 12:14:54 … do we want a guarantee of where things will go? 12:15:47 EA: 2 cases to consider - caret when you are using keyboard to navigate, and when JS moves it. There are many places where you cannot get a caret with user navigation keys, but can do it wiith script. 12:16:16 … There are 2 classes of problems, some putting the caret there and some painting it. 12:16:34 RN: yes, we have those 2 kinds of issues. 12:16:54 EA: 3rd question - whether we should do caret navigation through the DOM or the rendered page. 12:17:23 … Gecko does screen-based navigation - sometimes weird but often better. 12:17:53 tantek has joined #webapps 12:18:06 JW: We left how the caret moves unspecified for now. Important thing is that you can get the caret "everywhere it should" and be rendered there 12:19:09 … we want to avoid cases where the caret is now where it looks like it is. We realise there are places you cannot get to, but if we can move the caret there with JS that shoud be enough. 12:19:11 Florian has joined #webapps 12:19:20 RN: Browser bugs *will* exist… 12:20:14 EC: Idea is that with JS you can place selection anywhere, and there will be no attempt to move it to be visible. So if it is put into an invisible element you just won't see it, but that will be a legitimate thing to do? 12:20:36 JW: In certain places we want a guarantee that the caret will be rendered. 12:21:02 RN: Don't think we need a restriction - I think it is premature to spec a list of places where carets must be rendered. 12:21:19 … we need implementation experience of not normalising first, and need to fix caret-painting bugs. 12:21:57 EA: Now position of caret is not observable by script. Are we going to add that? 12:22:20 RN: Think we are still using collapsed selection. We discussed this yesterday 12:22:46 … at boundary of bidi levels we could have two caret positions, so there would be two rectangles. 12:22:56 … We need to sort out carets in vertical mode, too. 12:23:28 EA: Collapsed selection is probably OK. Not sure it is useful for authors, but it is what we do now. 12:24:15 FR: Logical position of caret is offset, plus bidi level, plus if you are at a line break. This gives enough to find out where you are, or to specify where a caret should be. 12:25:54 RN: Discussed adding a new selection object. Current selection API seems to be misused. Argument that one reason is the interface makes it hard to understand that you have to get the counts and collect them, so Ojan selected we have an iterator of ranges that may help get better quality support. 12:26:27 … in multi-range world, the fact we have anchor, etc, looks like a single range and not so smart for a set of them. 12:26:49 … So if we have a multiple range selection in a new API, we can carry caret information better. 12:27:20 FR: Other issue motivating a new selection API was a desire for non-Live nodes… 12:28:46 EA: Performance implications for keeping ranges alive… supporting multi-range selections, do other vendors want to do it? 12:29:35 RN: Apple is - for example so you can select content visually when different boxes are laid out and aren't in DOM order. 12:30:05 FR: And selecting rectangles on a touch device… 12:30:20 … selecting across a user-select: none thing… 12:32:03 EA: We can enable users to select multiple things at a time - another example is selecting table cells. 12:32:25 … how many of these cases do we want to expose? (not all of them are necessary to support) 12:33:07 … Multi-range selection is very very difficult to implement properly - there are lots of points in code that need to deal with it. 12:33:37 … So it is great for the user, but very hard for the engine. 12:34:56 FR: If we let JS author create selections however tehy want, they can create e.g. overlapping ranges. We considered throwing exceptions to stop that, and backed off to say we would allow overlapping selections, only normalise if you tried to exec command, otherwise leave it up to the scripter to decide how to handle their weird results 12:36:25 EA: Seen pages put selections in places that make no sense. Hard to say what the right behaviour should be. Whatever we choose, we want to be consistent across browsers. 12:37:43 weinig has joined #webapps 12:37:50 FR: Do you mean problem rendering selection, or how the selection braks exec comman in e.g. overlapping ranges 12:38:29 EA: We e.g. display visual selection behaviour selecting a run from RTL to LTR, but select logically, which is of course a bug 12:41:16 FR: If an editor wants to e.g. allow visual selection across bidi boundaries, they need multiple ranges and don't want the selection to move from under them? 12:41:58 PK: We like gecko's behaviour because we know where it will put text. For multi-range, allowing table selection is interesting even though it can be faked if it isn't supported. 12:42:45 EC: How does gecko handle copy? Do you take a single fragment or keep a set of fragments on clipboard? 12:43:34 EA: we iterate over each one, don't remember how we handle the gap… 12:43:57 … *think* we put some break between the ranges 12:44:14 FR: Seems like you put double line break between fragments. 12:44:56 EC: What happens if you copied 3 disjoint things and try to paste into 2 ranges. 12:45:31 FR: You replace the first range with the whole clipboard, and just delete the second range. 12:47:00 EA: This is an example of where correct behaviour is non-obvious. E.g. select items from an ordered list and an unordered list nested, and delete things so you promote list items from the sub-list to the parent list. 12:47:44 … ther are a lot of these tricky cases where we just do *something* because there is no sane behaviour. 12:48:24 FR: Tables are an example of where there is an obvious behaviour that is hard - e.g. copy column and paste to another column should not paste the column into the first replaced cell, but … 12:48:57 EC: WOuld be easy to leave it up to implementation what to do. 12:49:24 FR: The browser should do the simple and predictable thing, and leave it up to JS editor developers to customise behaviour in smarter ways. 12:49:50 EA: I am sure there are cases where it is hard to come up with "the simple predictable behaviour". 12:51:51 RN: Think the current plan for ce=typing is for each app to implement bolding, underline etc themselves, so they decide on what "sensible behaviour" is. 12:52:29 … if we want to let app decide what to do with multi-range copy/paste, we need to have the information available about where each piece came from. 12:53:33 … cut/paste multi ranges in the same place should look like a noop… which takes lots of information about what is in the clipboard 12:54:15 FR: We have beforeedit that says what is going to happen, but in order to do the smart thing, you need to have the structure available 12:54:28 … don't need to stitch together in the clipboard, do we? 12:55:00 RN: Stitching may not happen in clipboard. It doesn't assume there are multiple pieces in the clipboard - there is no way to support that 12:55:15 SW: Yes you can, at least on Mac, annotate types and multiple pieces. 12:56:21 EA: Even if clipboard understands format, you are bound by common denomiator of different clipboards. As far as I recall there is no clipboard that allows for multiple pieces somewhere, so gecko needs to stitch the pieces together. 12:56:33 EC: There is also the issue of exposing this to the clipboard API. 12:57:32 jyasskin has joined #webapps 12:57:35 FR: If you don't have multi-piece clipboards, you may be able to intercept the copy event and annotate with extra information, but then those annotations will do weird things e.g. on paste inot a different application. 12:58:10 EA: You can copy different formats at the same time. If the goal is to have copy-paste within the browser, you can invent your own format. 12:59:34 … Paste into another application would show there is text/html (stitched) or magic-firefox-clipboard-format… would that be good enough, or cause problems because you can't paste from FF to IE? 12:59:47 RRSAgent, make minutes 12:59:47 I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html MikeSmith 13:00:00 FR: Or copy HTML table and paste into Excel 13:00:22 RN: We could spec the annotation we add in a browser to provide structure information… 13:00:54 … if that were supported across browsers it seems other apps could recognise it too. 13:01:44 EC: Not sure we should specify the clipboard format for native platform… we should specify what goes there to use with clipboard API 13:02:35 … anyone can specify as many formats as they want to post to clipboard. Think we should aim for copy/paste consistency within an app, not so sure we need to have fidelity copying from one browser to another. 13:03:07 FR: If we manage to get this working for a given browser, then maybe we can go to a standard clipboard format 13:03:23 RN: Browser vendors can't change the format, it is an OS-based format they use. 13:03:41 FR: But we can standardise an additional format that we could put in which is interoperable. 13:03:55 SW: We don't need to debate this now if it is a "later on" feature. 13:06:01 Topic: deleting… 13:06:21 FR: We thought we had a non-overlapping set of things for when to delete and when to replace… 13:06:45 … but what if you do alt-backspace - delete something that isn't selected, but with direction. 13:07:19 … if delete doesn't have a range other than selection you cannot use it for e.g. previous line… 13:07:48 EC: Thought these were low-level events where you got the info backwards/forward. Now you are asking for more commands, like word or line. 13:08:04 JW: If the caret moves, why not select the word and then delete it? 13:08:32 FR: Yes, we could do that. Perhaps save previous selection, delete the word, restore ... 13:08:53 FR: If browser has a native deleteWord, it is a thing that it would do. 13:09:07 … depends on how that is implemented, maybe it already does the right thing. 13:09:29 JW: So the caret moves, so I think we are fine. 13:10:33 PK: What if I cancel the deletion but not the selection of the word before that. 13:10:41 JW: Tough luck… 13:10:50 jyasskin has joined #webapps 13:10:58 FR: You don't know that you get select in order to delete. 13:11:18 CMN: If you have relatedEvent then perhaps you do... 13:11:29 RN: WHy not targetRange? 13:11:43 FR: There isn't one on delete, only on replace. 13:11:55 … otherwise there is overlap between delete and replace. 13:12:03 RN: Don't think that is an issue. 13:12:10 … we can spec them around this. 13:12:33 FR: Yes, but that is harder to make happen. 13:13:43 RN: All commands should always work on target range. 13:14:22 EC: So what happens in ce=typing when user types "hello". I select "lo", press delete. What events come out? 13:14:41 RN: targetrange are those characters, will delete backward. 13:15:08 EC: and user presses "delete word"? Webkit changes selection to select word, deletes. 13:15:30 RN: Same. select the content, delete backward with targetrange as what was selected. 13:15:45 [chaals leaves] 13:36:23 is the meeting still going on? 13:37:04 is somebody else taking notes elsewhere? (etherpad or something) 13:46:27 smaug has joined #webapps 14:03:24 MikeSmith - meeting is over 14:03:36 tantek: ah ok 14:03:38 thanks 14:03:39 notes were all in IRC - no separate etherpad AFAIK 14:03:47 ok 14:04:04 chaals just sorta seemed to drop the mic there 14:04:11 today and yesterday too 14:04:12 rrsagent, make minutes public 14:04:12 I'm logging. I don't understand 'make minutes public', tantek. Try /msg RRSAgent help 14:04:21 rrsagent, pointer 14:04:21 See http://www.w3.org/2015/08/24-webapps-irc#T14-04-21 14:04:32 rrsagent, make minutes 14:04:32 I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html tantek 14:05:16 shepazu has joined #webapps 14:23:42 Florian has joined #webapps 14:49:07 johanneswilm has joined #webapps 15:22:44 Florian has joined #webapps 15:25:34 Spocke has joined #webapps 15:34:21 Lachy has joined #webapps 15:44:56 Florian has joined #webapps 15:46:14 tantek has joined #webapps 16:02:44 Florian has joined #webapps 16:37:41 marcosc has joined #webapps 16:43:40 marcosc has joined #webapps 16:46:16 jyasskin has joined #webapps 16:58:50 jsbell has joined #webapps 17:15:11 wilsonpage has joined #webapps 17:46:12 marcosc has joined #webapps 19:21:26 wilsonpage has joined #webapps 19:22:50 shepazu has joined #webapps 19:26:47 wilsonpage has joined #webapps 19:34:02 shepazu has joined #webapps 19:35:15 wilsonpage has joined #webapps 19:45:54 johanneswilm has joined #webapps 20:25:28 Florian has joined #webapps 20:30:09 tantek has joined #webapps 20:30:27 johanneswilm has joined #webapps 20:40:15 Florian has joined #webapps 20:46:29 Florian has joined #webapps 21:24:40 weinig has joined #webapps 21:38:32