ContentEditable New Line Issues

[JAB Creations]

There is inconsistency for creating new lines when users press enter in various browsers for elements with the contenteditable attribute set to true.

I'm not jumping on mailing lists though I think the issue should be easily resolved: web designers. Frankly web designers either get to use or have to deal with standards. The problem I've had while creating a rich text editor is that Firefox consistently refuses to give the keyboard caret focus to paragraph elements enforcing a sort of anti-paragraph element policy. I've filed a bug report.

What browsers should do is honor the web designer's goal, paragraphs or not. If a paragraph exists inside of a contenteditable element then new lines should create new paragraphs. However if there are no paragraph elements present to begin with inside of an element with the contenteditable attribute set to true then new lines should be generated using the breakline element (<br />). This would allow everyone who disagrees to agree because at the end of the day you can choose whichever manner you wish the (X)HTML to be generated.

I should add some clarifications. White space should be completely ignored in the presence of a paragraph element unless a pre element exists (in it's own applicable way). So in example indented paragraphs would gain the keyboard caret focus instead of having the caret be given focus before the first paragraph; this is currently the bugged behavior in Firefox that I submitted the bug report about.

In the presence of pre elements the behavior should be subjective to if the caret is focused inside of the pre element or not; this in effect should allow the web designer to have text in both paragraph elements and directly inside of the element (e.g. divisible element) with the contenteditable attribute. In regards to white space at the beginning of the contenteditable element whichever is encountered first should determine what happens when the user presses enter; if it's a pre element breakline elements should be generated while if it's a paragraph new paragraph elements should be generated. If the user presses the down arrow and moves the keyboard caret in to a pre element then pressing enter should generate breakline elements instead of paragraph elements. In all other cases white space should be completely ignored if the keyboard caret is not focused inside of a pre element.

[JAB Creations]

While reviewing my editor in various browsers I've come across some inconsistent behavior which I think needs to be sorted out.

I quoted some text and all the XHTML are children of a blockquote element that can not be edited. When deleting text with the delete button if a blockquote comes in to range...
- Internet Explorer 9 deletes the blockquote element though leaves it's contents intact.
- Opera and Chrome delete the blockquote element and everything inside of it.
- Firefox prevents the blockquote element from being deleted in any sense.

Clicking on the blockquote element (which is inside the editable element though itself can not be edited) and then pressing delete...
- Opera, Chrome and Internet Explorer 9 does not select the blockquote element as a whole and thus can not delete it as a selected element.
- Firefox selects the text inside (though visibly not the element as a whole) however pressing delete removes the element, partial text selection is (correctly) not possible.

Having a paragraph before and after and then selecting text from the bottom paragraph moving upwards...
- Internet Explorer allows the blockquote which does not allow editing to edit if the blockquote is partially selected, this behavior is incorrect.
- Chrome and Firefox do not allow partial selection of the blockquote element.
- Opera allows partial selection of the blockquote element however does not allow deleting the blockquote element in part, only when the selection includes the whole element.

[JAB Creations]

When clicking on an image inserted in to an editable element...

- Firefox allows you to drag and drop however when you release the mouse Firefox incorrectly only inserts the alternative text.
- Chrome correctly allows you to drag and drop.
- Opera is unable to drag and drop.
- Internet Explorer 9 apparently does not support inserting images.

When selecting content on a page to copy and paste...

- Firefox selects the (X)HTML of the content and then pastes the original source.
- Opera and Internet Explorer 9 copy the text without any (X)HTML formatting.
- Chrome copies the text however it's implementation seems buggy and generated a long horizontal scrollbar.

[zcorpan]

Bring your feedback to Aryeh's attention (send email to whatwg) if there's something his spec doesn't fix.

http://blog.whatwg.org/html-editing-api ... r-feedback

[JAB Creations]

Filed a bug for Gecko where text styling is applied to the divisible element instead of to text specific elements...

https://bugzilla.mozilla.org/show_bug.cgi?id=680701