Hi all, I was looking at some of the caret display challenges (e.g., the current caret appears offset compared to the line, position doesn't always expand properly for line heights etc.) and started researching alternative ways of doing things. Additionally, I am trying to avoid modifying the DOM if at all possible as other parts of things I'm working on are using MutationObservers... so less events is better :). Firstly, the current implementation creates a cursor in the document as follows: 1) Find the requested position (e.g., via mouse click or cursor navigation with arrow keys) 2) Insert the cursor node (splitting the text node if necessary) The cursor style position to absolute (to stop the browser from modifying text flow or layout), while the height is set to 1em (to try and mimic the normal line height). Unfortunately, by setting the position to absolute, the browser no longer draws the caret in line with the text vertically, instead choosing to display it at position 0 of the cursor div (quite noticable on some of the documents I'm using). Trying to find a fix for how to get the cursor position correct, I researched how Google Docs does this. I've noticed that Google Docs doesn't insert the caret inline into the text. It has a global caret element, who's position is updated on cursor navigation or clicks. To this end, I made a quick demo showing how the googledocs cursor is achieved. The pro's of this approach: * No modifications of the document structure in order to render the cursor. This will be faster, more memory efficient (due to how text nodes etc. like editing) * Cursor (so far in firefox and chrome at least) renders in a more natural spot, as it is vertically centred, and more easily put between characters (the current implementation also sits a tiny bit too far to the right, though that could be fixed with CSS easily enough I believe) The con's (because nothing is perfect) * Cursor synchronization will always need to be done manually. The existing implementation of placing the cursor inline with the text means the browser can take care of flowing the cursor along as text is edited.With the googledocs approach, each text modification etc. will need to relayout the cursors manually. * Unsure about the speed of this approach * Also unsure about how cross-browser compatible this is... What do people think? Is there any benefit from the Range-based approach vs inserting a cursor node directly in the document? Is it worth me investigating further? Cheers, -- Philip Peitsch Mob: 0439 810 260