contenteditable caret: request to more details

Hi,

I am working on Aloha Editor http://aloha-editor.org and we do a some painful browser work arounds for this nice feature. I follow the list for a while, read the specification and some related information with big interest and understand the need to find a way that works for all browser( implementer)s. I am also aware that the contenteditable spec takes few place compared to the rest of HTML5 and it's potential/challenges. Probably because of this some behavior is loosely defined ("...In such cases the behavior is UA-dependent..") and maybe because it is very complicated to define in detail too. I tried to extract some of our issues from which I think they are worth to be defined in HTML5 in favor for a better user experience. All following questions are related to contenteditable and I understood "contenteditable doesn't change how CSS works, it just allows a caret to be inserted inside rendered text nodes." from http://lists.w3.org/Archives/Public/public-html/2008Aug/0468.html

1. how can I determinate the caret position (x/y) in the doc?
We and our users some times have the need to find the position in pixels of the caret inside a document or container (http://getsatisfaction.com/aloha_editor/topics/how_do_i_find_the_text_cursors_x_y_coordinates?utm_content=topic_link&utm_medium=email&utm_source=new_topic)
Here are some usecases where we would need that:
* change the position of the Aloha Editor "floating menu" (a toolbar similar to a right mouse menu)
* move a container element to the carets position in order to show an autocompletion list (eg. spelling or semantic suggestion in continous text and not in lists only as defined in use case http://semantic-editor.com/use-cases/collection-editing)
* display information or an option control as we know from mobile touch screen devices such as iPhone.
We are aware of the workaround with inserting a tag, get its position and remove it. We could live with that even we think there could be needed more such as lineheight to place an information above the caret etc.

2. Where is the caret, when on the border of an element?
The position of the caret near the border of a DOM element defines if the next character is inside or outside the bordered DOM element. Let me explain the use case in a short example of content in a contenteditable div (please consider | as caret and not a character):

When at the end
This <b>is</b>| text
or
This <b>is|</b> text

And on the other hand when at the beginning
This <b>|is</b> text
or
This |<b>is</b> text

How about |<b><i>is</i></b> text and so on.


3. Should the caret really be allowed in an empty element http://www.whatwg.org/specs/web-apps/current-work/#editing-hosts? If so please specify more in detail.

Let me explain the use case in a short example of content in a contenteditable div (please consider | as caret positions after pressing right arrow and not as a character and the word "Space" as a 1 character space):

|Space<b></b>Space

How many key press do you need to reach the right end from the left end? Possible solutions are (among others):

|Space|<b>|</b>|Space|  (4 right arrow key presses)
|Space|<b>|</b>Space|  (3 right arrow key presses)
|Space<b></b>|Space|  (2 right arrow key presses)

The last solution imho seems to be the most natural for the user on what he sees, while you can never reach the empty tag.
How about Space<b><i></i></b>Space ?
Or Space<b contenteditable=false>Space</b>Space?
Please consider the answer of question 2. for this solution.

4. Caret position after a "line separator" insertion
Please specify more in detail where the caret should be rendered. Some browsers do the right thing but render the caret immediately after the BR and do not render a new empty line and the caret at the beginning of it, which imho is the behavior the user expects from such an action. Similar specification has been done for empty elements and would be helpful in this case too.


5. Placing caret in an block element.
Some browsers do not render empty tags for the one or other probably good reason, but this makes it hard to place the caret in these tags as described in http://lists.w3.org/Archives/Public/public-html/2009Jul/0276.html. We work around by inserting a <br class="GENTICS_ephemera"> and we remove this "special" placeholder on special actions (eg. when a JS implementer requests the content of an editable through our API) similar solution as Opera. In the spec I http://www.whatwg.org/specs/web-apps/current-work/#editing-hosts found the note "This means that even an empty block can have the caret inside it, and that when the caret is in such an element, it prevents margins from collapsing through the element". I am not sure how this solved the problem of placing (at user action) the caret in such an element. In the case of Operas implementation of a BR in an empty block element, how should the JS developer know wheater to remove the BR or keep it before sending the content to a backend as the BR did not come from the user. Unspecified modifications of browsers are not easy to handle because some backends cannot handle and users don't see the difference between with or without BR. Even if the browser would remove the inserted BR a post of the "empty" tag would send the BR.



I have a some more questions with selections. 
Is this list the right place to ask such questions? Thank you very much.

In order not to border with already answered questions I checked most of the mails containing contenteditable at the mailing list (89 today)
http://www.w3.org/Search/Mail/Public/search?type-index=public-html&index-type=t&keywords=contenteditable&search=Search
and the bug tracker (1 today)
http://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=contenteditable

Is there any other good place to check before posting?

I would be interested in this feature to be defined much more in detail either in HTML5 or a new spec: Is anyone (W3C, browser developers, JS developers) interested in such a specification? Would W3C support or provide a forum for such a work? Thank you.

All best 
haymo


Haymo Meran 
@spikeatschool http://t.co/8kaMAfi - Great. Hope you join http://sn.im/1te23s and implement AE in Spike@School. Cool Image plugins in queue.
director of product experience at Gentics
+43-17109904-513 | e-mail | skype | Xing | twitter | blog
 
Why is there a picture in my signature?
My picture should remind you that the content you are reading has been written by me - especially for you. I'm writing to you personally because you are important to me. I chose e-mail as tool to get in touch with you. My picture in the signature brings me one step closer to you. You can see me, the person who's message you are reading. Another step closer is my twitter status in the signature. It gives you an idea about what's on my mind right now. Hey - maybe you find it interesting, then reply and tell me what's on your mind!
Maybe you want to know more about creative and vivid communication with today's tools. Then get in touch with me as well! To reply now click here.
Last but not least reason for this signature is that an e-mail signature can be more, than the usual legal notice. I guess you are aware of this email beeing private, confidential, privileged and only for the above mentioned addressee and if you receive this e-mail in error, please advise me immediately and delete the message. I don't have to tell you that any more. And for sure you know that unless confirmed in writing, duly signed by an authorized representative of Gentics Software GmbH, any liability is excluded.
Although taking according measures, complete safety from viruses cannot be guaranteed. Any liability for damages resulting from or in connection with virus infections is excluded. Forum for all disputes out of or in connection with our services is the competent court for the First District, City of Vienna, Austria. Any agreements and all services are governed to the extent or as permitted by Austrian law. Visit Gentics on http://gentics.com. See you ;) 
Gentics Software GmbH, Gonzagagasse 11/25, 1010 Vienna, FN 199328f, ATU49912901