Re: User Intentions Explainer (was: List of Intentions)
I'm not sure if I remember correctly, but I believe that after long discussions we left the question what should contenteditable=minimal be? unanswered. First the intention events lists should be created, so we can see what needs to be handled. And this is what Ben Peters is working on. Still we may also take in consideration that there are limited resources available for working on the specs. Therefore the whole work could be separated into two *independent* topics: 1. Intention events + execCommand. 2. contenteditable=“minimal” That's what I was proposing as well - to have the base (which consists mainly of fixed selection API and intention events) ready as soon as possible, so hopefully browser makers can start implementing it and then we, editor makers, can start using it. This part will already improve the current situation a lot, but it's itself pretty hard as we can see. Then, if anyone will be still interested, a specification for default browser's actions can be created. It's a huge task and there are a lot of controversial topics like the famous delete/backspace behaviour when merging blocks and that's why I would not recommend starting these discussions right now. On Tue, Sep 9, 2014 at 12:59 PM, Frederico Knabben f.knab...@cksource.com wrote: On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote: I don’t think that browsers having time/will for it today is a good argumentation for not doing it. The specs have a critical and noble scope, of serving as reference for the future of the web. We’re talking about the future after all. Still we may also take in consideration that there are limited resources available for working on the specs. Therefore the whole work could be separated into two *independent* topics: 1. Intention events + execCommand. 2. contenteditable=“minimal” “1” should be concluded asap, because it is the foundation for the success of “2”. It is also compatible with the current contenteditable=“true”, so it should enable sites/frameworks to fix the current status of things. “2” is the ideal world. Something that would require much more energy to get done right. Still in the beginning, there should be an agreement on what’s in and what’s out. Following that, several specs can get started, each one defining the default behavior we want for each of the features we want “minimal” to have. The first ofc, would be “Selection” (and “Focus”!). -- Piotrek Koszuliński CKEditor JavaScript Lead Developer -- CKSource - http://cksource.com -- Follow CKEditor on: Twitter http://twitter.com/ckeditor | Facebook http://www.facebook.com/ckeditor | Google+ https://plus.google.com/107736718646302128806 | LinkedIn http://www.linkedin.com/company/cksource
Re: Editing with native UI
On Tue, Jul 1, 2014 at 1:19 AM, Ryosuke Niwa rn...@apple.com wrote: On Jun 24, 2014, at 3:44 AM, Robin Berjon ro...@w3.org wrote: Second, it doesn't address the point made below about native UI exposing a likely non-natural subset of the commands I wish to support. That presumes an opt-out mechanism to enable native UI. If we had used opt-in instead, then we wouldn't have this issue. I think that it may happen in both cases. Developer won't know if on platform X there's native UI for all commands that he/she wants to enable. Mobile Safari displays numbered and bulleted lists buttons, but browser Y may support only bold, italic and underline and in such case content created on Safari will not be fully editable on browser Y. That's why I can't imagine using native UI for more than a really simplest use cases (e.g. comments on blog). But if native UI will stay, opt-in mechanism is definitely the way to go. There is a list of problems with the current editing API: - Undo/redo menu doesn't get enabled/disabled in accordance with the app's intrernal undo stack. Yes. It would be great if native undo/redo options were controllable. I'm also hesitating whether cut and paste options should not be controllable. That would give us similar control as we have over drag and drop. BTW. It struck me recently that we're writing here about disabling commands in order to remove them from native UI. But enabling/disabling command is something different than removing (hiding/showing) option from native toolbar or context menu. For example - I may decide that inline styling (i.e. bold, italic) should not be available in my editor. There's no point in having them in the toolbar, so I want to remove them. On the other hand, my app has an internal undo stack, so if it's empty I want to disable undo and redo buttons. I don't want to hide them. I just want to change their state. Similarly, different rules regarding what content is allowed may apply in editable areas within one editor (having one toolbar). This is a very popular scenario in CKEditor (see e.g. how toolbar behaves when moving selection from main editing area to image's caption in [1]). In such case I want to be able to disable some commands without hiding them, because that's less confusing for users. Therefore, I believe that we need two methods - one to control commands' states and one to enable/disable features (meaning - showing/hiding). Also, a feature isn't necessarily the same as command. We may have different set of features that can be enabled and commands which states are controllable. [1] http://cdn.ckeditor.com/4.4.2/standard-all/samples/plugins/image2/image2.html -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] selection across editing host boundaries
On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon ro...@w3.org wrote: On 23/06/2014 20:33 , Johannes Wilm wrote: I filed bugs on this on both Firefox and Chrome in spring 2013. It was briefly fixed in Chrome, but the fix was then retracted and we never heard any more of it. It was also reported in Firefox by someone else in 2011. [1] I also had some contact with Webkit people working in this area who unfortunately didn't find the behavior to be problematic. This is probably the main reason why at least I am wondering if editing maybe just is an area that won't be of enough interest to browser makers to ever fix and that it may therefore just make more sense to just ask them to remove it and do everything in Javascript. But now it seeems this is about to change, which would be really really good. From discussions I've had in the past on this topic, it's not so much that browser-folks don't want to fix this. The problem is more that 1) this is hard, so fixing can often only happen if someone really owns the problem rather than contributing the odd fix, and such a person isn't always available; 2) the current state of contentEditable is such a mess, notably with libraries doing per-UA workarounds, that fixes that make the behaviour globally saner actually break deployed code. This has conspired to make the situation rot. Hopefully we can fix this with the new tack taken here, notably by using contentEditable=cursor as a sanity hook which doesn't have to be backwards compatible with the existing madness. I am happy to see more cases that force us to propose something new, instead of patching rotting contentEditable=true :D. That's all nice and well, but what should the range be in the following cases: A: editableblah non-editablefoo/non-editable| blah/editable B: editableblah [non-editablefoo/non-editable] blah/editable C: editablebl[ah non-editablefoo/non-editable bl]ah/editable D: editableblah non-editablef[oo/non-editable bl]ah/editable E: editableblah non-editable|foo/non-editable blah/editable Or in this: F: ul contenteditable=cursor liblah/li li|blah/li /ul F2: ul contenteditable=cursor liblah/li li|/li /ul or just for kicks, one could make the argument that this is different: G: ul contenteditable=cursor li contenteditable=cursorblah/li li contenteditable=cursor|blah/li /ul ? I think that we can start to solve this in the following manner: • When a deletion event would produce a range crossing an odd number of editing boundaries (either because there's a selection doing so in the sum of its ranges or for instance given backspace in case A above) then its range is empty and corresponds to a collapsed range a the cursor position (this is defined even for selections). • Conversely, when it would cross an even number of editing boundaries, then the range covers them. • Deletion events capture information expressing the direction of the deletion (previous, next, or possibly both in the delete-line case). This makes it possible for script to know how to hand the empty-range case. • Additionally, the deletion event can expose convenient information about the editing boundaries being crossed, their number, their hosts. This means that, assuming backspace, the cases above can be handled as follows: A: empty range, the script can decide whether to select or delete the non-editable content (direction previous). B: a range containing non-editable. Presumably deleted. C: same as B with some extra content on both sides. Presumably deleted. D: empty range, the script can decide what makes most sense. (Stabbing the user in the face sounds good.) E: empty range, the script decides which is best. For F, F2, G, and an awful lot of other cases (dt/dd, td, etc.) I think we should take the minimalist approach: just produce a deletion event indicating its direction but with an empty range. Scripts can decide if they wish to merge elements, delete empty ones, outdent, etc. This is getting complicated enough (and I haven't mentioned other cases such as br, script, hr, td, img, video...) that I wonder if the Deletion event shouldn't have its own spec. I agree about A, B and C. Selection in D in my opinion should not be possible (I'll comment on that later [1]). Selection in E also should not be possible because empty selection can't be made in non-editable element. As for the complexity, I feel that there's an indefinite number of cases (e.g. we can start including styling - hidden elements, block/inline etc.). Since the information about proposed result range is just an information - can't we provide it only in some cases. For example, considering CTRL+backspace in this scenarios: 1. pfoo bar|/p = [bar], direction:previous 2. pfoo/pnon-editable-block/p|bar/p = direction:previous In the second case editor may choose between multiple possible
Re: [editing] Leading with ContentEditable=Minimal
I think that first we need to clarify how we understand some terms/concepts, because I was confused many times and I'm afraid that I also haven't been understood correctly. 1. Separation of basic user intent events and rich command events. Examples: * user intent events - insert character (typing), move caret left, delete a letter, delete a word, insert paragraph break (enter/return), insert line break (shift+enter/return), etc. Additionally there are clipboard, undo and drag and drop events separated already, but they fall into this category. * rich command events - bold, indent, make numbered list, link, enable objects resizing, enable automatic quotes. At some point there were all included in the command events and in my opinion this started the confusion. User intent events are crucial for contentEditable=minimal, when rich command events may be useful for some better internationalization, but are not crucial (if browser does not try to do too much), because they usually are triggered by keystrokes. 2. Commands versus command events. These are separate things again for me - cE=minimal needs events, but does not need commands and entire execCommand/queryCommandState/Value/etc combo. A link command event may be fired when browser thinks that user wants to make a link even if there's no default action bound to that event. 3. Native UI. Again we have UI for basic interaction like the paste option in context menu and UI for rich options like bold or enabling/disabling auto quotes (see [1]). CE=minimal does not need rich options in any form - commands or UI. I'm not sure yet what about basic interaction like copy, cut, paste, spell checking, undo, redo, select all, but they definitely belong to a separate group and may be considered independently of the rich options. Do we agree about these three topics? At least from the separation POV, not necessarily about what cE=minimal needs. [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html On Mon, Jun 16, 2014 at 8:12 PM, 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? -- Piotrek Koszuliński CKEditor JavaScript Lead Developer -- CKSource - http://cksource.com -- Follow CKEditor on: Twitter http://twitter.com/ckeditor | Facebook http://www.facebook.com/ckeditor | Google+ https://plus.google.com/107736718646302128806 | LinkedIn http://www.linkedin.com/company/cksource
Re: [editing] CommandEvent and contentEditable=minimal Explainer
On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent jpar...@google.com wrote: I certainly understand the concern that it would be impossible to properly catch and cancel all events. I'm not concerned only about this. I'm concerned about the fact that currently existing commands and editable-related features does not fit in a simple command APIs. But I think that is somewhat the point - it forces browser vendors to get these parts right. The spec should guide engines' developers, because there's a single spec and many engines. Even if all browser vendors will get these parts right, they may choose different paths. And then, in general, this will be not right and it will be a pain for developers. 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. I don't think that number of events implies that we are building a bad API. Dozen of well defined events is better than three that do too much in an unclear way. Besides that, as an editor author I'm not only interested in preventing default action of features I don't want. I also want to hide them - remove them from browser UI like context menus, menu bar, or other widgets like special toolbar appearing over contenteditable on iOS. This makes the situation which spec has to describe much more complex. That's why I think it's better to focus on basics ( http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0918.html) than on trying to make specification for every feature that was introduced in any engine in any away. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] CommandEvent and contentEditable=minimal Explainer
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] CommandQuery Object and Event
On Fri, Jun 6, 2014 at 6:39 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. You may not need native UI working at all in your app, but that doesn't mean all other developers don't want it at all. Furthermore, enabled-ness of items in desktop browser's edit menu should reflect the current state of the editor; otherwise, it would degrade the user experience. Furthermore, we shouldn't design our API only for existing platforms. We need to make it so that new, completely different paradigm of UIs and devices could be built using new API we design. Another important use case for browsers to know the state of the editor is for accessibility. AT may, for example, want to enumerate the list of commands available on the page for the user. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. Providing default editing behavior may not be desirable for that reason. However, it would be still of connivence to provide some helper functions to do the work automatically when the author opts-in so that he/she doesn't have to write every single editing logic himself/herself. I am sorry for the dramatic tone of this message, but I am honestly shocked by my today's discovery. Namely, I checked what Safari displays in contenteditable's context menu. For those who don't have access to Safari: * Substitutions (set of options like smart copy/paste, smart quotes, smart dashes, smart links, etc. plus show substitutions option displaying a native popup). * Transformations (make upper/lower case, capitalize). * Fonts (two options that do not work (show fonts and show colors) plus bold, italic, etc.). * Paragraph direction (ltr, rtl). So what I saw on a mobile Safari (the floating toolbar) was only a tip of an iceberg. I don't want to say that these options should never be added. I don't also want to say that they should be first standardised, then implemented (though that would be perfect of course) or that they should be now dropped (backward compatibility is a requirement I understand very well). My point is that we would need to take all this into account when thinking about fixing contenteditable=true. It must stop be surprising and unpredictable for developers. That I think should be our goal - to make it predictable and controllable. There are two paths to achieve this goal: 1. Make all what's already implemented controllable, or at least possible to disable. 2. Start from scratch (meaning contenteditable=minimal as an option, not as a concept). When the first option seems to be tempting I still believe it's not the right way. It will force us to think about all the crazy stuff like native toolbars, fonts, transformations, text direction, automatic substitutions, ability to add new options, setting icons, a11y, localisable labels for new options etc. All these things are complicated just by themselves and besides them we still need to fit input or intent events, commands, their states, etc. Even if we'll focus only on making all these controllable (without defining expected behaviour) then we'll have to solve problems like - should a command be executable if I disabled it? No? What if I want to remove that option from native context menu/toolbar but reuse the implementation? That's why I think that the second option is better. Contenteditable=minimal should not only be a concept - we need an option. Option which will allow us, while creating a spec, to forget about legacy features and not care about backward compatibility (which will be left in form of contenteditable=true). In a shorter period we'll be able to come out with a solution to at least part of the current problems and the solution should also be cleaner. Otherwise, I'm afraid that the new spec will end like the old one did. Simultaneously, contenteditable=true will still be usable. In use cases not satisfied by contenteditable=minimal developers will be able to use contenteditable=true. Moreover, there will be a possibility to backport features (like APIs and maybe command events) to contenteditable=true. But the primary goal should be to make contenteditable=minimal useful, not to enrich contenteditable=true. -- Piotrek Koszuliński
Re: [editing] CommandQuery Object and Event
Responding to browser UI is one thing and I totally agree with the need for user intent events. If user shakes iPhone editor should be notified that user wanted to undo. But I does not tie this to commands at this point at all. Events exist to notify app that something is going to happen. The default behaviour of what happens may be hidden behind a command, method or engine internals, but that's a separate topic. As for CommandQuery Event, I commented it in [2] and indirectly in my previous email. In my opinion it tries to hide symptoms of contenteditable's sickness rather than cure it. Existing commands break my app or are useless for it, so let me allow to disable them. 1. Most editors will disable as much of them as possible (I wonder what about paste/cut/copy) to hide native UI which may conflict with custom UI (e.g. overlap it) or simply to block undesired, unclear feature. 2. If developer is forced to leave any of commands enabled (e.g. to not lose clipboard support), he/she risks that native UI will be displayed and will break his app. 3. If developer wants to enable some option (e.g. smart quotes) he/she risks that native UI will break his app or that user will be able to disable such option when should not be able to do that. 4. Some of these issues may be solved by special commands blocking native UI without disabling specific commands. 5. In many scenarios native UI is useless, because it cannot be extended and redesigned (new buttons, new types of UI elements), so it only satisfies small subset of use cases. 6. Even if e.g. mobile Safari displays all buttons necessary for developer's use case, if any other browser does not do that, then developer has to override everything anyway. Without interoperability 7. A11y is not a reason to make browser handle all the UI. If ARIA's roles are not sufficient or some API is missing, then they should be added, not native UI extended. As I said, most of (advanced) editors will need to hide native UI, so if providing a11y using HTML and JavaScript is not possible on some platform (mobile?), then this problem will need to be solved anyway. 8. What if some command should have configurable behaviour? For example quote characters used by smart quotes feature might be configurable (language dependent?). What API allows this? Assuming that we've got two commands - disableSmartQuotes and enableSmartQuotes, which of them I have to disable to get rid of them from the UI? Sure there's a solution for all that, but extending commands APIs indefinitely will lead to even bigger mess than now. And having bazillion options in tight high-level API, without providing any primitives is a bad design choice. None of these points is a deal breaker when considered separately. But all of them (plus many we don't yet see) combined together makes the situation look terrible. Commands, related APIs, native UI are useless or problematic for editors (meaning real editors, not these adding contenteditable=true to a div) and still will be useless. Commands API might look extensible, because it uses strings as commands identifiers, but that's a very high-level native API, so if any feature is not included (like setting characters used by smart quotes), everything has to be implemented in JS from scratch. Native UI is inextensible and uncontrollable and still will be (command events cover only execution logic). Someone said that contenteditable=true tries to be an entire WYSIWYG editor (a poor one actually) at once and that that's bad. I couldn't agree more. Is adding new options to tame the contenteditable=true going to fix this? No. It will make the situation slightly more acceptable, but contenteditable=true is still terminally ill, because it still pretends to be an editor. [2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0826.html On Mon, Jun 9, 2014 at 10:28 PM, Ben Peters ben.pet...@microsoft.com wrote: Is it just browser UI that leads you to want to start over? The goal of CommandEvents is to allow sites/frameworks to work with browser UI, whether toolbars like Safari or gestures or speech or accessibility tools or whatever else in the future. I understand that browser UI can be a problem today since you can't respond to it, but once you have CommandEvents you'll be able to treat a bold button just like control+b by listening for a bold event. We are also working on coming up with a way (currently called CommandQuery Event [1]) to enable browsers to determine which commands are available, which would help browser UI display correctly and would also help accessibility tools tell users what they can do. Simply removing browser toolbars doesn't mean there are no other ways to interact with a page that users expect to work- take shake-to-undo in iOS for example. [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0791.html -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] CommandQuery Object and Event
On Wed, Jun 4, 2014 at 8:31 PM, Ben Peters ben.pet...@microsoft.com wrote: There has been some conversation about browser UI for Commands with ContentEdtiable=minimal. Some people seem to believe that UI should not be displayed because it may not be relevant. I think that it was me talking about mobile Safari displaying its native toolbar over contenteditable field. But this is not a solution I had in mind. Few weeks ago we started discussing about contentEditable=minimal. It was a great relief for me, because I consider contentEditable=true being already ideologically dead for a long time and I see no point in resurrecting it. There was a common agreement that contentEditable=true is wrong because it tries to be an entire application rather than just a base, a necessary architecture for frameworks and applications built in JavaScript on top of it. Why I mention this now? Because I think that two wrong assumptions have been made. 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. In a simple case, when I want my FontName command to apply span class=font[[Name]] to selected text instead of the default... font family=[[Name]], I need to: a) Totally override the way how command is applied. I need to remove other spans with classes starting with font class, and wrap content with my new span. b) Totally override command's state and value handling. It has to discover correct span tags (only these with proper classes), read the font family name from class name and handle it accordingly. Additionally, I don't have to do that on every selectionchange event - I care only about selectionchange events fired when an element in which selection starts changes. This is a big performance improvement. So what's left from a native command? Nothing. I can't even reuse algorithm applying inline elements to selection. That actually would be useful, but such algorithm also needs to be customisable, so it's better if it's implemented in JavaScript. TL;DR 1. Let's drop execCommand and queryCommandState. They have no real value for developers and clearly conflict with cE=minimal. JavaScript frameworks will be created which will allow implementing totally custom and customisable commands. 2. Expose necessary APIs and architecture so all necessary commands can be implemented in JavaScript. Currently I can think only about copy, cut, paste which someone may want to disabled in some conditions. Maybe also undo and redo, because I can imagine that advanced editor's logic may be too complex to use native undo manager (but maybe I'm wrong - I haven't read undo manager's spec). Basically, it would be nice if we were able to control state of commands that should appear in browser menu bar or context menu, but that does not have to be based on currently existing commands API. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] CommandQuery Object and Event
On Fri, Jun 6, 2014 at 1:29 PM, Piotr Koszuliński p.koszulin...@cksource.com wrote: TL;DR 1. Let's drop execCommand and queryCommandState. They have no real value for developers and clearly conflict with cE=minimal. JavaScript frameworks will be created which will allow implementing totally custom and customisable commands. 2. Expose necessary APIs and architecture so all necessary commands can be implemented in JavaScript. Currently I can think only about copy, cut, paste which someone may want to disabled in some conditions. Maybe also undo and redo, because I can imagine that advanced editor's logic may be too complex to use native undo manager (but maybe I'm wrong - I haven't read undo manager's spec). Basically, it would be nice if we were able to control state of commands that should appear in browser menu bar or context menu, but that does not have to be based on currently existing commands API. To give an example. 1. User presses down key. 2. A command event with commandType == 'moveSelectionDown' is fired. 3 a. If app does not execute preventDefault(), then the default action is executed by browser. The default action means executing e.g. selection.move( DIRECTION_DOWN ) or any other more complex code but using exposed APIs. 3 b. If app executes preventDefault(), then it can call selection.move( DIRECTION_DOWN ) and the result should be identical. Or it can preventDefault() and e.g. execute selection.move( DIRECTION_END_OF_DOCUMENT ) The idea is to expose necessary functions in form of selection/element/whatever methods and use these methods. The same may be achieved by execCommand() and related methods, but: a) backward compatibility, b) not standardised, c) too high-level in some cases, d) not the best API design ever, e) problem with extensibility. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: contentEditable=minimal
On Tue, May 27, 2014 at 11:01 AM, Robin Berjon ro...@w3.org wrote: On 25/05/2014 20:40 , Piotr Koszuliński wrote: Making some things unselectable might also be useful. IE has unselectable, there's also -moz-user-select and friends. But this is small fries for later I'd reckon. There are also nested non-editable islands. We built very important feature based on them - http://ckeditor.com/demo#widgets. Currently we block their selection by preventing mousedown and we handle left/right arrows. But cancelling selectionchange would allow us to control more cases in a cleaner way. I'd be curious to know what your take is on the best way to expose this. IE has an unselectable attribute, whereas Gecko and WebKit have a CSS property. In this thread we've been talking about using cancellable events for this (or if not cancellable, ones in which the selection can be modified on the fly). On instinct I would tend to think that this not a great usage of CSS, it's much more tied to behaviour at a lower level. But it sort of is one of those borderline things (as many of the properties that initially came from the CSS UI module). The scriptable option that we're consider is good in that it enables arbitrary cases, but it could be interesting to support a number of cases out of the box with a simpler (for developers) approach. Let's imagine the following DOM: div contenteditable=minimal pblah blah blah/p div class=widget unselectable.../div pblah blah blah/p /div If the cursor is at the beginning of the first p, you hold Shift, and click at the end of the second p, we could imagine that you'd get a Selection with two Ranges (one for each p) and not containing the unselectable widget. I *think* that's the most desirable default behaviour, and it's also one that can be pretty painful to control through script. In that sense an unselectable attribute would make sense. (I reckon that setting the widget to be cE=false would have the same effect, but it is nevertheless an orthogonal property.) WDYT? My previous email might be confusing because I mentioned only that CKEditor handles mousedown event. Actually, this is a tip of an iceberg :). I think that it may be an interesting case, because we were forced to overwrite most of browser behaviours when implementing the widget system. Also, this case is so complex that it's easier to start from what we experienced rather than saying that if X and Y will be possible, then our needs will be satisfied. I hope you forgive me this laziness :) The main requirements for the widget system were: 1. User must not be able to modify a non-editable part of widget. 2. Widget must be selectable as a whole (like an image). 3. Widget may contain editable fragments (nested editables). 4. There are block and inline widgets (surprisingly important requirement). 5. Widget may contain other widgets in its nested editables. So widgets may be nested multiple times. 6. Widget must be selectable by click, arrow keys, etc. It also has to be deletable by backspace/delete and copyable by CTRL+C. This is a structure that we used: div contenteditable=true !-- editor's main editable -- pfoo/p div contenteditable=false !-- widget wrapper -- p contenteditable=truenested editable/p pnon-editable content/p div contenteditable=true panother nested editable/p /div /div pfoo2 span contenteditable=falseinline widget/span/p /div Why did we choose contenteditable=false? At the beginning it was simply intuitive. We don't fully control the interaction methods (mouse, keyboard, selection), so let browser do that. Then we overwrote most of the interaction methods so currently the attribute is not so crucial. However, there's one aspect of interaction which we cannot control and I'm not sure if we'll ever be able - dynamically changing selection (its visual and logical aspect) around block widgets, their nested editables and a special case that complicates all this - blocks may be floated. Let's try to imagine how we could handle selection without using contenteditable=false. pfoo/p div class=widgetwidget/div pbar/p TC1: User clicks main editable's margin, on the side of the block widget. If he clicks closer to the top of the widget, we would like to place caret at the end of preceding editable block (foo^), and when closer to bottom, then in the following block (^bar). Without checking dimensions, that would not be doable, because browser would suggest a selection inside divwidget/div. On the other hand, we could consider always selecting entire widget if selection was proposed inside it. This seems to be a good option, especially taking into account that we may have multiple block widgets one after another, and then you cannot place selection between them anyway. TC2: Another aspect is selection normalisation. When we make a decision that entire block widget should be selected we want to be able to anchor the selection
Re: [editing] CommandEvent and contentEditable=minimal Explainer
But what is the default behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may demand from browser vendors that they fix their contentEditable=true
implementations and I don't think that anyone wants that. Why not forget
about contentEditable=true, make it deprecated and create specification
only for algorithms needed by contentEditable=minimal and all required
command events?
On Wed, May 28, 2014 at 10:39 PM, Ben Peters ben.pet...@microsoft.comwrote:
Great idea! If Intention Events (Clipboard, Selection, Command) cover
all of the editing operations that a site would want to handle themselves,
we don’t need CE Min as a feature, only a concept that can achieved with
preventDefault().
*From:* Julie Parent [mailto:jpar...@gmail.com]
*Sent:* Tuesday, May 27, 2014 4:40 PM
*To:* Ben Peters
*Cc:* public-webapps@w3.org
*Subject:* Re: [editing] CommandEvent and contentEditable=minimal
Explainer
The discussion of which minimal default handling to include with
contenteditable=minimal makes me wonder if contentEditable=minimal is
necessary at all. It quickly becomes a can of worms of *which* default
handling should be included, and it seems likely to not satisfy every use
case no matter which decisions are made. However, minimal is proposed as
a building block because currently, disabling all default functionality of
contentEditable=true is difficult/impossible. But with CommandEvents,
shouldn't contentEditable=minimal be equivalent to:
// Let editRegion be div contentEditable id='editRegion'
var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
evt.preventDefault();
}
No default actions would be taken, but selection events would still fire
and be handled. There would be no ambiguity. If implementing
contentEditable=minimal on top of CommandEvents could just be a few lines
of code, why complicate things by spec'ing another property?
Then, if someone wants a region that just does basic text input, then they
simply allow it:
function handleCommand(evt){
switch (evt.commandType){
case 'insertText':
// Let the browser do text insertion
break;
default:
// Prevent all other magic
evt.preventDefault();
}
This hedges on the fact that CommandEvents would capture ALL the cases
that contentEditable currently handles, and that the event would fire
BEFORE the dom is modified, and that calling preventDefault would cancel
the event, but isn't that a goal of this design anyway?
Julie
-- Forwarded message --
From: *Ben Peters* ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.org public-webapps@w3.org
I have completed a first-draft explainer document [1], taking the generous
feedback of many of you into account. There are 6 open issues on the
document currently, and I'm sure there are others that I have missed. It
would be great to know if this is heading in in the right direction.
My vision is to use this a non-normative Explainer, and create 2 normative
specs to go with it. The specs for contentEditable=minimal and CommandEvent
should have first-drafts next week.
Thanks!
Ben
[1] http://benjamp.github.io/commands-explainer.htm
--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
Re: contentEditable=minimal
On Tue, May 27, 2014 at 1:48 AM, Ben Peters ben.pet...@microsoft.comwrote: 5. There should be no native toolbars in cE=minimal (and other native UI interfering) like the one Safari opens on iOS if you have non-empty selection. I haven't yet checked exactly what's in the iOS toolbar, but generally I don't think we should dictate UI. Clearly on mobile we don't want to forbid browsers to bring up the virutal keyboard, which is a form of native UI. And the spellcheck UI that safari displays also doesn't seem bad if spellchecking is enabled. And UI for cut/copy/past that android renders seems good to render *somewhere* when there's selection. On iOS the contextual toolbar not only contains copy/cut options which are of course ok, but it also contains bold, italic and lists buttons. That's unacceptable and I assume this kind of native UI will not be implemented for cE=minimal. The goal of Command Event is to make this a non-issue. If sites respond to bold/italic/list commands they can handle this UI just fine. Are you concerned that a site may not use bold so the button would have no effect? Yes, it should be possible to disable whichever feature you don't need. In some cases you don't need lists (because e.g. you're editing a text that will become a content of a paragraph). And in some cases you don't want bold/italic because your use case requires only structured HTML. So being able to handle such commands is a one thing. But first of all there should be no assumption that a user needs these buttons, because a browser just don't know about that. If I think that users need toolbar, I can render a custom one. There's one more assumption that makes editing on mobile devices (especially low-res devices) very hard. It's that if user focuses editable, then he/she wants to type, so native keyboard should pop out. Very often it's true, but in some cases user may want to select some text and using toolbar apply styles or lists, etc. And when the keyboard is visible there's very little space to do that. If there was any API to control whether keyboard is visible, then we could achieve much better UX. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: contentEditable=minimal
At the beginning I've been sceptical regarding cE=minimal not doing any DOM modification at all. The ideal situation which I imagined was that you can easily use cE=minimal in basic case like a single paragraph of text with a bold and italic buttons (which you need to implement by yourself). This is a pretty common use case if you have structured content and you allow editing only specific parts of it, but want to provide basic styling support. In my imagined situation you would only need to handle style application/removing and filter pasted/dropped content. All this would be less than 1k LOC. And the code size matters. CKEditor's implementation of inserting text and HTML into selection is 2-3kLOC (hard to estimate because of code reusing). Few backspaces/delete cases which we handle take around 500LOC which then use next 2kLOC. I'm pretty sure that full implementation of HTML and text insertion, backspace and delete, caret movements plus all the necessary bindings will not fit in 10kLOC (it's a jQ size) unless browsers will help. And this may affect cE=minimal adoption (or quality of implementations) because many developers don't accept so big libraries (especially for mobiles) and well... there's cE=true still - why not use it? On the other hand, I must agree that even most basic handling for content deleting and insertion (which shares a lot with deleting) leads us to immediate problems. Even in simplest case pfo[obbar/bb]om/p we need to remove the b element, because no one expects that only text nodes will be deleted. So when we started deleting b, then what about cells selection in tables and so on. Let's leave this. No DOM modifications made by browser. So my two proposals are: 1. Events should be made as useful for developers as possible. Delete and caret movements events should contain information about proposed target selection, and text input about the character/word. I'm not sure though if algorithm for finding position after delete and caret movements is simple. Having this is actually half the way to fully handling these actions. There's inline, inline-block, block contents, empty elements, tables, non-editable content (cE=false), nested editables, boundaries of inline elements, etc. Can the spec contain all this? BTW. This reminded me about range walker, which is an extremely useful tool, but I haven't seen it in any specification. 2. I second the idea about example, basic implementation of text insertion, caret movements and backspace/delete. It does not have to really work, because it would require cE=minimal and command events to be ready or at least mocked. But the sample code will be very helpful. It will help some of us to imagine how all of this will function (e.g. I'm not sure I understand what and how I will have to handle about composition). And it will be a nice addition to spec in the future. On Fri, May 23, 2014 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: ## What should cE=minimal handle? Awesome feedback! ## What should cE=minimal handle? 1. Selection and caret drawing. 2. Selection API Agreed on both! 3. Typing characters. 4. Delete, backspace. I think these are the hard ones. More below. 5. Navigating with arrow keys, selection with SHIFT, CTRL modifier. Agreed. Developers have to deal with selection moving around anyway since they should handle touch screens. But we should definitely fire events whenever cursor or selection is moved and enable the page to either cancel the movement, or adjust the location before it takes effect. 6. Spell check. When you want a native spell check you cannot override context menu. When you want custom context menu, you need custom spell check (which is extremely hard). And context menu is very important for many users because they used to look there for contextual options, so most editors override it. Therefore, a way control at least one of them (I guess it won't be a context menu, though that would be awesome) will be great. There's already a contextmenu feature in HTML, though I don't know if any other browser than Firefox implements it. And the spec has seen so much changes that I don't know how closely Firefox conforms to the spec. Anyhow, I think the ability to extend/replace the existing context menu is the way to go if that's what people need. Adding spellchecking primitivies, and forcing webpages to implement their own spellcheck, seems like the wrong way to go about enabling pages to do their own context menus. ## What should not be handled by cE=minimal? 1. Bold, italic, list, link, blockquote and other commands creating content. 2. Enter key support. 3. Tables and images resizing. 4. Another thing that browser engines cannot do is trying to be... too smart? Strongly agree with all of these. 5. There should be no native toolbars in cE=minimal (and other
Re: contentEditable=minimal
6. Spell check. When you want a native spell check you cannot override
context menu. When you want custom context menu, you need custom spell
check
(which is extremely hard). And context menu is very important for many
users
because they used to look there for contextual options, so most editors
override it. Therefore, a way control at least one of them (I guess it
won't
be a context menu, though that would be awesome) will be great.
There's already a contextmenu feature in HTML, though I don't know if
any other browser than Firefox implements it. And the spec has seen so
much changes that I don't know how closely Firefox conforms to the
spec. Anyhow, I think the ability to extend/replace the existing
context menu is the way to go if that's what people need.
Do you mean:
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
?
I didn't know about it. It doesn't seem to work on any browser yet, but it
should be able to solve our problems. I hope it will be implemented soon.
5. There should be no native toolbars in cE=minimal (and other native UI
interfering) like the one Safari opens on iOS if you have non-empty
selection.
I haven't yet checked exactly what's in the iOS toolbar, but generally
I don't think we should dictate UI. Clearly on mobile we don't want to
forbid browsers to bring up the virutal keyboard, which is a form of
native UI. And the spellcheck UI that safari displays also doesn't
seem bad if spellchecking is enabled.
And UI for cut/copy/past that android renders seems good to render
*somewhere* when there's selection.
On iOS the contextual toolbar not only contains copy/cut options which are
of course ok, but it also contains bold, italic and lists buttons. That's
unacceptable and I assume this kind of native UI will not be implemented
for cE=minimal.
Another thing that we should look at is the ability to style ranges
rather than just elements. In Gecko we have an internal feature that
allows us to style DOMRanges. This allows us to render a red dotted
line under misspelled words and black line under composition
characters. And do that without worrying about managing a lot of extra
elements in the DOM.
Right now pages are forced to sprinkle elements all over the DOM in
order to do the same thing, which then makes editing that DOM more
complex. It would be awesome to find ways to enable styling ranges
which would allow them to keep a simpler DOM.
Wow! Such feature would be awesome. This reminds me about an idea mentioned
in https://medium.com/medium-eng/122d8a40e480 that cE could be
reimplemented with shadow DOM. It would be extremely powerful if caret and
selection and styled ranges were real, accessible elements.
Which brings me to think: when we discussed this at the Summit, there was
some agreement (between all four of us :) that it was a good idea to
support multi-range selections. These are useful not just for tables, but
also for bidi. The reason for the latter is that when selecting a line with
multiple embedded directions (using a mouse), you want to have the visual
selection be an unbroken line (as opposed to the crazy jumping around you
get if you follow logical order).
It's definitely useful, though it does come with its problems. The
question that opens up for me is: do we want to support multi-caret editing
as well? The data model certainly supports it, but we have to account for
it early if it's an option.
At any rate, multi-range selections would be much easier to handle if we
had something like Selection.forEachRange(function (r) {...}).
Uh... multi-range selections. I find myself and my colleagues ignoring
them. They add so much complexity to already complex tasks that we simply
handle first range and ignore other. And I don't remember complains about
that. They make some sense when selecting table columns but this is not a
necessary feature and may be also handled by an editor by fake selection.
Multiple carets are useful in code editors, but not a single text editor's
end user know about them (and I believe they were removed from Firefox). I
don't know the bidi case though. But if it could be handled without
multi-range selections I would gladly forget about them.
--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
Re: contentEditable=minimal
* Cursor navigation, including reacting to touch events, mouse clicks and keyboard events. Cursor navigation would likely also fire cancelable events. Yes. Cursor navigation can be represented through selections (that may be collapsed). In general it is important that selection changes can be cancelled so that developers can carry out selection validation before accepting it. Making some things unselectable might also be useful. IE has unselectable, there's also -moz-user-select and friends. But this is small fries for later I'd reckon. There are also nested non-editable islands. We built very important feature based on them - http://ckeditor.com/demo#widgets. Currently we block their selection by preventing mousedown and we handle left/right arrows. But cancelling selectionchange would allow us to control more cases in a cleaner way. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Moreover, the clipboard is systemwide, when selection exists per document. So in my opinion window is a better choice. On Fri, May 23, 2014 at 3:21 PM, James Greene james.m.gre...@gmail.comwrote: I wouldn't put this on window though; why not put it on Selection? This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: CommandEvent for user intentions
I wrote a longer reply in the contentEditable=minimal thread, which touches some aspects of command events. Actually, before some stable point about cE=minimal is reached I feel that it may be hard to design command events in a way that both are interoperable. Command events should be an extension to cE=minimal making it possible to create advanced solutions on top of it. Therefore, it may be beneficial to discuss both of them in one thread. But for now, here are some additional thoughts which I haven't included in the email about cE=minimal. 1. It should be possible to modify selection and DOM in a command event listener, but leave the action to the browser. Browser should perform the action on the updated selection and DOM. Example - I want to transform * to a list when user types additional character. So I would listen to keyboard event, check if two previous characters are * , replace them with a list and place selection inside li. But I want browser to perform character insertion so I don't have to handle undo manager, scrolling to show caret, etc. There are of course other ways to achieve the same, but this seems to be the cleanest. 2. It's not totally necessary, but it would be nice if command event would also carry an information about its future result. For example command fired for up-arrow key could carry a range with the proposed position of caret. So if I don't agree with browser implementation, because for example it enters a non-editable region, I can check that and handle this specific case by myself. Since there's no easy JavaScript solution for handling up/down arrow keys such information would allow us to focus only on these specific behaviours we don't like. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: contentEditable=minimal
Great news and a great idea. I totally second a concept of making contenteditable simpler and a lot more controllable for us, editors developers. Even if it would be possible to make cE=true interoperable, there are cases which depend on editor's logic. For example, in CKEditor Bold command may be totally blocked depending on content filter settings (you should not be able to create disallowed content). Similarly, enter, backspace/delete, end/home, undoredo, arrow keys, most of CTRL+ keystrokes, context menu, click-select - we already control them totally or at least in specific cases. And even if related features would become reliably stable, many times their behaviour should depend on editor's logic, configuration, and a use case in which editor is used. That's why a standard and reliable way to intercept them will be very helpful. Moreover, I understand very well how hard and time consuming maintaining cE implementation is. And currently we have 4 implementations - one in every browser engine. Then editors developers override significant amount of that work. This doesn't make sense. It would be beneficial for everyone if browser vendors could focus on the necessary minimum and editors developers on creating an editing framework and specific solutions on top of that. The frameworks would be something like jQuery for editable. They would simplify most common tasks, like applying Bold/Italic/etc styles, inserting HTML into selection, filtering, supporting enter key, etc. All of these operations are very complex and require rare knowledge about cE, selection, ranges and deep understanding of DOM. I was trying to imagine what cE=minimal would be then. CE=true pretends to be an entire WYSIWYG, from which you need to subtract the things which you don't like. CE=minimal could be the opposite - a textarea-like field. You would add your features to it rather than subtract from it. What's more, for some really basic use cases, like Twitter's compose tweet box, it would be a sufficient base without much additional code. ## What should cE=minimal handle? 1. Selection and caret drawing. 2. Selection API - I know that this is a separate topic, but in order to make building features on top of cE=minimal acceptably hard (and not extremely hard), the selection must be improved. I.e. selection in empty inline elements, selection in empty blocks, selection of non-editable (cE=false) content and nested editables, bogus brs, selection in tables, selection in multiple frames, etc. All those things are broken now. 3. Typing characters. It works in textarea and I think it should work out of the box in cE=minimal. Otherwise, cE=minimal will be useless for simple cases (mentioned Twitter), because you'll always need a pretty complex library to handle text input. Additionally, I don't remember any problem with typing characters, so this seems to work well already in cE=true. There's also the IME which scares me, but I don't have any experience with it. 4. Delete, backspace. Here I've got more doubts, because it's now broken in some engines (merging blocks, deleting inline elements, possibility to leave paragraph, etc.). But without native support for them cE=minimal requires JS implementation of them, and taking CTRL modifier into consideration, the implementation becomes big. So I think that delete and backspace should also work out of the box, but should implement the simplest possible algorithm, sufficient to work with paragraphs of text (Twitter case again). But their behaviour in lists, tables may be simplified, so the algorithm is generic and may not be good in terms of UX. That would be customised by editors that need tables and lists and other fancy features. Note: typing on a non-empty selection may trigger delete event + type event afterwards, so customising delete will customise typing. 5. Navigating with arrow keys, selection with SHIFT, CTRL modifier. Again, works in textarea, should work in cE=minimal. Additionally, implementing up/down keys in JavaScript seems to be extremely hard at the moment. 6. Spell check. When you want a native spell check you cannot override context menu. When you want custom context menu, you need custom spell check (which is extremely hard). And context menu is very important for many users because they used to look there for contextual options, so most editors override it. Therefore, a way control at least one of them (I guess it won't be a context menu, though that would be awesome) will be great. ## What should not be handled by cE=minimal? 1. Bold, italic, list, link, blockquote and other commands creating content. All of them are not crucial for simple cE=minimal use cases. Additionally, it's controversial whether b or strong, em or i, there are many ways how lists and blockquotes can be created out of selected contents, etc. You end up rewriting all of them if you need them in your editor. Therefore, I think it makes sense to not waste time trying to standardise them and then
