Detailed review of 5.2. The contenteditable attribute and 5.5. The command APIs

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