08:17:19 RRSAgent has joined #webapps 08:17:19 logging to http://www.w3.org/2015/08/23-webapps-irc 08:17:30 rrsagent, make log public 08:17:39 Meeting: Editing TF face to face 08:17:41 Chair: Chaals 08:18:33 Present: Chaals, Ryosuke, SamW, Enrica, SimonS, Grisha, Ojan, Piotr, Florian, Johannes, Johan 08:18:59 enrica has joined #webapps 08:19:29 https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting 08:19:32 weinig has joined #webapps 08:19:40 agenda+ make an agenda 08:21:19 scribe: chaals 08:21:40 Ojan: Interested in all three specs - input, selection and typing 08:21:53 s/typing/ce=events 08:22:13 RN: Not clear whether ce=events and input events are different enough to need differnt specs. 08:22:48 JW: One is the host for the other. Inputs has events that should fire on the old contenteditable, whereas new one isn't going to work backwards. 08:23:34 RN: Not convinced. If we want to make it so JS sets selection the browser doesn't normalse it, that should be always, not just sometimes. 08:24:51 Ojan: Have some detailed thoughts on minor things… 08:25:18 … high level thoughts: Like providing lower-level primitives people can build on. Ideally we implement a subset of cE=true. 08:25:47 … so cE would be like sandbox, with a list of things it enables. E.g. true, or, "events something other thing" 08:26:00 … would make sense to split events, one part enabling events aother enabling text input. 08:26:11 JW: it doesn't currently enable text input. 08:27:39 Johan: maybe movements should be a different thing from text input, layering features. 08:27:52 JW: That has been discussed the last week - should we have caret movement? 08:28:15 agenda+ caret movement 08:28:21 agenda+ selection 08:28:30 agenda+ IME and the DOM 08:28:49 agenda+ multi-range selection 08:29:26 Topic: Caret movement 08:29:52 JW: There are things we don't know about that happen in the browser, and some of what we are hearing is contradictory - can we change contentEditable or will it break everything? 08:30:28 … so for example @@ has been sayign we need something new if we are going to change the normalisation of selection, but that can't be changed or we break the web. 08:31:01 … And I don't know if that's the case. Unclear to me with caret movement - if you reove normalisaiton of selection, can you have caret movement and will that break the selection? 08:31:21 RN: You mean if the caret is rendered elsewhere? 08:31:29 JW: If it is actually moved into eg a bit of SVG. 08:31:39 RN: Think that is something that we could fix as bugs. 08:32:56 … if the element is not visible we cannot render the caret, but that's obvious 08:33:23 JW: WIthout normalisation of selection the browser handles the caret movement but the caret can disappear sometimes so you need to implement it in JS already. 08:33:52 EC: If you let JS handle movement there could be a place where the caret goes and the browser cannot render one e.g. where there isn't a height computable. 08:34:02 JW: You normalise the position now to make sure this doesn't happen 08:34:23 RN: That isn't why we do normalisation. So even if we lost that you should be able to render the caret where you want it. 08:34:38 … it is normalised for editing, to reduce the edge cases we need to handle. 08:34:54 OV: Where browser isn't handling editing you could imagine not normalising. 08:35:18 RN: If that's what we are doing we dhould not normalise at all, unless we are running execcommand and normalise it there. 08:36:00 OV: there are some thing in common across blink and webkit codebases. We would also have to normalise right before copy. I think that is a reasonable change to make, but it will be some serious work. 08:36:12 RN: Not happening overnight but does need to happen. 08:36:52 JW: copy is the only exec command left that we need. But that's only relevant if you have a selection. Problem for editors is just the caret. If you only have a caret and people copy, you cannot copy? 08:37:12 OV: The idea is that you would not normalise the selection, but take the copy and then normalise what you have copied. 08:37:18 JW: That sounds even better. 08:37:51 Piotr: Copying doesn't have to put something to clipboard, we can do this in javascript directly. 08:38:06 JW: But we initialise that through an execcommand 08:38:29 PK: But ckeditor puts the content into the clipboard manually so we get the right stuff in there. 08:38:34 q+ agenda 08:39:02 FR: My impression is that this area hasn't been a high priority area - how mch can we reasonably expect will happen? 08:39:17 Ojan: Think this is the hardest part and most "at risk". 08:39:28 … we will do selection eventually, but cannot give a timeline. 08:39:38 FR: You don't have anyone obviously ready to do it? 08:39:43 Ojan: Not sure… 08:40:10 SW: Browsers operate based on what others do… so may copy, especially once two browsers start doing something. 08:40:23 RN: There is also a question of benefit to cost… 08:41:57 weinig has joined #webapps 08:42:14 Ojan: Want to convince our team soon to implement beforeinput and kill textinput. ContentEditable events? Should do, it is simple. Selection normalisation is hard... 08:42:45 Piotr: There was a difference between webkit and blink - when I added ranges, blink started returning the same ranges. 08:43:07 RN: You (ck) now normalise at execcommand, right? 08:43:10 PK: Yep. 08:43:19 RN: That part isn't that hard… 08:43:29 Ojan: So the thing I said is hard, we already did, right? 08:43:43 RN: Well, the hard part is to respect what you already did when you insert... 08:44:25 agenda+ What features get used, are they spec'ed 08:46:06 JW: SO two positions. We don't do caret movement in the browser. I think that is almost possible except maybe line endings and bidi boundaries. Other position is caret movement but we don't specify that. People making editors have been asking for standard caret movement, because moving in the block direction would be different. 08:46:29 … Don't see harm in having caret movement, but we may build code for something that wasn't specified and be stuck supporting that. 08:46:54 RN: We could have caret movement supported by ce=events, or we could have a caret that would allow you to move between elements. 08:47:20 Ojan: The question is should we specify caret movement? You can imagine having it as an optional piece of ce= 08:47:38 JW: Should we have caret movement prior to having a spec, or should it just not move? 08:47:55 RN: We should spec both at the same time 08:48:03 FR: Can you turn them on and off seperately. 08:48:07 Ojan: Proposing sepeartely. 08:48:33 SW: Seems odd to have a spec that says if you touch the keyboard text doesn't happen but arrow keys do, so makes sense. 08:48:54 RN: And in collaborative editing you already have to render carets, so you don't want browser caret movement. 08:49:12 FR: Think spearate modes make sense, and we say it happens and we will need to specify it. 08:49:42 weinig has joined #webapps 08:50:17 RN: Not sure if it makes sense to have caret but not events. As soon as you have typing, you need caret, makes no sense seperately? 08:50:36 Ojan: Not so sure. E.g. you have special widgets but don't want to deal with typing yourself? 08:50:47 RN: But if you have IME, you need caret there 08:51:48 RN: So should events and caret be disjoint, or caret be a superset of events? 08:52:17 SW: So what do we mean by caret movement? Arrow keys / mouse, or implicit carets when you paste, or what? 08:52:26 PK: Drag and drop is affected too. 08:53:21 FR: We can say caret movement is implementation dependent, but we need to define early in what triggers movements. E.g. drag and drop, ... 08:53:44 RN: HTML5 says selection shouldn't move on drag/drop, but webkit/blink doesn't do that 08:53:56 FR: Worth trying to scope what triggers there are for caret movement. 08:54:02 RN: Yep. 08:54:20 … There are some platform-dependent things, e.g. keyboard combinations may or may not trigger a selection. 08:54:32 … but e.g. ordering of events should be specified 08:54:46 enrica has joined #webapps 08:55:05 … on Mac we don't have touch events, but on iOS you have touch events moving the selection. 08:55:22 Enrica: Selections won't be drawn without user interaction, but they exist in the DOM and can be acted on. 08:55:45 RN: So if you interecept touch events, and do things to the selection when the user can't see it, you confuse people. 08:56:11 Ojan: Sam's point is interesting. If you paste, when you only have events and selection but not caret, what happens? 08:56:20 … so maybe makes sense to have superset relation 08:56:30 RN: We can define it like that for now, and see if we need to change it later. 08:56:49 Ojan: Don't see anything that will break, for the moment, so let's go that way. 08:58:42 RESOLUTION: We think we want strict subsets - events is a subset of caret is a subset of typing which is a subset of true. 08:59:22 Ojan: Think it makes sense to have one spec for editing, one for selection... 08:59:30 JW: There is also execcommand... 08:59:34 Ojan: Don't integrate that. 08:59:48 JW: Right but e.g. clipboard want things to be updated in that spec. 09:00:50 RN: Might need to specify caret movement in selection API... 09:01:02 JW: Yeah, we'll just say there will be a spec at some point. 09:01:19 RN: If it is going to be specced, it will happen in selection spec. 09:01:40 [spec development synchronisation …] 09:02:28 RN: So say a browser moves selections, where do they move to? Right now they are browser-specific… makes sense to specify that. 09:02:37 Ojan: Yeah, spec should describe what is going to happen there. 09:02:45 RRSAgent, make minutes 09:02:45 I have made the request to generate http://www.w3.org/2015/08/23-webapps-minutes.html MikeSmith 09:02:53 RRSAgent, make logs public 09:03:02 RN: In most applications what you want is the selection to be in the text node, not in an element boundary… 09:03:14 Ojan: Need to discuss this with Mozilla. 09:03:29 FR: If we can arrange call in, @@@ from Mozilla can do that. 09:03:46 Ojan: There are a couple of points that would be good. Selection normalisation. 09:04:51 chaals has changed the topic to: Editing TF f2f. Ping us for remote connection. minutes: http://www.w3.org/2015/08/23-webapps-minutes.html 09:05:16 EC: Is it worth trying to standardise where selection will be on caret movement, or leave it to application? 09:05:38 … if we define strict rules we don't leave freedom to app developer about what is going to happen next… 09:06:38 CMN: We should standardise, but need to include the possibilities which makes things complicated... 09:07:08 Ojan: We should define primitives so you can hook into all the places, even if you don't implement those in your high-level. 09:07:13 s/@@@/Ehsan/ 09:07:30 FR: Doing reasonable things for people especially in regards to i18n makes sense because it saves a lot of work for app developers. 09:08:04 RN: If people are implementing at a low level like ce=events you have to do more work than if you're doing ce=true... 09:08:26 FR: Yeah, but i18n in particular is an area that people really don't know what they needed to know, so doing it for them is useful. 09:09:05 RN: Websites can always get things wrong. make things mostly work unless they specifically ask to do things otherwise. 09:09:20 … what if you want to show a widget on top of the caret… in multiple writing modes? 09:09:38 … it's a crazy idea, except people want to do that. 09:09:44 FR: new CSS? 09:10:04 … there are user stylesheets... 09:10:12 SW: Yeah, although they don't seem to work out well. 09:10:29 … What are the real problems? 09:11:37 weinig has joined #webapps 09:12:46 JW: By making most basic tasks easy and not break, we can try to ensure editors can get the hard things like vertical correct… 09:13:19 RN: Example, at a boundary of vertical, the caret is shown differently depending on which direction you came from. 09:13:34 EC: Are we talking about the caret, or selection? 09:13:44 RN: Think selection… 09:14:10 EC: In that case eg vertical becomes more important, because selection is a pretty important thing beyond just editing. 09:14:38 SS: To the point about boundaries, you're inside the element or outside it, and those are different positions in the DOM. 09:15:30 RN: Meant bidi boundaries 09:16:08 Ojan: We would give primitives so you can put the caret where you want it, but we wouldn't make all the controls for where the browser moves the caret if it is handling it. 09:16:33 RN: So do we expose that the caret moved from left to right to get where it is now? 09:16:50 FR: The question is how do you find out where the caret gets to? Do we need to specify the superset? 09:16:58 JW: There are also end of soft line breaks. 09:17:12 RN: We have split caret in webkit… 09:17:22 … do we expose that as well? 09:17:46 Ojan: Yes. Don't see an alternative if you want stuff to work. 09:17:58 RN: And then we have to add more for each system… 09:18:47 CMN: Yeah, but this is likely to be a reasonable sized set to try and track. 09:19:08 Ojan: When we write down what editors want to do, it becomes clear what we need to expose. So we should do that exercise. 09:19:28 JW: We have been talking about that and haven't come up with a whole lot of new requirements... 09:19:42 RN: SUre, but there are very few people who even know all the things. 09:20:04 Ojan: So we need to look at the primitive, as an extension to selection - which end of line or bidi are you at? 09:20:16 SW: Do we need to expose things that match our internals? 09:20:38 Ojan: Where a single DOM position can be two different screen positions, yes we do. 09:20:49 RN: So e.g. before or after a line-break. 09:21:16 JW: getclientrects gives two rectangles in those cases - in which is the caret - that is the question… 09:21:27 RN: Right, because the answer now is "depends". 09:22:28 enrica has joined #webapps 09:23:25 JW: So are there any other cases than "in one, in the other, or in both?" 09:23:46 RN: For bidi you need one more bit of info - the bidi level the caret is on. 09:25:53 JW: So having 2 carets, of which one is preferred, is that semantically different from having a single visible caret? 09:27:22 CMN: SO the need for bidi-level is when you extend the selection at a bidi boundary. 09:27:40 FR: Are we talking about enabling all things people do today, or determining what they can do? 09:27:52 JW: So you need a get and set of the bidi level... 09:27:59 SW: What do editors need here? 09:28:40 … if the browser says "when you modify selection one character forward this is what we will do" is that enough, or do you need to be able to know more? 09:29:17 PK: Bidi is really unclear, having "what we will do" is a good start. I don't think many of us editors want to mess with that on our own. 09:29:38 … understanding why the browser chose the location, that's not critical 09:29:51 FR: But if you are controlling teh caret, do you want to control how it is shown? 09:29:54 PK: Yes. 09:30:12 Ojan: You want to be able to save and restore character position with full fidelity, so you need to have that information. 09:30:39 SW: So if you have a shadow cursor of where something would go, you don't need the nitty gritty. 09:30:56 Ojan: Yes, when you remove the DOM and then need to put the selection back. Or collaborative editors... 09:31:38 weinig has joined #webapps 09:32:03 RN: Don't think we want to have browsers implement other browsers' selection behaviour 09:32:24 JW: Most common use case is end of line - you reimplement in JS moving up and down… 09:32:41 … RN you already started on a proposal right? 09:32:59 RN: For line breaks yes. For bidi, I think we need another attribute for bidi-level… 09:33:17 Ojan: Can we add those to range? So you can get/set on a range? 09:33:26 RN: Yes, in the context of multi-range. 09:33:36 Ojan: should not be just set-position. 09:33:50 SW: We need some new objects that represent the internals of selection... 09:34:14 [break] 09:57:53 chaals has joined #webapps 09:58:02 rniwa has joined #webapps 09:58:42 enrica has joined #webapps 09:59:47 weinig has joined #webapps 10:04:09 proposed resolution: we want information in selection that says where the caret is - before/after linebreak, where in a bidi boundary it is, and a way to say how to put it in a given place (before, after, or at both ends). Primitives for a superset of all browser behaviour, but browsers will choose for themselves where to put it and leave editor implementors to normalise that if they want it 10:04:43 PiotrekKoszulinski has joined #webapps 10:05:17 line break issues: https://github.com/w3c/selection-api/issues/32 and https://github.com/w3c/selection-api/issues/51 10:05:56 RESOLUTION: we want information in selection that says where the caret is - before/after linebreak, where in a bidi boundary it is, and a way to say how to put it in a given place (before, after, or at both ends). Primitives for a superset of all browser behaviour, but browsers will choose for themselves where to put it and leave editor implementors to normalise that if they want it 10:07:14 RN: So we are probably looking at a trinary state… 10:08:18 … need to decide whether this will be on a range or selection. 10:08:48 Ojan: Use cases: Save and restore with selection in place, and being able to take the caret and do things to it. I think the latter should be a different API. 10:10:09 FR: You have enough information from the browser to expose the state, but not necessarily enough power allowing overriding of platform conventions 10:10:58 JW: If you want to move the caret in block direction by yourself and it jumps from start to end of the line, what do you do? 10:12:15 [How browser internals really work for this matters] 10:12:47 RN: hesitant to expose implementation-dependent rectangles, because people will rely on it. 10:13:03 JW: If you look at aloha2, they just disallow one caret location. 10:15:02 FR: When you move down from a non-Bidi line into one, where does the caret go? 10:17:54 [moving up and down ends of line vs offset that is at the end is tricky… but not horribly so?] 10:18:18 RN: The issue is restoring the history of that movement. 10:18:43 Ojan: A react style virtual DOM, where you are constantly reloading, is a stronger use case. 10:19:01 … feels like this is just another bit of information... 10:19:09 RN: we want to add more and more info... 10:19:18 Ojan: Yeah, but it isn't an infinite list. 10:21:37 FR: Dropping down from a straight line to a bidi boundary, you want to be able to set a physical caret location. 10:21:42 RN: How does the app do this? 10:21:58 JW: Point to caret position thingo helps do that. 10:23:07 RN: If we had a clone selection, and modify the clone, you don't modify the actual user selection. If you move the selection down, you are done... 10:23:15 … why figure out the position manually? 10:23:41 JW: Many times you want to put the character eg into a floated block… 10:24:32 FR: You don't want to rely on the browser to move your caret, you want to be able to do it yourself. 10:25:20 CMN: editors want to override the browser placement. 10:25:29 RN: Not sure we want to allow that 10:25:44 Ojan: You can just try all the bidi positions to get the one you want. 10:26:43 JW: We can and do put carets everywhere, except for linebreaks and bidi boundaries. Not having those two possiblities is problematic. 10:27:26 Ojan: Think we need some object that has all the state the browser uses internally - offset node, line point, bidi level, now I think inline-position… 10:27:58 … not worried which one it should be. seems reasonable that the API returns this object, which doesn't seem hard to implement, and would meet all the use cases 10:28:35 Johan: If you want to get to a point that is not visual, you cannot. You need to send the point inside the rectangle. 10:28:56 SW: Think the solution is that this is on document, probably need to put it on elements as well. 10:29:06 FR: And you should be able to do it in the viewport of the scroller. 10:29:24 Ojan: We don't hit-test things that are clipped. If we need to do that it is new... 10:29:47 JW: Aloha has this problem. Why not just scroll and then move there? 10:30:21 PK: What if you have slow scrolling, how do you get there? 10:30:47 Ojan: We should leave this for now... 10:31:00 SW: Is main use case to extend selection into something that is not visible? 10:31:14 … if so wouldn't API to extend selection be better? 10:31:34 FR: Extend forward and backward? Assumes browser caret movement is adequate, which isn't always true. 10:32:00 SW: Just API that says "if you move the caret, here is where we will put it" so you can check, then decide what to do. 10:32:16 EC: What Ryosuke said about cloning the selection without affecting user selection. 10:32:30 Ojan: That's backwards… 10:32:47 weinig has joined #webapps 10:32:49 … we don't hit test for this. There is a separete code path for that. 10:33:07 EC: caretrange from point does hit test in webkit 10:33:49 RN: If you have selection modify on a clone you I can't think of a use case that means you also need to convert x/y to putting caret. 10:34:00 FR: Because e.g. the browser cannot get to the place where you want to go. 10:34:29 JW: You want to implement caret behaviour in your system that is consistent across different platforms. 10:38:28 FR: If you have DOM position plus line-end you know where it goes, but for position plus bidi level you don't. 10:38:53 RN: You can predict - it is beginning, end, or both, reliably but dependent on platform. 10:39:55 Ojan: If you get the rect where the caret goes, is that enough? 10:40:28 … you get caret position. Caret range from point returns that. There is a method to get the rect(s if there are two). Is that enough? 10:42:54 RN: In visual selection you want to be able to say "select from this coord to that one"... 10:45:24 JW: So in effect you can specify line start/end and an equivalent for bidi? 10:47:40 weinig has joined #webapps 10:49:18 [Ryosuke draws a complex case to look where the offsets are in RTL text with mixed bidi levels] 10:51:23 RN: You will not be able to do restoration across different browsers, because they use different offset numbering in the line. 10:52:03 Rossen_ has joined #webapps 10:53:33 proposed: For now we can live with not being able to solve the edge case of knowing which end of a bidi block you get to when you move the DOM across to a different browser 10:54:08 RESOLUTION: For now we can live with not being able to solve the edge case of knowing which end of a bidi block you get to when you move the DOM across to a different browser 10:54:23 rrsagent, draft minutes 10:54:23 I have made the request to generate http://www.w3.org/2015/08/23-webapps-minutes.html chaals 10:55:34 Ojan: CSSOM has offsetnode, offset and getclientRect - we will have to reconcile with that… 10:55:45 SW: Only Mozilla does that. 10:55:53 Ojan: We can convince them to change that. 10:56:36 Filed https://github.com/w3c/selection-api/issues/58 Need an API to get the current caret rects 10:59:51 [lunch] 11:00:00 Filed https://github.com/w3c/selection-api/issues/59 We need to expose line direction coordinate as a property 11:00:13 Florian has joined #webapps 11:01:18 Florian has joined #webapps 11:36:09 hgl_ has joined #webapps 12:18:01 PiotrekKoszulinski has joined #webapps 12:18:14 chaals has joined #webapps 12:27:31 enrica has joined #webapps 12:28:57 rniwa has joined #webapps 12:30:10 Florian has joined #webapps 12:31:09 weinig has joined #webapps 12:32:00 Topic: IME and DOM 12:32:43 JW: Benjamin Peters looked at this and his first conclusion was that if we do inline IME we need to allow typing because it changes the DOM along the way… 12:33:28 … which is why we did ce=typing. Then Koji pointed out that this could be handled somehow in shadow DOM, so we could have inline IME input and when the content is constructed you create the beforeinput events and don't change the DOM in the meantime. 12:35:12 [We are talking about how inline IMEs work. Some are a popup, others show a composing character and then a final…] 12:35:38 SW: Do we count e.g. a composing character and then the result? 12:35:45 RN: Think this is more of a ligature case. 12:36:18 OV: IMEs are arbitrary programs that do their own internal thing. There is a pipeline of start composition, do stuff, end composition, and then you commit the resulting text… sort of… 12:36:55 … so for inline IMEs browsers modify the DOM as you type mid-composition, so if you autosave it might grab the half-composed thing. Escape will undo the composition. 12:37:47 RN: This varies depending on which language… 12:37:58 OV: dependent on language, OS, … 12:39:00 JW: supposedly this can be done without changing the DOM. Benjamin talked to the office team, ... 12:39:09 FR: is autocorrect like an IME? 12:39:15 CMN: Yes, OV: no... 12:39:44 RN: Doesn't work exactly the same, but you are trying to replace the range of text with something else. 12:39:59 OV: But there is no middle point, you replace something with something else. 12:40:08 FR: swipe keyboards? 12:41:09 RN: Yes. 12:41:22 JW: Mac-style composing accented character? 12:41:48 EC: That's not composition - the combining character is there, it is just that you might change it subsequently. 12:42:04 OV: On android everythig is IME. 12:43:12 JW: The issue is if you have a collaborative editing environment, and you send a tilde ready for composition, can someone else make a mess there? 12:43:50 … if we can get it down to this character is being committed, that would simplify many things when you coordinate editing 12:44:34 OV: The option-based combination on Mac is an IME... 12:45:39 CMN: The yandex translate input will let you type some letters in Latin, and offer an auto-complete as if it were a russian keyboard. 12:46:02 OV: What if you start composing an email, and hit send mid-composition. 12:46:20 RN: Real users don't - but anyway, the send confirms the current suggestion. 12:46:58 [This is highly variable according to platforms] 12:47:31 RN: Let's say you have

