This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Bug 14554 describes a mechanism for plaintext editing using the contentEditable attribute, but has too narrow a focus. Elements that are contentEditable should have the flexibility to control what child elements are allowed or not allowed. This would allow for a plaintext editor, and much more. Here are a few examples. 1. Create a permanent ordered list that always has at least one list item: <ol contentEditable="true" accept="li" destroy="false"> <li destroy="false">Edit list item.</li> </ol> 2. Create a heading that can be changed, but not removed: <h1 contentEditable="true" accept="b i" destroy="false">Edit heading.</h1> 3. Create a plaintext editor: <div contentEditable="true" accept="p" destroy="false"> </div> 4. Create a custom editor that cannot include tables, images, or links: <div contentEditable="true" reject="table img a" destroy="false"> </div> 5. Create a table that can be edited and removed: <table contentEditable="true" accept="thead th tr tbody td tfoot"> </table> See also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14554 Implement the first item in a cross-browser fashion required a fair amount of effort to handle bugs and browser inconsistencies (see: https://github.com/DaveJarvis/listeditor/tree/master/source). Underneath the hood of contentEdtiable, various browser vendors will provide various interpretations of the HTML specification regarding contentEdtiable. By allowing Web App developers the ability to choose what child elements are permitted, it might help to reign in the inconsistencies.
This feels a lot like mutation events. It eliminates the issue of synchronous event dispatching but still has the issue of forcing UAs to support not inserting or removing arbitrary set of elements. For starters, there are many behaviors to be specified for each and every execCommand as to what exactly happens when insertion or removal of a certain element is not allowed. e.g. What happens if the author forbids to insert div, br, or p and the user pressed enter? What if one is permitted but the other is forbidden? More importantly, what should happen when a selection contains an element that cannot be removed. Should the surrounding context except the element be removed?
I think a simpler solution is to simply fire synchronous events for things like pasting or typing text, and when various commands are executed. These events should expose what content is about to be inserted and should allow modifying it such that it can enforce constraints. I *don't* think we need to enable restricting which elements can be inserted through the DOM directly. Having the .appendChild etc methods work special seems like a source of a lot of complexity. I think most of this already exists though. But I haven't followed the spec in detail so it's quite possible that pieces are missing. Something that might be worth doing though is enabling a plain-text mode where all insertions are limited to plain text. This could enable more powerful plaintext editors.
(In reply to Jonas Sicking from comment #2) > I think a simpler solution is to simply fire synchronous events for things > like pasting or typing text, and when various commands are executed. This is just the beforeinput event that's already provisionally specced, right? https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#methods-to-query-and-execute-commands Note that pasting and typing are defined to call execCommand(), so they'll fire beforeinput/input events: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements This doesn't practically enable things like "don't allow element X," but I don't know if the use-cases are strong enough to justify further complexity. destroy="false" might be worth having (probably not with that name), although I'd like to see some stronger use-cases. > Something that might be worth doing though is enabling a plain-text mode > where all insertions are limited to plain text. This could enable more > powerful plaintext editors. Bug 14554.
> I'd like to see some stronger use-cases. Currently, edit-in-place functionality requires substantial amount of JavaScript (see: http://www.appelsiini.net/projects/jeditable/default.html). Allowing users to edit the content directly on the page (contenteditable's purpose) is far less jarring of a user experience than clicking to reveal a text input field. If users can delete contenteditable elements, then there is no way to ensure that users can always update the value (without additional JavaScript). In other words, once a contenteditable element is removed from the page users can no longer make edits. There are innumerable examples of where this would be useful: https://www.google.ca/search?num=100&q=%22edit-in-place%22|%22inline+editor%22 The example at http://getbarley.com/ is of particular relevance. The title cannot be deleted, yet the content body can be completely erased. Once the body is fully ereased, it is impossible to add body text (at least in Firefox). Similar to the heading, the side content ("Jules Verne") can be erased, but retains editability. Were there a simple way to express that the contenteditable element cannot ever be removed it would make for a consistent user experience.