Re: [selection] Selection.setBaseAndExtent
For what its worth, we plan to remove base and extent from Blink/Chromium ( https://code.google.com/p/chromium/issues/detail?id=230267). We've found that developers do not understand the difference between focus/anchor and base/extent, and since it is only supported by WebKit based browsers, it is not heavily used. On Wed, Aug 6, 2014 at 12:58 PM, Ben Peters ben.pet...@microsoft.com wrote: I don’t understand the difference. setBaseAndExtent would then set all 4 of these properties of selection? Do you have a definition to use for this? *From:* Ryosuke Niwa [mailto:rn...@apple.com] *Sent:* Wednesday, August 6, 2014 12:43 PM *To:* James M. Greene *Cc:* Ben Peters; public-webapps *Subject:* Re: [selection] Selection.setBaseAndExtent Focus and anchor are different concepts from base and extent. While the former always coincide with start and end, base and extent may be different from those two. In particular, when a user selects text by double clicking on a word, base and extent stays at where the user had clicked while focus and anchor will extend to the beginning and the end of the word like start and end. - R. Niwa On Aug 5, 2014, at 4:58 PM, James M. Greene james.m.gre...@gmail.com wrote: For consistent terminology with the rest of the API, shouldn't it be `setAnchorAndFocus`? Sincerely, James Greene Sent from my [smart?]phone On Aug 5, 2014 5:54 PM, Ben Peters ben.pet...@microsoft.com wrote: I have added proposed text to this bug. Any objections to this? Proposed text, based on the text for collapse(): void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The method must throw an IndexSizeError exception if offset is negative or longer than node's length ([DOM4]). Otherwise, it must create a new range, set ([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, extentOffset), and set the context object's range to the newly-created range. *From:* Ben Peters *Sent:* Tuesday, May 20, 2014 11:37 AM *To:* Ben Peters; Ryosuke Niwa; public-webapps@w3.org *Subject:* RE: [selection] Selection.setBaseAndExtent I have filed a bug to track this issue [1]. Ben [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831 *From:* Ben Peters [mailto:ben.pet...@microsoft.com ben.pet...@microsoft.com] *Sent:* Monday, May 5, 2014 11:28 PM *To:* Ryosuke Niwa; public-webapps@w3.org *Subject:* [selection] Selection.setBaseAndExtent I noticed that some websites use selection.setBaseAndExtent [1]. According to what limited documentation I could find, it works similar to selection.extend. Is there any intention to standardize this, or is it made obsolete by selection.extend? Ben [1] http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
Re: [editing] Leading with ContentEditable=Minimal
Well stated. I like contentEditable=cursor. On Mon, Jun 23, 2014 at 9:21 AM, Robin Berjon ro...@w3.org wrote: On 17/06/2014 02:12 , Julie Parent wrote: If Intention events are (temporarily) moved out of scope, I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? The way I see it, that is indeed *all* it would do (and serve as a sanity flag so that browsers know how to handle this cleanly). It *is* an explicit API to enable cursors. It has the advantage of reusing an existing name so that we don't have to worry about what happens when you specify both; and it's declarative because that's what you want for such a case (notably so that CSS can style what's editable cleanly). We could rename it contentEditable=cursor if that's cleaner — the idea is the same (and I certainly won't argue bikeshedding :). -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [editing] Leading with ContentEditable=Minimal
On Fri, Jun 20, 2014 at 8:47 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 17, 2014, at 1:44 PM, Julie Parent jpar...@google.com wrote: On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. How does that work in mobile? iOS for example shows lollipops at the end of selections to trigger editing actions such as copy, paste, etc... if a web content was drawing its own cursor, then these UIs can't be shown for the user. It seems to me that what they want is to use the native cursor and do every editing operation themselves. The sad answer, at least for the Docs case I was referring to, is that they aren't using web content on mobile, they are writing native apps. Your point is still valid, but I think the selection API would need to be significantly extended in order for them to make use of it, rather than doing their own thing. In particular, they want to be able to draw multiple cursors (the primary user selection and those of collaborators) and to control the granularity of selection movement throughout different types of rich content, in a better way than you get by just using ce='false' regions inside an editable regions. It would be great to evolve to selection API to encompass these use cases as well, but I think that is outside the scope of this discussion. I'm also not certain how we're going to expose an element with cursor=true but commandEvent=false or cursor=false but commandEvent=true to an assistive technology. - R. Niwa
Re: [editing] Leading with ContentEditable=Minimal
On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. - If commandEvents are just events with no default action, can they not fire safely wherever cursor=true? If the page code does not listen for the event and react, nothing happens. If the page wants to do anything with a command event, it just needs to observe said event. True, and perhaps that could simply things. Events aren't free for the browser though, so there is a cost of having them fire needlessly. I'm assuming here that text insert is a commandEvent and that the page dev takes care of updating the DOM with inserted text (including partial edits with composition events). I guess that part is still up for debate :) I am further assuming CommandEvents refers to low level intent events like deleteToBeginningOfLine (although they could also eventually refer to boldSelection). I want to clarify that in my opinion cursor=true (or commandEvents=true) should in no way imply that the UA should show a WYSIWIG editing UI (bold buttons and context menu entries, etc...). My editor may be a code editor where a bold command makes no sense whatsoever and having bold button looks silly and confusing. I can imagine we would eventually create an API that allows page devs to tell the UA that certain WYSIWYG controls should be shown, and control their state, and they should fire commandEvents. This could be a nice additional building block for editor devs in the future. However the default should be don't show any UA-native WYSIWYG or text editing controls.
Re: [editing] Leading with ContentEditable=Minimal
If Intention events are (temporarily) moved out of scope, I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? On Mon, Jun 16, 2014 at 11:12 AM, Ben Peters ben.pet...@microsoft.com wrote: There’s been a good deal of discussion about the value of contentEditable=minimal. Some of us think that being able to cancel all browser actions with preventDefault on all Intention events is enough, while others believe that having a single way to stop browsers from taking action makes sense. I lean in the direction of the former, but there is another consideration- it will take more time to design and build Intention events in all cases, so why not work toward making contentEditable=minimal available, and then ship Intention events once we have a more complete story ready?
Re: [editing] CommandEvent and contentEditable=minimal Explainer
I certainly understand the concern that it would be impossible to properly catch and cancel all events. But I think that is somewhat the point - it forces browser vendors to get these parts right. All changes to an editable dom must fire an event before the modifications are made, and must be cancelable. Further, I'd say that if the number of events you would need to preventDefault on grows larger than selection, command, and maybe clipboard then that implies that we are not building the right APIs. On Sun, Jun 15, 2014 at 11:49 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: On Sun, Jun 15, 2014 at 5:15 AM, Olivier F teleclim...@gmail.com wrote: On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters ben.pet...@microsoft.com wrote: On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote: On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com wrote: Imagine as well a situation where a UA creates a new way to paste content, and to prevent confusion with paste they decide to create a new ua-prefixed event uaMagicPaste. Now our end-users have a way of pasting content into our editor's DOM without any intervention at all on our end, resulting in breakage and bugs. This is a good point. Registering for and calling preventDefault() on CommandEvent and BeforeSelectionChangeEvent will catch all new events in those categories, but ClipboardEvents must be listened to individually (Cut, Copy, Paste). We should consider whether we disallow new ClipboardEvent types or allow a generic ClipboardEvent listener, which would catch uaMagicPaste. I'll add a note to the Explainer for this. Yes, we could add ClipboardEvents and funnel all clipboard events through there, that would work. But I also noticed that Issue 3 was added: Do we need DragEvents too. And yes we do, good catch! It is totally possible to alter the DOM of a contentEditable by dragging something on top of it. I guess we can add DragEvents, but to me this illustrates why the practice of enumerating and capturing all current and future events to preventDefault them is not the right approach. For enumerate+preventDefault to work, every possible event that could change the cE's DOM has to fire correctly and cancel correctly. Every one. I can't help but to feel that there will always be something missing. Something we didn't think of in the spec, something the UA forgot to implement, some bug that prevents the event from being fully canceled, or some brand new interaction paradigm with its own event Class. Just one of these in effect in one major UA and editor devs all over are in pain. So long as enumerate+preventDefault is the only way for editor devs to control their editors, I'm concerned that there will be a constant source of difficulty trying to work around the leaks in the spec/ua/future, and that the end-user experience will continue to suffer as a result. I've got very similar feelings about all this. For years features have been randomly added to contentEditable=true and structuring them now seems for me as undoable. As I commented in [1] and [2] there are features related to contentEditable that do not fit in the CommandEvent and CommandQuery proposals very well. We agree that undo, clipboard and drag and drop interfaces have to be separated from commands. Why not other? Why all other features have to be pushed into commands section? If the commands' related APIs (I do not include very useful low level user intent events into that) and commands themselves will lack precision, then the only use that a cross-browser editor could make of them will be to disable everything. And we'll need to hope that we haven't disabled too much (e.g. clipboard events) or too few things, because imprecise spec will not clarify this. Less is better. Give us stable platform and we'll build great solutions on top of that. Make the platform unpredictable and we'll be fighting it the rest of our days. [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html [2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0876.html -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well?
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
Without default text input, the current proposal for contentEditable=minimal is essentially just enabling cursors (drawing them, dispatching events, performing default actions). Rather than calling the mode minimal, which is ill-defined, why not explicitly call it what it is: cursor-only? Or, have contentEditable take a list of features to turn enable: contentEditable=enable-cursors enable-CommandEvents. Or, rather than tying this concept to contentEditable, with all the assumptions and complications that brings up, why not expose this building block as a completely separate attribute? On Mon, May 26, 2014 at 1:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue yo...@chromium.org wrote: Range.style is cool idea! I assume Range.detach() removes styles added Range.style. detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach To implement text composition with this, I would like to have wave underline, dotted underline, thick underline etc. Range.prototype.style seems complex in the context of overlapping ranges and such. Suddenly you're no longer applying CSS to a tree. -- http://annevankesteren.nl/
Re: CommandEvent for user intentions
Have you seen the recent post about the rich text editor that Medium uses? It is a somewhat cheeky essay, including a mathematical proof, about how contentEditable is broken. The conclusion is that in order to move forward, we need to treat contentEditable as an API, rather than as a standalone component that tries to do everything itself. It discusses the idea of an edit intent API, which is very in line with this proposal for CommandEvents. https://medium.com/medium-eng/122d8a40e480 On Wed, May 21, 2014 at 11:51 AM, Ben Peters ben.pet...@microsoft.comwrote: Great to hear! I’m working on an explainer document that will be more descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on your questions should be made clearer there. I’ll update this thread by the end of the week with more details, and my initial thoughts are below. I strongly agree that something like CommandEvents is necessary: a web developer should be able to respond to the user’s intent, aka “selectAll”, rather than enumerating, listening to, and responding to each and every platform specific way that the intention to selectAll can be communicated. How encompassing do you envision CommandEvents? Would it only cover well known keyboard shortcuts and actions like those currently used by execCommand? I see this as being more than just well-known keyboard shortcuts. I would like web developers to be able to extend it for their own purposes. What about taking this further and providing better events in two distinct areas: those involving selections (intents like selectAll, but also selection modifications like caret movement by keyboard or gestures, selection changes, etc) and those involving input (including paste/drop/cut/formatting, but also basic text insertion via keyboard/voice/etc). This is a great idea! I'll include it in my spec. I’m not sure an extra event type is necessary here though: why not use beforeinput for the input events, and selectionchange for selection events? Ryosuke’s selection spec currently has a placeholder for selectionchange, and seems like the right place and timing to work this in? My current thought is that Selection events should be used for selection, and CommandEvent for things that would be in a toolbar or context menu. I think the design should make it easy to create and style toolbars based on the available commands and their state. Input events don't cover everything that would be in a toolbar, and they fire for things that already have events for user intentions (like Clipboard Events).
Re: contentEditable=minimal
I question whether contentEditable=minimal should actually handle text input. If the idea is to provide the base platform on which a developer can build the editing product of their dreams, isn't text insertion just another behavior they could potentially need to disable? Stepping back, there are distinct concepts that all combine to form the current editing environment: 1. Selections: Enable selections, perform cursor movement, scoping the boundaries on which the selection can operate. 2. Input: Perform dom modifications, dispatch events, not limited to keyboard input, also includes IME, paste, drop, etc. 3. Spell check: Enable spell check, modify the dom (or dispatch an event) when the user selects a replacement 4. Formatting magic: bold when the user hits control + b, change directionality on Ctrl+LeftShift , etc. It sounds like contentEditable=minimal as proposed would only enable #1 and #2, and perhaps allow for #3? To break editing down into true building blocks, I think we need to provide developers a way to explicitly enable each of these systems separably, and not require the element to be contentEditable. On Mon, May 12, 2014 at 9:26 AM, Robin Berjon ro...@w3.org wrote: On 12/05/2014 00:46 , Johannes Wilm wrote: Also this looks good. There seems to be consensus that contenteditable is just not going o get fixed, and so removing the faulty behavior entirely and replacing it with this would be almost as good. It depends on what you mean by fixed. It is conceivable that given enough time and energy the current contentEditable behaviour could be made interoperable, but the problem is that even if that happened it seems clear from developers' feedback that it wouldn't do what they want. A lot of the time you would still want to disable a lot of what it does by default and handle it yourself. This is therefore just intended as a way of providing developers with primitives for editing. Intercepting key strokes is already now possible and probably the best one can do. The one thing where this gets complicated is when typing characters using more than one key stroke. such as ~ + n to make ñ. I am not sure if you include that under the Some keyboard input handling. Yes, text input is a hard problem and you can't get away without solving it. We are talking about providing primitives here, so things can be expected to be a little bit hairy though. DOM 3 Events has something called composition events for the example you bring up (which can get a whole lot more complicated, notably with things like Kotoeri and such). On the face of it it would seem to be the needed part but I've never used them (or seen them used) in the real world. (The quality of browser support is also unclear at this point.) Some cases also require the IME API. Developers relying on the bare bones cE would probably have to handle the rendering of ongoing composition themselves (which isn't the end of the world, but you need to think about it or you are guaranteed to mess things up). This is probably acceptable at this level, libraries can make it easier. -- Robin Berjon - http://berjon.com/ - @robinberjon