Hello

and your caret is before the H, and the IME wants to insert… 12:47:58 … we attach the shadow DOM, conceptually speaking - shadowroot -> -> H 12:48:03 with the cursor at the H 12:48:11 s/with/… with/ 12:48:47 OV: With shadow DOM you replace what is rendered with something else. So in HTML you won't get the composition. I don't like that because the lowest level element can be aribitrarily big. 12:49:17 … I think you want the thing in the DOM, but control over whether it synchs to collaboration, e.g. to demonstrate how to do the composition mid-typing. 12:49:35 … what if we put a composition element where you are composing? 12:49:44 RN: That was the original proposal. 12:49:50 JW: Main problem is with split text nodes. 12:50:48 … say we put the composition in the middle of two text nodes, start composing in the middle, and cancel, do you merge the two nodes which used to be one? 12:50:58 OV: Text nodes get re-normalised all the time… 12:51:32 RN: Problem modifying the real DOM you enter ce=typing, and you end up modifying a bunch of DOMs 12:51:57 OV: I'm a bit confused :S 12:52:12 RN: In ce=events we don't want to modify the DOM at all. 12:52:57 OV: I was assuming that in ce=events you have to get the composition events as they come. 12:53:25 RN: Different IMEs use different ways to e.g. identify what bit of the current composition is being worked on. 12:53:31 OV: How does browser do it? 12:53:49 RN: It's broken in blink. But Firefox gets it. 12:54:33 OV: We should expose what the browser does… draw an underline 12:54:51 FR: That varies enormously. Do you want to expose that as a superset of all platform behaviours? 12:55:14 OV: Today we have compositonStart, …Update and …End. 12:55:38 … if browsers tell you what the user typed and what they think the current compositoin is, that's enough… 12:56:10 RN: You need seperate ranges for each part of a composition. There is some privacy concern, because it can expose user-defined dictionaries. 12:57:04 OV: Seems far-fetched concern... 12:57:10 [not so much…] 12:57:57 [Rysouke gives example of how splitting japanese text in different ways exposes things in your dictionary, such as names.] 12:58:03 OV: Don't think this is a big deal... 12:58:42 RN: This is as bad as spellchecking, which people have said they don't want exposed. 12:59:18 [FR explains how to use this as a fingerprinting technique] 12:59:19 enrica has joined #webapps 13:00:43 JW: collaborative editors are breaking because they get the composition events as they come. 13:01:20 OV: This is where I am going with the composition. A good editor wouldn't let a collaborator mess with what is being modified. Today you can't stop that because you don't know what is being composed. 13:01:35 … my concern with shadow approach is performance. 13:01:50 RN: We could do that with caret but don't want to put it in the real DOM. 13:02:03 JW: Koji said we don't need that... 13:02:08 OV: But I think he is wrong. 13:02:40 JW: If you save in the middle of composition, what do you do when you load again? You don't want to arbitrarily merge sibling text modes. 13:03:01 OV: Makes no sense to me to have event-only thing where you are modifying the content typing in an IME. 13:03:13 FR: Agree. But for visual aspect, who should display? 13:03:21 OV: Depends on IME… 13:03:32 …inline part is done today by the browser. 13:03:40 RN: Not necessarily. Depends on teh browser. 13:03:58 FR: So you want to make it the javascript's job choose what to display? 13:04:02 OV: yes. 13:04:19 JW: Can we get hold of Koji to get input on this? 13:05:55 OV: Koji's approach is possible but not performant... 13:06:39 JW: Is having stuff in shadow DOM less performant than normal DOM? 13:06:54 OV: No, it is that you have to re-render... 13:07:55 CMN: worst case is 
 …[4000 lines of code] …
