- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Tue, 09 Oct 2007 21:29:01 +0300
- To: public-html <public-html@w3.org>
Hello! I have reviewed section 5.2. "The contenteditable attribute" [1]. Here are my comments. 1. In the fourth paragraph of section 5.2. there's an error: "Otherwise, either the HTML element has a contenteditable attribute set to the false state, or its nearest ancestor with the contenteditable attribute set is not editable, or it has no ancestor with the contenteditable attribute set and the Document itself has designMode disabled, *and the element is thus not editable*." I think there's something missing "and the element is ... thus not editable". Or maybe that should be only "then the element is not editable". I don't know for sure what was the initial intent. 2. In the fifth paragraph of the same section, the "true" and "false" values only have the left quote, without the right quote mark. 3. In section 5.2.1. "User editing actions" [2]: The "move the caret" and "change the selection" action definitions mention the "mouseydown" event. That should actually be the "mousedown" event. 4. In the same section 5.2.1, the last paragraph: the Enter key is marked-up with two <kbd> nested tags - should only be one <kbd>. 5. In section 5.2.2. "Making entire documents editable" [3], the second paragraph, first phrase: "The designMode DOM attribute on the Document object *takes takes* two values, "on" and "off". " Eliminate the duplication: "takes takes". 6. How does a script determine the exact caret position? By "exact" I mean: in which element node, at which character position within the element is it? I would recommend defining methods which allow authors to find the current caret position. editingHost.caretNode() returns the node where the caret is. editingHost.caretOffset() returns the character index where the caret is located within the node (the index starts from 0). The caretOffset() method could be provided for input fields and text areas as well. I know this has been already requested, from the issues list [4]. Personally, I don't think the ideal solution is something overly complex - specifically the spec should not cater to "multiple carets". For now, people generally only use one caret. Also, I certainly dislike the current selectionStart/selectionEnd solutions for finding the caret position. The reason is simple: they are just unreliable solutions within the limits of today's APIs. "We cannot get the caret position, but we have the selection, and I can use it to get the caret position in IE and Firefox - that is enough for me." I know as well that the specification explicitly does not define how to determine the caret position, as mentioned in the text selection API [9]. 7. There's absolutely no mention about cut/copy/paste. The WYSIWYG editing capability is one of the most important use-cases for cut/copy/paste-related APIs in the "Drag and Drop" section [5]. Section 5.2 should detail a bit how it relates to the "copy and paste" section [6] of the DND API. 8. There's no mention of how editable content behaves in regards to context menus. Can we have a context menu associated with an editing host? How do we check on which node the user right-clicked within the editing host? This is needed for context-aware menus. Can we use the contextmenu attribute on elements within an editing host? When the user right-clicks within an editing host, does the "contextmenu" event fire and bubbles-up on the specific node within the editing host? If yes, then the authors can create contextmenus with an event listener on the editing host, which checks where the event started. Thus, creating menu items as needed. 9. The spec does not define what happens to the editing hosts and child nodes, with regards to event listeners and scripts. Can child nodes have event listeners? designMode is defined such that child nodes, nor the document itself, can have any event listeners, nor any scripts running, Also, it's generally undefined what happens with CSS :hover, :focus, :checked, and other "state-aware" pseudo-classes. 10. Here's a scenario: a) One loads a complex Web application; b) One enables designMode on the entire document; c) One does many changes, to fields, to various data, which would normally have event handlers, which would do various things, including, but not limited to, retrieving data from the server, or disallowing certain input values, etc. d) One disables designMode. What happens now? The user played like "God" and altered the state of the entire application, creating, possibly, even security-related issues. The application is not notified that designMode will be enabled/disabled. Will the scripts continue to run in the application? Or all scripts are forever stopped, even after disabling designMode? Will event listeners still be valid for the nodes which remained in the document, without being removed during editing? Based on some concerns raised by this scenario, I suggest defining that the "designMode" event fires at the document before it's enabled, and after it's disabled, such that scripts can "know" this has happend. The event must not be cancelable. Similarly, a "contenteditable" event (bubble true, cancel false) should fire at the element node for which contenteditable is enabled/disabled. Use case: a banking site, a Web mail application, or some other Web application where security is critical, could have a script which can disallow such (malicious) user behavior, or it can check the consequences after designMode is disabled. Obviously, determined malicious users can, and will, bypass such security measures. Yet, any security layer, is welcome, in my opinion. 11. Another scenario: a) The user loads a page with a script which sets contenteditable to true for one node. b) Then the running function inserts a <script> into the node. c) Then contenteditable is set to false. Does the <script> ever execute? If yes, when? What if the <script> has a src attribute, thus trying to load an external script? What about <style tags? and <link rel=stylesheet>? Currently, it looks like Gecko allows :hover in designMode. It also allows some event listeners to work in designMode - for example: click, mouseup, mousedown, mouseover, mouseout, and probably even more. Obviously, since it allows event handlers to run, it allows scripts in the document to run. What Gecko doesn't allow is navigating to other pages from the event handler, nor from the default actions (e.g. form submit, or click on anchors to load another page). I haven't yet tested, but I wouldn't be surprised to see Gecko load the scripts and the styles given in the scenario from point 11. I also reviewed section 5.5. "The command APIs" [7], which is directly related to WYSIWYG editing. I have the following comments to make: (Is this section TBW (to be written) or a WIP (work in progress)? I did not see any of these markers. I am asking because it lacks some things. Let me go into details...) 1. My internal WYSIWYG editor (Awebitor) is not full-fledged like others, yet it makes use of commands which are not in the spec. a) The "createlink" command which encloses the selection within an anchor with the href attribute having the given value. Use case: for "create a link" buttons within the editor UI. Otherwise, the author has to use the 'inserthtml' command with some manually generated code, prone to errors. b) The "unlink" command which removes all the links in the selection. Use case: similar to the above. This is more desirable than writing our own code which parses the DOM, or parses the source code as a string. c) The "removeformat" command which removes all the formating of a selection. This actually removes style attributes, bold, italics, underline, align left/center/right/justify and some more. Proper testing needs to be done to determine the precise behavior. I can do it, if this command is to be added to the spec. The command is quite useful in many cases when editing a document. It would be quite much work, prone to errors, for authors to write their own implementations. d) The "bold", "italic", "underline", and "strikethrough" commands are also left undefined. These, I believe, have a high usage among WYSIWYG editors. e) The "forecolor" and "hilitecolor" commands left undefined. The former changes the text color, and the latter changes the background color, of the selection - based on the provided value argument. Again, these are used quite much. f) The "fontname", "fontsize", "justifyleft", "justifycenter", "justifyright", and "justifyfull", "insertorderedlist", "insertunorderedlist", "indent", and "outdent" commands are also undefined. Often used by WYSIWYG editors. g) The "formatblock" should also allow "div", and all the values should not be case sensitive. h) The "heading" command should be defined as well. The value provided can be h1, h2, h3, h4, h5, or h6. This is used for inserting headings in the document, as needed. i) The "insertimage" command - value being the URI/IRI of the image src attribute. j) A rather important command for me, is the "inserthtml" command, which works like innerHTML on the entire selection - or as "insert HTML at the caret position" (if no selection is available). Even if "innerHTML sucks", I would say this is quite useful. Use case: My editor (like many others) has the option of adding tables (you specify the number of rows and columns you want, and some more). The JS code generates the HTML code as configured, which is inserted into the document with 'inserthtml'. The same goes for a more complex "Insert image" dialog I made that allows changing the alt attribute and some more properties. Most likely, all these commands were left out on purpose. Why was this? Given the spec tries to standardise and bring order into many vendor-specific features implemented over the years (window stuff, window.history, canvas, and some more), Having them properly defined, makes it easier for Web developers and implementors to gain better compatibility across UAs. Recommended reading: Midas from MDC. [8] 2. Based on experience and testing, commandId should be defined as case-insensitive. 3. Regarding the "unselect" command: "Big Issue: We need some sort of way in which the user can make a selection without risk of script clobbering it." Suggestion: why not limit the number of consecutive "unselect" commands? Say a bad script tries to automatically unselect anything more than 3 times. The fourth time ... the command does nothing. Automatic protection against "unselect" abuse. 4. The doShowUI argument has a weird name. Doesn't "showUI" sound better? That's about all, for now. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-contenteditable.html#contenteditable [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-contenteditable.html#user-editing [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-contenteditable.html#making [4] http://www.whatwg.org/issues [5] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dnd.html#dnd [6] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dnd.html#copy-and [7] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-command.html#command [8] http://developer.mozilla.org/en/docs/Midas [9] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-selection.html#documentSelection -- http://www.robodesign.ro
Received on Tuesday, 9 October 2007 18:29:19 UTC