07:03:12 RRSAgent has joined #webapps 07:03:12 logging to http://www.w3.org/2016/09/22-webapps-irc 07:32:57 anssik has joined #webapps 07:39:41 ericc has joined #webapps 07:45:54 cabanier has joined #webapps 07:47:34 jungbin has joined #webapps 07:48:22 dom has joined #webapps 07:50:38 smaug has joined #webapps 07:53:02 wilsonpage has joined #webapps 07:54:24 jamesn has joined #webapps 07:59:02 Florian has joined #webapps 07:59:45 chaals has joined #webapps 08:00:30 johanneswilm has joined #webapps 08:01:22 garykac has joined #webapps 08:02:36 kawai has joined #webapps 08:03:24 Meeting: Web Platform - editing APIs 08:03:28 Chair: chaals 08:03:40 Chair: Léonie 08:04:05 enrica has joined #webapps 08:04:19 Agenda: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-22TPAC-3.md 08:05:07 aboxhall has joined #webapps 08:05:08 nainar has joined #webapps 08:05:13 kenneth_ has joined #webapps 08:05:32 tantek has joined #webapps 08:05:55 LJWatson has joined #webapps 08:06:47 kinjim has joined #webapps 08:07:23 Scribe: chaals 08:07:54 Topic: intro 08:09:08 Present+ Yves, Chong, GaryK, OlliP, Enrica, Chaals, Léonie, Johannes, Kochi, DomC, Yoshi, Yoisho, Hayato. 08:09:30 bz has joined #webapps 08:09:36 jungkees has joined #webapps 08:10:25 agenda+ input events 08:10:35 agenda+ event order 08:10:40 agenda+ other issues 08:10:50 Topic: Input events 08:11:18 JW: input type with spellchecker. Last time we said we may need something more general, replace a text node. 08:11:26 present+ 08:11:32 present? 08:11:34 bz has left #webapps 08:11:35 … suggested we use spellchecker. benefit is we get more information about why the change happened. 08:11:42 present+ MarkV 08:11:49 Zakim: help 08:12:43 https://w3c.github.io/input-events/ 08:13:10 Gary: UIEvents gives base definition, the rest of the editing stuff is collected into the input-events spec. 08:14:10 JW: 5.1.2 in the input events spec. The one called insert non text - previously replace content, so the proposal is to be explicit that this is a spellchecker. So can it only come from spellchecker, or e.g. making something all caps? 08:14:18 Enrica: Think it should. 08:14:53 JW: Couldn't be insertText - *can* go across element boundaries 08:15:08 kbx has joined #webapps 08:16:21 Enrica: is nonText an HTML fragment? 08:17:15 JW: Can be 08:17:57 CMN: It's mostly text. The key is that it's something "semi-automatic" working quite probably in the background, as opposed to the user at their point of attention… 08:19:12 enrica: If you're replacing a word across elements - e.g. for bold and non, how do you decide what the result is, bold or not.. 08:19:27 kawai_ has joined #webapps 08:20:08 JW: Right now nobody has a smart way to do this much, and it's for the user agent. 08:20:19 plh has joined #webapps 08:20:22 rniwa has joined #webapps 08:20:43 [bikeshedding...] 08:22:15 RESOLUTION: insertReplacementText 08:22:43 Topic: IME 08:23:18 JW: We can't stop IME mid-stream. This makes collaborative editors hard. 08:23:23 Present+ Travis 08:23:45 … latest approach comes from Chong - divide the IME stuff so some events can be cancelled, some not. 08:24:23 … some IMEs just insert new characters. We get some input events that cannot be canceled, and at the end of construction we get a removal and a reinsertion, which we can cancel / handle in JS. 08:25:14 … there are cases where we have some text that needs to be fed into the IME. For this we get a new beforeInput event before the construction starts, and if that is not cancelled deletes the curent word 08:25:58 Florian has joined #webapps 08:26:02 … and starts construction in its place. This can be canceled - if you cancel it, the initial word will be there as well as the replacement. 08:26:30 CZ: If you cancel onInput you want to be in the state before then. 08:26:45 … but in some IMEs you can start the composition from existing text. 08:27:06 … so we can't just remove the composition, or you lose the text that was there before. 08:28:19 … so we make a text replacement happen, which allows us to separate it into deletion and insertion which are cancelable, with the composition happening in the middle. 08:29:02 JW: This is only if you preventDefault - then you have to remove the text yourself. 08:30:28 chongz has joined #webapps 08:30:33 https://github.com/w3c/input-events/issues/33 08:31:51 Travis: In a spellchecking scenario, the UA is going to try to change something, fires an event, you can cancel there and you're in original state. If you don't cancel, you remove word and replace… 08:31:58 Ching: This is only about IME. 08:32:28 … everything during it is non-cancelable. so we have the two cancelable pieces at start and end, deleting something and replacing it. 08:33:06 JW: If I preventDefault and delete the word myself, I can still get the insertion at the end to allow the actual composition to take place. 08:33:32 bkardell_ has joined #webapps 08:34:08 enrica has joined #webapps 08:34:51 CMN: this actually works fine for spellcheck if you do it that way. Which is a good thing, IMHO. 08:35:25 GaryK: If you preventDefault on first deletion, does that stop the IME? 08:35:42 Ching: No. The composition and insertion is still going to happen. 08:35:47 enrica has joined #webapps 08:36:28 Gary: you cannot cancel within the composition, but you can cancel the insertion at the end, what if you do. 08:37:11 https://github.com/w3c/input-events/issues/34 08:37:18 MarkVickers has joined #webapps 08:37:24 yosin has joined #webapps 08:37:41 present+ MarkVickers 08:37:49 https://github.com/w3c/input-events/issues/33 08:38:08 Etherpad available for describing steps: https://pad.w3ctag.org/p/22-09-2016-editing 08:38:13 Chong: Issue 33 is about the first cancelable event, 34 is about the one at the end. JS doesn't need to worry what is happening in the middle 08:38:25 yosin has joined #webapps 08:38:29 JW: Except that you need to know not to make a mess in here while compositoin is going on. 08:39:29 [so if composition is going on and on, you probably want an unblocking thing…] 08:41:05 JW: If people are typing japanese and working on long chunks, they can commit a piece of composition and restart with the rest of what they are working on, as necessary. 08:41:22 … should we go with this? 08:41:27 [general nodding] 08:41:56 Gary: We have lots of deleteby and insertby. I don't know if people are going to want to catch all of these, because it's a long list. 08:42:10 JW: Here we are reducing a bit the number of different types we have. 08:42:36 Travis: So is there a way to catch "deletion" without caring what type it is? 08:42:46 [Smaug nods] 08:43:24 RESOLUTION: Yes we can do the issues 33/34 proposal for cancelable at each end of IME. 08:43:54 Topic: catching inserts / deletes 08:44:26 Gary: If we strictly use insert and delete as prefixes for events, maybe format* as well, makes it much easier to catch all events. 08:45:06 JW: Yep, seems reasonable. 08:45:26 CMN: +1 08:46:09 Smaug: Why categorise everything using one attribute? Why not type and subtype… 08:46:32 … inputType with 200 different things doesn't seem what you care about. 08:47:27 JW: Question is who will use this. So far I see maybe a dozen editors, and they are the customers for this. Making your own editor for your homepage seems unlikely, given the size of it. 08:48:05 … don't mind whetere we use subtypes or prefixes. But I don't think we are talking about a mass-market of developers here. 08:48:16 s/whetere/whether/ 08:48:41 Smaug: Think splitting this would be nicer ergonomics. 08:48:55 Gary: what other input types do we have - can we categorise them easily? 08:49:07 smaug: we have insert, delete, modify? 08:49:14 gary: format. 08:49:35 JW: And history 08:49:49 Travis: They are insert and delete when you do them. 08:49:58 JW: Browser doesn't know the transaction history 08:50:04 Gary: For browser stack only 08:50:32 JW: editor has to maintain its own undo stack - this came from the discussion at last meeting, you *cannot* use global stack 08:50:53 IanPouncey has joined #webapps 08:50:55 glazou has joined #webapps 08:50:58 Travis: So you implement the user's intent to undo on your own. If you don't cancel those, you don't know what will happen. 08:51:05 Present+ Glazou 08:51:57 JW: e.g. MS Office or Google Docs maintain different history stacks for different input areas. And that seems reasonable. 08:52:09 Travis: undo/redo notifications aren't associated with input 08:52:33 enrica has joined #webapps 08:53:15 Gary: it's likely that this is some kind of modification. It isn't guaranteed, but it's probably the case. 08:53:36 Chong: for copy/paste, beforeInput shouldn't care about history or keyboard, just about DOM updates. 08:54:08 … if you prevent undo for input, the history stack still pops. if you preventDefault for cut, it only prevents deletion of the word ubt it still goes to the clipboard. 08:54:51 JW: You don't know the browser would do an update. Maybe the browser won't delete something because it thinks you are in the wrong place, but the editor still needs to handle it. 08:55:07 … we used to have movement, but that went away. 08:55:24 Travs: Doesn't feel right, but can't put a finger on why. 08:56:07 Gary: Making beforeInput catch everything is a decision taken a while ago. 08:56:26 Enrica: This is about DOM mutations, but there are some exceptions. 08:56:35 Travis: Think this is about user intentions… 08:57:25 … so there are things that don't feel like input in terms of "here is some text" 08:57:49 Gary: This isn't fired for everything, only things that are likely to mess with the DOM. 08:58:01 Travis: Maybe this is just a bikeshed on the name… 08:58:25 [And tra-la-la, we bikeshed the name] 08:58:32 hyojin has left #webapps 08:58:37 Glazou: Gecko used "editType" 08:58:52 s/Type/Action/ 08:59:38 Travis: Let's table that and think about it some more. 08:59:53 Gary: This goes with the inputSubType discussion too, right? 09:00:16 jnurthen has joined #webapps 09:00:17 … but we do need to make sure tehre is an easy way for developers to collect all of a class of events. 09:00:38 … my concern is that if we get too granular we might cut off things we want, later. 09:00:51 JW: So we are lookng at delete, insert, format, history … 09:01:43 Travis: There are complex properties here… directions and so on. 09:02:12 Gary: We can get lost in this, but stripping the top level seems worthwhile. 09:02:27 [break - and then undo history] 09:03:39 jamesn has joined #webapps 09:08:12 dcooney has left #webapps 09:14:39 LJWatson has joined #webapps 09:20:44 enrica has joined #webapps 09:21:59 Topic: Undo Redo history… 09:22:17 JW: Ojan asked if we should have a different category, how should it relate to general system stack… 09:22:49 Florian has joined #webapps 09:22:51 JW: CKEditor tried to build on top of a browser's history. Doesn't work, since they handle the events themselves there isn't any history. 09:23:02 chongz has joined #webapps 09:23:20 … we want a way to say that some element is not handled by global history, then how do you enable/disable the various undo menus? 09:23:38 Undo/redo https://github.com/w3c/input-events/issues/36 09:24:01 … Ryosuke had a proposal for enabling/disablign features. You can add undo/redo given that it's available. 09:24:27 Travis: for contentEditable we don't have a dedicated element - would need to be applicable to all elements. Is it applicable globally. 09:24:48 Gary: With multiple undo stacks - e.g. Office, GoogleDocs, I don't see how a global attribute would work. 09:25:03 Travis: No, just that you can apply it to any element 09:25:29 Gary: seems like it would work… 09:25:38 … going to be ugly to find 09:26:00 Travis: And you have a tree - can you disable it further down the tree, and reneable it even deeper? 09:26:02 https://github.com/w3c/input-events/issues/32#issuecomment-248762122 09:26:31 JW: The proposal (see link above) is an attribute for the container of contentEditable. 09:26:55 enrica: there are other features we want to enable or disable - bold, spellcheck, whatever. 09:27:11 Gary: Would be nice if you culd find the container that is editable 09:27:15 JW: editingHost. 09:27:44 Gary so it is there, or not there. You wouldn't find it on some other element somewhere else. 09:28:00 Travis: Is it time to add the "editSection"? 09:28:15 s/?/ element? 09:28:20 Enrica: Why? 09:28:42 Travis: Once you put something into contentEditable state, there's a whole lot of special magic. 09:29:00 … like where attributes only apply sometimes, depending on type. 09:29:26 … so if, when you become contentEditable you start getting a whole lot of possible extra things to do, then we're following the anti-pattern of input. 09:30:01 … Or we can subclass elements and make a specific element that would be the editing host. Then the attributes are specific to that element and not going to hang on any element… 09:30:21 JW: This doesn't sound unreasonable, and might clarify contentEditable. 09:30:38 Gary: That's the way this should have been done, but what is the cost of the transition to there? 09:30:44 … this is a big task to do that. 09:30:51 IanPouncey has joined #webapps 09:31:28 Enrica: think we can spec the attribute now, and if we do the new element, we can add that. 09:31:38 Travis: You could describe the attribute but not commit to it. 09:31:52 Smaug: implenenting a new element is trivial. And it would simplify the platform a lot. 09:32:08 Gary: have a new element now, stripped down so it just gets basic functionality. 09:32:38 Chong: Would we allow disable copy? 09:32:51 Travis: I think we can answer that question orthogonally. 09:33:12 … if there is a feature we need to add, it would be easier to do it if we had a specific element to which that would apply. 09:33:37 Chong: some actions like disable copy don't necessarily apply only to contentEditable. 09:33:57 Travis: Copy could be blocked generically. 09:35:33 CMN: There is a transition path, if we only put nice new stuff onto the editor element. 09:35:55 Gary: If we make an element, is it going to be a bucket to fix everything before we ship? 09:36:24 JW: The discussion of fixing the other parts is something we want to take - selection normalisation, how do we get around it, etc.. this is a mega task. 09:37:38 Gary: If we make a starting point, and don't aim to fix everything before we actually ship the element 09:37:50 CMN: Yeah, that's the only logical approach. 09:38:09 Enrica: So a new element thta will behave as contentEditable, plus new features. 09:38:16 Gary: Right. 09:38:49 JW: So an issue for switching. On the JS we were told we cannot fix things in contentEditable because there is legacy. But in the new element if we inherit the legacty we have a problem. 09:39:31 Gary: Right - this is the issue. If we were going to fix something broken, we're saying "but we are not going to make something different from contentEditable". 09:39:46 Smaug: Don't see how adding the element makes anything worse. 09:40:06 Gary: If we have a gating function, of fixing everything, then it slows us down. 09:40:41 JW: Getting to a more fixed version is to change the values of the contentEditable attribute. If we do it with a new element, we need a flag that covers e.g. version. 09:40:51 Travis: That is still fine. 09:41:24 Gary: If we can version it, then we are fine for dealing with legacy, and that means we should do it now rather than later. 09:41:43 Travis: We can scope the problem space better if we have the element. 09:42:23 JW: Can we do versioning already? 09:42:37 smaug: we start with mode="legacy" 09:42:44 CMN: or mode="broken" ? 09:42:47 enrica has joined #webapps 09:43:01 Travis: It isn't a major effort to implement the element... 09:43:08 yosin has joined #webapps 09:43:09 Gary: Right, it's a management issue 09:43:45 RESOLUTION: We think that this makes sense to propose something concrete 09:44:18 [in which bikeshed do we do the work?] 09:44:53 i/Travis: Is it time to add/Topic: Editing element? 09:45:05 Topic: Undo / Redo stack popped 09:45:18 dom has joined #webapps 09:45:19 Gary: We have a bunch of attributes that can go on this new element. 09:45:36 JW: history management, interaction with browser undo/redo functions 09:45:42 Gary: cut/copy/paste? 09:45:45 JW: Yep. 09:46:06 Enrica: thought this is all the different features we can enable / disable 09:46:38 smaug: do we need these things on input, textarea 09:47:04 Gary, Kochi: you don't need it 09:47:13 … no rich text editors in input 09:47:18 [well, sort of] 09:47:45 s/Kochi/Yoshi/ 09:47:46 CMN: Nope, if you want rich features use the new element. 09:48:13 Travis: Will you want system undo/redo inside the editable element? 09:48:27 JW: You need to use that if you handle anything… 09:48:42 Gary: Is there any use case for it? 09:48:46 JW: Never seen one. 09:49:10 Travis: So we could make system default "no system undo stack"… 09:49:22 Gary: We should try that at least. 09:49:25 CMN: +1 09:49:34 JW: Or allow turning it on... 09:50:10 Gary: Supporting it at all seems odd if there isn't a use case. 09:50:22 JW: It is possible there is a use case, just can't find one. 09:50:31 Travis: Sounds like work to turn it off. 09:50:45 Gary: if you turn it off you get the saving of not managing the events 09:50:56 Travis: Yeah, although I need new logic to turn it off. 09:51:25 Gary: So if you can ssume undo won't happen, you get big runtime benefits, but there is some more code complexity if you have to be able to enable them. 09:52:02 Yo1: What do you mean about enable/disable? Control the menu item from javascript? 09:52:05 LJWatson has joined #webapps 09:52:17 Gary: Yes - JS can tell the browser about UI things 09:52:53 jungbin has joined #webapps 09:53:14 Yo1: so the undo stack is created - if the JS calls appendChild, this doesn't go to the undo history. 09:54:05 Travis: Right. But the JS that did the appendChild knows it did, and it is creating its own stack. It needs to make it look like there is history, so the browser needs to allow an undo event that the JS that will then capture and process. 09:54:19 Yo1: JS adds to the history? 09:54:26 Travis: Manages its own history. 09:54:36 … it could be done automatically, in theory 09:54:44 JW: That would be complex. 09:54:55 [example of why undo histories are awful] 09:55:59 … I write ten things in a paragraph in a collaborative editor, my colleague deletes that paragraph, I need the ten things popped off the stack. Do we try to tell the browser how to manage the history, or just say "let the user do "undo" and tell me, and I will manage that in my JS 09:56:29 wilsonpage has joined #webapps 09:56:46 … the idea in beforeInput is that you get things from the browser related to what teh user wanted, which is better than by trying to trap keypress events and guess what the user wanted. 09:57:59 Chong: We need two attributes - control which context menu will be shown, second is to show undo or redo... 09:58:18 CMN: It's just "please enable undo in your interface" 09:58:39 JW: there is also "does global history apply" 09:59:01 Travis: and "should context menu appear at all"? 09:59:12 Chong: what if everything is disabled? 09:59:41 Gary: It's a UX decision. But don't make the menu disappear because then the user doesn't know if they get no menu because they did the wrong thing or because it was disabled. 09:59:51 present+ AnnevK 09:59:57 kbx has joined #webapps 10:00:12 [yep, this is UI that the browser should be able to manage] 10:00:39 Gary: Instead of a boolean for canUndo you suggested something else? 10:00:54 JW: No, I just wanted to have booleans for the functions. 10:01:25 Yo1: Sometimes in UI you have context information to hint at what will happen in the undo 10:01:36 Gary: We could add that later… 10:01:48 s/in the undo/in the undo. Localisation is a mess there. 10:02:45 glazou has joined #webapps 10:02:47 JW: Recap: We make the element, that can be versioned. It can do contentEditable plus Ryosuke's proposal of turning on/off features. Current features are the different inputTypes, and global history 10:02:58 Enrica: We had contentEditable="*"... 10:03:18 JW: This will take over from that. All the new ones that haven't been made, will only be implemented in the new element. 10:03:40 Enrica: So a page that uses it will only behave in the old way 10:03:44 [Yes] 10:03:46 jcraig has joined #webapps 10:03:54 kinjim has joined #webapps 10:03:56 Enrica: So why do we need the versioning? 10:04:27 JW: Because we will inherit legacy problems, and want a way to say "OK, we will fix that in a new version mode" so we can fix problems stepwise. 10:04:46 Enrica: beforeInput will only be fired for the new element, and not for 10:05:07 Gary: Sort of - it will fire on input elements 10:06:18 JW: It will for legacy behaviour, but the idea is to have an HTML element that collects. 10:06:37 Annevk: What happens when you mix the attribute and element? 10:06:50 Travis: These are the same problems we already have with the attribute. 10:07:08 Annevk: not sure how it make sense if you tie undo/redo to the existence of the editor element 10:07:41 Travis: We want to give a lot of new properties to the editor. And we prefer to have a single element contain these, instead of further adding to global things that can accompany contentEditable on any element. 10:09:06 LJWatson has joined #webapps 10:09:45 Annevk: I'm worried that you are going down the XHTML2 path… 10:09:54 Travis: That risk is valid… 10:11:35 [disussion about evolution] 10:11:42 s/disu/discu 10:13:00 LJWatson_ has joined #webapps 10:14:29 ericc has joined #webapps 10:15:06 enrica has joined #webapps 10:15:28 Glazou: SO will you be able to express, in the brave new world, what contentEditable does? 10:15:28 jnurthen has joined #webapps 10:15:34 [Yes. (we hope)] 10:15:46 IanPouncey has joined #webapps 10:16:41 Yo!: Why do we need to support the current legacy in the new version? 10:16:51 JW: I also thought that... 10:17:04 … but all the stuff only works in execCommand, and so on. 10:18:27 [so we can make a transition easier] 10:19:54 Glazou: this is document-wide, not element wide. If you have multiple editing elements, with different features turned on/off, that will be tricky. 10:20:12 … there is also designMode, which is document-wide. 10:20:26 … so there is nowhere to make the editor element replace that. 10:20:44 Travis: In practical use cases it is an iframe. 10:21:10 Glazou: Not necessarily. It is still feasible, and there are intranets that do this. 10:21:50 …anyway, we need to think about designMode 10:23:14 Enrica: caveat I see fora new element is that there are many cases where the attribute leverages the fact that you can put it on any container. Do we want to go down the path of a container? Are we making a monster - can we turn it on and off inside the subtree? 10:23:23 JW: That's a requirement for us. 10:23:57 DG: Implemented templates inside contentEditable, through CSS property that prevents selecting, modifying etc. 10:24:26 … an editable container nested in a non-editable, nested in an editable, is a case we need to deal with. 10:27:08 jungbin has joined #webapps 10:30:14 LJWatson_ has joined #webapps 10:30:59 david_wood_ has joined #webapps 10:31:23 present+ 10:35:13 [break until 11.50] 10:38:43 atotic has joined #webapps 10:39:30 LJWatson has joined #webapps 10:46:27 enrica has joined #webapps 10:49:28 johanneswilm has joined #webapps 10:51:56 Topic: Static range 10:51:56 Smaug: Why? 10:51:56 Gary: there's a range. Issue is that it keeps up to date with manipulations, which is expensive. 10:51:56 … concern that putting a range in an event and someone copies it, you have to do all the calculation, even if they never actually *use* them. 10:51:58 … There was pushback on using ranges. We wanted it for beforeInput, but didn't want to put a full range there because it would be expensive. But it would be nice to have a lightweight snapshot you can use for some things. It will be invalidated if there are changes. 10:52:07 Smaug: You don't know if what you are getting is valid or not. 10:52:07 Gary: right. if you have a cascade of event handlers that modify the DOM, we have a tricky problem. We have getTargetRanges which sends a snapshot, but you can upgrade to a real Range if you care, but you hould opt into that becaus they are expensive 10:52:07 Smaug: Does range perfomance show up in profiling? 10:52:22 JW: We were told not to add ranges by browsers because they wouldn't implement 10:52:31 Smaug: Is this implementation or specification 10:53:23 Enrica: We track all ranges. By giving a range within an event, instead of being able to request the range live, you get problems. 10:53:56 … being able to request the range at the moment you want it is better than having an invalid snapshot that comes from when the event started. 10:54:10 glazou has joined #webapps 10:54:10 Smaug: this is still a static range so can go invalid again. 10:54:20 Enrica: Sure, but you can keep requesting it. 10:54:33 Smaug: You will need to create new static ranges all the time 10:55:29 Enrica: With range, you *must* create the new thing on every change. Whereas being able to request, you can reduce the number of ranges you create, 10:56:49 Olli: Web developer has to request the static ranges.. 10:57:02 AnnevK: Do you need a lot of those? 10:57:23 Gary: You can still get a real range. But the cost of forcing that everywhere is really high 10:57:53 Smaug: I am worried that this will be error-prone for developers. You don't know when they stop representing reality. 10:58:28 s/Do you need a lot of those/Do you keep the static ranges around, or make a lot of new requests for them?/ 10:59:20 JW: When we use these in editors, we just occasionally want to get the range, make a change, and if you want an update you request the new static range. But you don't need it very often. 10:59:54 Smaug: Why do you keep the event alive? 11:00:03 Travis: To track undo stack 11:00:39 [discussion about usage patterns for ranges] 11:02:04 jamesn has joined #webapps 11:03:02 Yo1: There are use cases where live range is actually not helpful, and you *want* a static range. 11:04:04 … having liveness everywhere makes heavy browser implementation and leads programmers down bad paths. 11:05:04 Enrica: Ojan said, we agree, beforeInputevent gives you the situation before everything happens. So you *want* that to represent the situation at that time, not be updated… 11:05:56 Smaug: I would like to see the performance profile... 11:07:49 [bikeshed on name...] 11:08:24 Smaug: This should be a dictionary. 11:08:40 enrica has joined #webapps 11:08:41 AnnevK: That makes it clearer that it isn't going to update. 11:09:15 Gary: We return an array of these… 11:09:27 AnnevK: You can return a sequence of dictionaries. 11:10:10 … static range as platform object has some dodgy characteristics. Dictionaries are pretty stable. 11:10:42 Travis: Like this. 11:10:49 Gary: Makes sense conceptually. 11:11:05 Travis: So instead of interface, you say dictionary 11:11:09 Smaug: Yep 11:11:22 Yo1: But using a dictionary, typecheking is harder. 11:11:43 Travis: Yes, but not clear what you would need that for. You could add .type or something. 11:12:18 Yo1: You can't do static typechecking… 11:12:30 Travis: You don't get that anywhere else in JS… 11:12:44 Gary: If you have a .type then you can make a static typechecker 11:13:11 Travis: Sure, but JS in general is not typed - you have to add a layer that covers that. 11:13:23 … a dictionary is a typed object in WebIDL. 11:13:54 … there is a formalism for static range as a dictionary 11:14:01 Yo1: OK, that works. 11:14:25 RESOLUTION: Interface should be turned into dictionary. 11:15:19 RESOLUTION: Move forward with static ranges. 11:16:27 Topic: Static range can be affected by getTargetRange? 11:16:34 kinjim has joined #webapps 11:16:43 kinjim has left #webapps 11:16:51 Gary: Actually they are just associated with, not affected by. There is no action going to happen to this. 11:17:05 … think it's just a wording confusion. 11:17:31 JW: If I merge two paragraphs, they are associated with the event, even if the range is in the middle of them... 11:17:48 Gary: Yes, but we say the thing associated is the middle of the paragraph. 11:18:16 Smaug: What if you remove the entire contentEditable and then ask for getTargetRange ? 11:18:36 DG: You get the dictionary, but they are collapsed. 11:18:57 s/collapsed/removed from the document 11:19:44 Smaug: Needs to be specified what happens. 11:20:16 Enrica: Shuld be defined to happen the same way as it would in a live range. 11:20:57 Smaug: during dispatch you have a range that you use to create the snapshot 11:21:35 Gary: current selection is managed somehow. This is saying "so snapshot that" 11:21:39 Smaug: OK 11:22:02 Smaug: If we already have that range, why not give it out? 11:22:30 gary: Because if you want the snapshot, that you copy and cache, … 11:22:50