13:09:07 RN: You could have a mode where a caret element is disabled. EMpty in most cases 13:09:21 JW: You split text nodes… 13:09:38 RN: Yes but you never remove the caret. You see them all, you just don't show the characters 13:10:19 JW: When you split text nodes to put a composition element in the middle you have to send to everyone that you split the nodes. 13:10:26 … this is complicated. 13:10:32 RN: But you can do that easily enough. 13:10:46 JW: There may be other reasons why you have separate text nodes… 13:11:34 … e.g. so people are overwriting different parts of the same text node. 13:11:51 RN: You don't want to multiply split text nodes - that would be super inefficient. 13:12:17 JW: Avoiding splitting text nodes seem preferable. 13:12:41 RN: Don't think you have large text nodes 13:12:52 OV: when you have a code element you do. 13:13:02 RN: you can put
s in to split the nodes 13:13:15 OV: But that doesn't help in the shadow because you still take the element. 13:15:26 CMN: what if ce=events doesn't let you mess with composiotion and if you want to do that you have a new ce=composition 13:15:41 RN: Can't think of a use case where you want to handle composition on your own? 13:15:50 CMN: I can but they are a uncommon. 13:16:06 OV: Google Docs doesn't use the system IME… 13:17:08 CMN: Think use cases for messing with composition are obscure enough to justify a seperate layer… 13:17:50 RN: only use case I can think of is when you want to custom style the text being edited, e.g. spacing. 13:17:56 FR: How does Firefox get this right? 13:18:16 RN: It gets the info from IMEs and renders itself. 13:19:01 … we don't want web authors to do this 13:19:10 OV: We should be able to expose all this to the script 13:19:29 CMN: Not as a high priority. There is low value for most people, it is very difficult, and unlikely to be done right. 13:19:46 … Not that it should be impossible, but it isn't a priority to expose first. 13:20:08 FR: And it must not be the only way to handle this - developers should be able to just rely on system IME 13:21:22 RN: We want the editing to make it easier to develop editing software, this is a hard and often unnecessary piece. 13:22:13 OV: OK with an incremental path. Don't like that we have IMEs that are modifying the DOM as they go. If we had composition element you throw the composition into that, and that gives you control of what happens in the composition. 13:22:30 RN: That is the design. You could set where the shadow DOM shenanigans happen. 13:22:34 enrica has joined #webapps 13:22:35 OV: Don't see that. 13:23:13 RN: We have "user about to type". You can get that to set insert point. We don't have a real shadow DOM. When text is being composed in a real DOM, script can interfere with that and it causes trouble. 13:23:33 OV: Are you going to change ce=true to do this? 13:23:37 RN: Yes, we could. 13:23:54 OV: Top level needs to do the same as the bottom level. 13:24:04 RN: THink it makes sense to do this in ce=true. 13:24:09 OV: I don't. 13:24:57 OV: Suggesting that in compositionStart you tell the browser where to put the composition 13:25:10 … difficulty, you need to deal with where the characters go... 13:25:24 FR: What can happen to caret while you are composing? 13:25:32 RN: It is somewhere in the composition. 13:25:51 RN: WOuldn't be rendered while composition is happening. 13:26:02 Florian has joined #webapps 13:26:04 rniwa has joined #webapps 13:26:06 JW: As long as solution *permits* having composition in shadow DOM I don't have a problem. 13:27:05 Florian has joined #webapps 13:27:08 OV: Think my proposal works fine… 13:27:30 RN: Proposal is to set the insertion point? 13:27:34 OV: Yes. 13:27:41 RN: That is the selection model, right? 13:27:49 JW: We have all the pieces necessary? 13:27:52 [we think so] 13:28:05 OV: So it is going to modify the actual DOM... 13:28:24 PK: If I create a blank text node between two others, and tell the browser to insert there, will that work? 13:28:43 OV: Hmm. Should be possible, not just on an element. 13:29:00 PK: Text node will be modified as you work? 13:29:14 OV: Only if you ask for that. You can do it elsewhere if you like. 13:29:24 … composition point is text node plus offset into it? 13:29:40 RN: need to spec what happens when the author modifies the text-node mid-composition 13:29:55 PK: Think it should break the composition. 13:30:09 FR: Seems reasonable. You shouldn't do that anyway… 13:30:20 RN: So we are coming back to ce=typing... 13:30:31 OV: Just for active composition. How is this different? 13:30:46 JW: Because you don't change the DOM until you have the composition complete. 13:31:06 OV: Why is that better? Why do we care about modifying the real DOM? 13:31:14 RN: You may have some states on server 13:31:27 OV: But in this case you have control over that yourself. 13:31:39 … if you don't want to mess with text nodes you don't have to. 13:31:44 RN: I guess so. 13:32:00 … for consistency we want to support regular text input as well or it will be weird. 13:32:33 OV: I was envisaging that you handle composition yourself. 13:32:44 SW: So does your vision include the dropdowns? 13:33:11 OV: No, you say where the dropdown goes, and you show teh text. 13:33:28 … I hear editors saying they are not about to start writing their own IMEs. 13:33:56 JW: If the basic things work you can do the high level stuff. If the basics don't work, then you do less. 13:34:21 … your proposal that you have to create things doesn't seem terribly hard. 13:34:35 RN: So maybe we should just go back to ce=typing. That would make more sense 13:34:46 JW: Why did we go away from that in the first place? 13:35:02 OV: I'd like ce=events someday. But don't think this stuff belongs to the browser. 13:35:17 RN: Don't think we want apps to be doing this - even huge important apps get it wrong. 13:35:45 OV: I want IMEs to be included with standard libraries. 13:35:57 … imagine we have ce=events, and you imported an IME library. 13:36:15 … That would be fine. But if you want to change it, you can. 13:36:33 FR: Doubt people will do that. MS, Google and Apple ahve all failed to get it right. 13:39:21 OV: So what was the pushback on ce=typing? 13:39:29 RN: When we started exploring spellchecking 13:40:02 i/OV/[chaals and Ojan agree that we want something like ce=typing for the easy case, and to be able to rebuild it all in js using ce=events] 13:41:28 [security/privacy issues from spellchecking, spellchecking crossing element boundaries, so editors disable spellchecking, use a 3rd party spellchecker…] 13:42:27 JW: Gmail uses spellcheck from a 3rd party but also uses built-in. So you have both cases. If we can turn off spellcheck, that's good enough. 13:43:41 JW: Weren't there issues with carets in typing? 13:44:00 RN: Where you are IME composing in typing you cannot change styles. 13:44:12 … in plain typing you can do that… 13:44:34 … so eg you can have beforeinput say "user wants bold…" 13:58:46 wilsonpage has joined #webapps 13:58:59 enrica has joined #webapps 14:07:01 chaals has joined #webapps 14:07:25 agenda+ IME and accessibility 14:08:51 FR: Because we do not want to specify events relating to IMEs now, we want to skip that and do ce=typing 14:09:21 RN: Think we should focus on typing today. Don't need to put the future things in... 14:09:38 OV: Think we should note in the spec our expectations of what we will do in future 14:09:47 JW: Right, and focus on typing for now. 14:09:51 RN: Sure. 14:10:36 OV: For chrome on mac with chinese, if you move selection during compositionstart into an element you can already make that work… (for this one test case) 14:10:48 … if that doesn't work it is the sort of thing we could get into one of these specs. 14:11:16 FR: If you are in typing or higher, you get composiiton. 14:11:29 OV: If you are using events, you implement the whole shebang, you don't get input. 14:11:48 FR: If you are in typing or higher and canceling all caret events, what happens to caret movements during composition? 14:12:11 RN: You can cancel them 14:12:33 wilsonpage has joined #webapps 14:12:44 RESOLUTION: We are going to focus on describing ce=typing as a priority. 14:12:59 FR: Caret movements during composition are a bit magic and you don't want them to be overridden. 14:13:04 RN: Right. 14:13:41 RN: It's a bad idea to change carets/selection when a user is typing in general… don't do that. 14:13:58 … only tricky thing about IME is that sometimes the caret will disappear, e.g. japanese. 14:14:35 CMN: Don't think that is weird to actual users because that happens already. 14:14:41 OV: Think it is fine. 14:15:01 RN: When you have composition text script doesn't know where it starts and ends in the DOM. 14:15:18 OV: You can if you move the thing on compositionStart and create a place. 14:15:24 johanneswilm has joined #webapps 14:15:36 Florian has joined #webapps 14:15:58 … and caret weirdness is something you can handle if you go into the lower level and do your own IME. 14:16:59 RN: Think when you are composing we want to say "please replace this bit of text with that bit". 14:17:51 OV: When you first start you get compositionStart, then updates, and then end with a beforeinput. And you say that has a request to replace text. 14:18:13 RN: Should we fire an event for this, or just repace the text? 14:18:34 OV: In my mental model, we just replace. That's part of typing. There is a beforeInput you can cancel… 14:18:44 RN: So we fire that for each one of the replacements. 14:19:03 OV: it's IME specific. if it is inline with multiple changes, you fire multiple events for them. 14:19:29 RN: What if the user deletes? 14:19:53 … we need to ask the app when we delete it because browser cannot. That ends up weird. 14:20:44 … if we allow replacement, or deletion, then we are allowing the browser to delete text niside a text node. 14:21:28 … Once you deleted past the text node, the browser won't handle it, but inside the text node teh composition handles it. 14:22:00 OV: It is weird to have typing without deletion, and to have that you get execcommand. 14:22:34 RN: So you do this in two steps, asking the app to handle the actual replacement 14:22:39 OV: Think that is OK. 14:23:03 RN: The pushback was that people would make the assumption deletion never happens. 14:23:15 OV: App authors will get IME wrong if they don't think about it. 14:23:36 SW: Seems like we don't need to make it trivial to get this right, but that it is feasible to manage... 14:24:04 Florian has joined #webapps 14:24:10 OV: There are not that many people who want to write an editor... 14:24:26 RN: For spellcheck we do need a way to say please replace a range, already. 14:24:36 … so we want to use that in the IME case too. 14:25:08 … so I would prefer to always use beforeInput requesting replacement, even for IME replacing text nodes. 14:25:29 OV: Who does underlines? 14:25:40 RN: Browser. But we know the text node where we insert. 14:25:50 JW: Where is content during insertion? 14:25:50 wilsonpage has joined #webapps 14:25:53 [in the text node] 14:26:20 Florian has joined #webapps 14:26:42 OV: Backtrack - what if we had ce=events but instead of magic shadow we give you beforeInput that says replace this with that, and browsers do the underlines for now, until we later explain what happens for real? 14:27:04 RN: If you don't use the same text node to insert, we have no idea what happened… 14:27:10 OV: Yeah. just break. 14:27:20 SW: In some way that we will define. 14:27:35 RN: We wanted to know that what we are trying to insert is what the IME is seeing. 14:27:40 SW: Why do we need to ensure that? 14:27:53 FR: So what will happen if you do that... 14:28:07 … cancel composition and do a text diff? 14:28:12 SW: You let them insert that... 14:28:28 OV: And the underlines become unpredictable and we cancel the composition 14:28:34 FR: But then you need to do a diff... 14:28:41 SW: You just have it go funky. 14:29:07 OV: Think that is fine. Lets you do what you want, it's a lower level version of the same thing. 14:29:17 FR: Think it is fine but should specify the error case. 14:29:24 OV: Sure, but doesn't amtter what we say. 14:30:10 FR: most dev-friendly is if you put something else then cancel composition, but that requires diffing. Putting funky underlines isn't that great. 14:30:22 OV: Don't. 14:30:53 FR: You'll have a problem where authors don't consider people who use IMEs 14:31:01 OV: Don't think this is a big problem in practice. 14:31:24 PK: So you ask for stuff to go into a text node, but where. 14:31:54 RN: what if you have a react thing? text node is gone... 14:32:13 OV: React has a model for stateful elements, that you would have to use. But that is a reasonable thing in react. 14:32:24 PK: What about big selections? 14:32:40 JS IME, chinese, 3 years old: https://github.com/hermanschaaf/chinese-ime 14:32:44 FR: Browser says "delete selection", app deletes it, and says "now insert this". 14:33:10 RN: Text node will be super hard to figure out in practice. Thing we want to underline might not exist. 14:33:31 OV: What is you get beforeInput and tell browser "here is where I put the composition" 14:33:33 Florian has joined #webapps 14:33:41 JW: Just composition, or character input in general? 14:34:06 OV: Could be on compStart / update. So react can just reset it. 14:34:22 RN: Think we should do it on beforeInput so auhors don't have to listen to comp events. 14:34:29 OV: Default would be where the selection is. 14:34:36 I have made the request to generate http://www.w3.org/2015/08/23-webapps-minutes.html xiaoqian 14:34:38 RN: Just use the selection... 14:34:43 OV: Sure, seems fine. 14:35:28 OV: Note that this is for ce=events. 14:35:32 RN: Oh… 14:36:00 JW: So you get requests for changes as beforeInput events, during composition phase. 14:36:12 OV: As long as you don't move around in the middle of composition, you are OK. 14:37:04 OV: You do composition start, and at some point there the selection is at a point. Then you get your first character, "replace text(null, "я") …" 14:37:21 … wherever the thing started, you have to tell the browser where that is. 14:37:31 FR: You do that with selection. 14:38:11 RN: When you insert a character you need to move the selection forward. 14:38:16 … feels weird. 14:38:31 FR: During composition, selection must enclose the entire composition. 14:38:49 RN: The text node where the caret is contains the composed text. 14:38:54 … seems weird. 14:39:04 OV: So we add API to say "here is where composition goes" 14:39:19 … all to work around us not telling how we do underlining. 14:40:28 CMN: Don't think it is an issue if a caret disappears in an IME where it always has done that. 14:40:51 JW: You have to manually insert all the characters. How does the browser know that it is part of the same composition. 14:41:05 FR: You replace, then tell the browser where that is. 14:41:52 JW: You have replace content, and then say where the content you replaced is, and then you get a line. 14:42:11 RN: This API puts the app in control of the text node, and the app tells the browser where the underlining should be. 14:43:20 RN: In our original proposal we have a hidden text node where the browser does stuff, and when finished we tell teh app to insert the text node. Ojan's proposal is to request replacements character by character, and the app replies with a pointer to where the change happened. 14:43:52 PK: Maybe instead of a text node we specify a range, that must be anchored within one. 14:44:18 EC: Don't we already have the target range for any input event? 14:44:37 RN: Yes, but once you mess with that, you don't know where it went. 14:45:08 RN: Feels like few people will get this right 14:45:15 FR: Yeah, but the alternatives are worse. 14:45:50 OV: We have ce=Events with shadow DOM thing, or with "put this in a text node", or ce=typing which fixes that but has the delete issues to deal with. 14:46:14 EC: So we decided not to focus on events, lets try and focus on typing for now. 14:46:46 … all the app developer needs to know is that this is happening. They get all the events, but also notified if this is happening inside an IME session. So they can just leave it alone, to avoid creting problems. 14:47:05 … we have an API that notifies everything consitently, but you can tell them "this is in IME, so do nothing". 14:47:22 RN: If you delete an entire text node and there is an element boundary, the deletion needs to be done by the app. 14:47:29 EC: Yeah but you are not in composition anymore. 14:47:42 RN: That leads us to where we have two delete events 14:47:58 FR: composeDelete and delete. first you ignore, second you implement yourself. 14:48:00 OV: Seems fine 14:48:09 RN: Seems like the simplest thing we could do today. 14:48:18 … least insane of our current set of options. 14:48:23 FR: Are these cancelable? 14:48:42 https://w3c.github.io/editing/input-events.html 14:48:51 rniwa has joined #webapps 14:48:56 Florian has joined #webapps 14:49:11 OV: [segues to] input events are in composition. most IMEs don't support canceling updates… (bottom of link above) 14:49:36 … basically most IME don't let you cancel stuff they did. 14:49:59 JW: All makes me think when compstart happens, run away… 14:50:15 s/run away/move it to some sensible point/ 14:50:34 OV: Think this is reasonable. Cancelable should be false for events that cannot be canceled so authors know if they can. 14:50:45 FR: Set it per IME, or per event type> 14:50:50 s/>/?/ 14:51:08 OV: Don't feel strongly either way. Few IMEs allow cancelling so it seems mostly academic. 14:51:23 RN: japanese lets you cancel teh whole thing... 14:51:37 OV: But not a particular keypress in teh middle, right? 14:51:40 RN: Right. 14:51:54 … just say those things cannot be canceled. 14:52:23 EC: Not sure we can finalise all these. Start with something like no cancelable, and then do the homework to see if there is anything else we can say or negative implications. 14:52:30 OV: Fine to say these are not cancelable. 14:52:51 FR: So if we do this, does it leave door open to do =events the way we are starting to explore? 14:53:08 RN: Think we could do that… 14:53:34 FR: Seems compatible to me, but I am not confident I know... 14:53:44 … hope we can still do this one. 14:55:04 JW: There is a chinese IME in JS on the web - is there anything wrong with that? 14:55:30 OV: Just talking about the way the IME interfaces, not the entire IME from scratch. 14:56:26 FR: It's not a trivial task - it is a *lot* of work. 14:56:27 wilsonpage has joined #webapps 14:59:15 proposed resolution: We will have typing with compstart (cancelable) when you can set a selection point, then a series on non cancelable beforeinputs to replace text, and two kinds of delete events (one inside one across event boundaries) 14:59:59 smaug has joined #webapps 15:01:12 RESOLUTION: : We will have typing with compositionstart (cancelable) when you can set a selection point, then a series on non cancelable beforeinputs to replace text, and two kinds of delete events - one inside composition not cancelable, and a "normal" one to be handled by the application 15:01:38 rrsagent, draft minutes 15:01:38 I have made the request to generate http://www.w3.org/2015/08/23-webapps-minutes.html chaals 15:03:42 Topic: accessibility and IMEs 15:04:06 RESOLUTION: We will ask the accessibility people to look at IMEs and the problems we should have considered here but didn't. 15:04:25 ACTION: chaals to ask accesibility people about IMEs 15:04:26 Created ACTION-758 - Ask accesibility people about imes [on Charles McCathie Nevile - due 2015-08-30]. 15:06:54 estellevw has joined #webapps 15:10:47 Topic: Multiple ranges 15:11:58 SW: Apple wants to bring these back. 15:12:06 OV: Controversy is how to do it. 15:12:30 … @@'s suggestion was that unless the API looks teh same for single and multi range, people will get it wrong. His idea was to just expose a node list. 15:12:38 … don't think that works. 15:13:00 … nobody depends on multi-range today. 15:13:09 FR: How do people note there is more than one node in the list? 15:13:19 OV: That's the common case, so you have to handle it. 15:13:31 EC: How do you handle selecting part of a text node 15:13:36 OV: That was to be determined. 15:13:42 SW: 2 options... 15:13:56 … 1. Assume nobody pays attention because it was only in one browser. 15:14:11 OV: Anecdotally, it is alleged even developers could not get it right. 15:14:32 SW: Not sure I buy that. Appkit has it and it has worked fine - you get an array of ranges… 15:14:36 PiotrekKoszulinski has joined #webapps 15:14:58 … there are fewer appkit apps than pages, but also pages don't all need to mess with ranges in interesting ways. 15:15:20 I have made the request to generate http://www.w3.org/2015/08/23-webapps-minutes.html xiaoqian 15:15:24 … there are needs for it, but the number of important cases might well be relatively small 15:16:10 … We could try to implement the way firefox does it, or we could leave window.getSelection alone, and add a new window.getMultipleRangeSelectionItemsThingMethod() 15:16:25 … and start a marketing campaign. 15:16:45 … Not sure the latter is worth doing. The existing API has some oddities, but it isn't that crazy. 15:16:59 RN: We could forbid people from modifying ranges directly. 15:17:20 … just return copies, can only add things from user selections... 15:18:06 FR: Cases where it is useful may include editable fields and noneditable, and trying to select one or the other… 15:18:18 … there are use cases beyond visually contiguous things 15:18:22 SW: Makes sense 15:18:30 FR: But don't need to be able to do any crazy thing... 15:18:52 RN: Having ce=false inside a selection makes me think having a list of nodes makes more sense because you can just remove nodes. 15:19:17 … you have a list of nodes that are inside a selection 15:19:31 SW: Seems more complex than existing model from FF. 15:19:37 OV: Yes 15:19:56 JW: What about pseudo elements that cannot be covered by selections. 15:20:21 FR: If we are inventing something new, we should think of that this time. 15:20:39 OV: One issue with ranges is that they are live. That makes me incline to a new API more than anything else. 15:21:16 SW: There are a bunch of other things that you would want in a new selection API - each subselection to have positions and affinities to know how they are selected, endline state, … 15:21:32 RN: affinity only matters in collapsed. 15:21:44 SW: Thought it mattered in extending a selection. 15:24:49 [some discussion of this on whiteboards] 15:25:17 OV: Authors can modify selections in various places, so you do need to be able to collect endlines etc in each range 15:25:35 RN: Affinity only matters for single DOM offset. 15:25:59 OV: Do you want a new range class with the endpoints having bidi level, line affinity, … ? 15:26:14 SW: Think your initial point is more pressing. A new selection algorithm we would probably not make live. 15:26:45 … if you want to change things you listen for a selection change and re-get the selection. 15:27:39 OV: If you hold on to live ranges, you get a lot of slowing down 15:27:48 … you could have deadSelection/Range … 15:28:16 FR: If we say we cannot drop ce=true, I think we should get around specifying it properly. 15:29:01 … if execcommand takes in we have a whole set of new dragons to specify. If we have a new API, we don't get a herd of dragons. 15:29:02 wilsonpage has joined #webapps 15:29:12 SW: Think it would work OK with execcommand. 15:29:38 … worried that we will not specify execcommand in the short future. It will take a monumental amount of work to get the spec complete and implemented. 15:30:53 … I'm not sure where it is going. So if we want to do something like this we have to pave our own way. Think that's fine, and might help improve execcommand, but don't think these should block each other. 15:31:14 SW: Anyone else get pressure to implement multirange selection? 15:31:25 OV: Not much. For flexbox a bit. 15:31:42 FR: Have heard some statements saying that it would be a nice thing to have for a better world 15:31:53 OV: There are people who believe that, but not sure about users. 15:32:05 SW: That's pretty much our case too. 15:32:30 Ilya: how does it benefit web authors? 15:32:43 RN: Most common is table column selection. 15:32:51 SW: Don't think it helps authors, the drive is users. 15:33:19 OV: More about copy paste than anything else. Select something that has a position fixed in the middle that you don't want there (except when you do want it there) 15:33:48 EC: Shifting problem from cannot do it to "how do we make a UI" we learn a lot. 15:34:04 OV: There are not specific requests, but it does come out of more general requests. 15:34:12 rniwa has joined #webapps 15:34:34 EC: question for e.g. editor developers 15:34:45 Johan: We fake up table column selection… 15:34:55 PK: It isn't extremely critical, it would be nice. 15:35:25 … some of our algorithms wouldn't handle multi ranges 15:35:52 RN: Think a pain point is range can get into a messed up state. If you don't allow ranges to be modified, and they have to be sane, it would be good. 15:36:01 FR: Why not just get exception for doing dumb tings? 15:36:10 RN: Lots of edge cases to deal with 15:36:16 OV: It is slower, is one problem. 15:36:24 … but probably OK. 15:37:03 OV: giant tables can be arbitrarily slow 15:37:12 SW: But isn't something people would do with real selection... 15:37:38 @xiaoqian: perfect. very interested if there is anything blocking implementing IME entirely in JS. 15:39:06 SW: Only argument in favour of existing DOM selection is not duplicating API surface area. 15:39:25 OV: That is a big pro… 15:40:07 … the big con is live ranges. 15:40:20 SW: Maybe we start down this and then decide dead ranges are more efficient. 15:40:42 OV: What appkit does makes total sense. 15:41:01 … difference between getting a list, and querying into a list is important. Getting a list is clearer. 15:41:14 SW: There is a cognitive burden. If we did it today we would return a JS iterator. 15:41:20 … so you have to iterate it each time. 15:41:44 FR: So arguments for new API: dead vs live, cognitive load, collision detection 15:42:03 RN: If only browsers can make the selection... 15:42:13 OV: We would not do that. Why only the browser? 15:42:52 s/OV: We would not do that. Why only the browser?/… we could create multirange selections limiting what users can do to select/ 15:43:01 OV: That limits code selection. 15:43:28 FR: the thing with a floated section in the middle of somewhere won't let you include whether you pick the thing in the middle or not. 15:43:35 SW: Being able to construct a selection is important. 15:43:42 EC: Also becuse you need to be able to restore it. 15:43:52 SW: And you would be limiting what browser can do in the future. 15:44:28 OV: I am much more comfortable with multirange that returns iterator, and even more so if the object weren't live. 15:44:47 SW: SHould think about how we can get away with that. I guess we have don that before. 15:44:58 FR: So what happens to the current one? Do we develop it as well? 15:45:30 OV: Other problem with firefox' is that start and end don't make sense in a multi-range world. 15:46:41 … ranges should have anchor and focus. First range is anchor range, last is focus. 15:47:27 FR: Do we want to support "out-of-order" ranges? 15:47:37 OV: To match visual you have to do that. 15:48:04 EC: How do we want to manipulate the selection? In its entirety, or each range? Then you run into collisions… 15:48:14 RN: What if we only allow setting an array of ranges? 15:48:29 SW: This isn't going to be expensive. 15:48:40 OV: It will if you disallow overlapping. 15:49:15 RN: You could just normalise when you make overlapping ranges. 15:49:23 OV: Normalise we do is in a copy of the selection. 15:49:42 SW: Think the big thing we need is more implementation experience. 15:49:52 OV: Are you going to do that? 15:50:01 SW: Yes, we're planning on doing it... 15:50:14 OV: Would love to see dead ranges, iterator, @@@@ 15:50:21 … would be nice to pare it down, too. 15:50:43 … setbase and extend doesn't match the rest of the API 15:50:55 RN: Think that came from web compat requirement. 15:51:38 SW: Should add new names for setanchor/focus. 15:51:41 OV: right. 15:55:07 [noodling on ideas for a new potential selection object, ranges…] 15:55:50 wilsonpage has joined #webapps 15:57:26 EC: Next order of business would be to define reasonable behaviour for copy. 15:57:30 OV: and paste. 15:58:00 … don't think we should spec execcommand in a hurry, but cut/copy/paste would be good. 15:58:58 JW: Clipboard API wanted updates to that. I preferred they put methods for security etc in clipboard API, and in execcommand we could just point to their spec, so they don't rely on each other. 15:59:16 OV: mostly care about the behaviour of what copy does. 15:59:39 JW: We asked for a copy method, they said it will come. Until then they update execcommand on those points. 16:00:08 FR: Do we think ce=true and execcommand should be done in a decade or so? 16:00:12 [yes] 16:07:00 estellevw has joined #webapps 16:34:02 weinig has joined #webapps 16:38:15 jyasskin has joined #webapps 17:49:46 weinig has joined #webapps 18:01:59 smaug has joined #webapps 18:08:18 wilsonpage has joined #webapps 18:48:08 tyoshino_ has joined #webapps 18:48:19 othree has joined #webapps 18:49:22 mihnea_____ has joined #webapps 18:51:33 igrigorik has joined #webapps 19:13:45 weinig has joined #webapps 19:35:03 estellevw has joined #webapps 19:58:07 wilsonpage has joined #webapps 20:11:01 weinig has joined #webapps 20:55:15 weinig has joined #webapps 21:00:57 estellevw has joined #webapps 21:36:04 Florian has joined #webapps 21:50:54 Florian has joined #webapps 21:54:36 Florian_ has joined #webapps 21:54:39 johanneswilm has joined #webapps 21:54:40 wilsonpage has joined #webapps 22:36:36 Florian has joined #webapps 22:58:33 Florian has joined #webapps 23:38:35 Florian has joined #webapps