This is a problem on iOS, where a soft keyboard can obscure part of the user interface, and the cursor can be hidden from view. In my opinion, since contenteditable elements may be used for user input, they should be treated the same as form elements. In our email client, we use a <div contenteditable=true> element for composing emails. The problem on iOS is that we need to do complex cursor management which I think we should get for free, because form elements already exhibit the desired behavior. Without cursor management, when someone is editing our <div contenteditable=true>, the cursor can disappear beneath the soft keyboard. This is unfortunate. If we used a TEXTAREA element instead, we would get automatic cursor management for free. With a TEXTAREA, WebKit is smart enough to keep the cursor in view as the TEXTAREA is edited, even with the soft keyboard in view. However, we cannot use a TEXTAREA for user input in this case, because composing a rich-text, HTML-based email requires us to insert arbitrary markup-- not just the text input of a TEXTAREA. Because contenteditable elements can function as inputs, I believe they should be treated by WebKit just like form elements are: when it's focused, it should automatically be brought into view and kept in view as it is edited. If the automatic scrolling or zooming are detrimental in some cases, perhaps we should allow for an option to enable or disable this proposed behavior.
Another challenge we face which is related, but perhaps deserving of a second bug filing: Our cursor management utilities can only react to text input-- we cannot react to arrow keys. When a user is navigating a contenteditable element with the arrow keys, keydown events are not generated. Thus, while our cursor management utilities are able to react as the user types, generating new lines with character and return char inputs, if the user uses arrow keys (e.g. with a bluetooth keyboard paired with an iPad), we cannot detect the event and reposition the scroll position of the element so that the cursor stays in view. A third difficulty with custom cursor management? We don't know exactly how high the keyboard is. We can estimate the height, but we are unable to account for user preferences such as: are suggestions turned on? Is the user using a split-keyboard? The former, and perhaps the latter, affects the height of the soft keyboard. A fourth difficulty is that a soft keyboard may or may not appear, depending on keyboard pairing, and there is no event that we can listen to which tells us if the soft keyboard has been displayed. These problems make the issue of contenteditable ideally behaving like a TEXTAREA in terms of cursor management is even more important.
Thanks for the report! The lack of automatic scrolling to reveal the caret when typing is tracked internally by <rdar://problem/28300343>. However, the change corresponding to this radar is in another system component (UIKit). As such, this isn't a WebKit bug, but rather a UIKit bug. Moving to config changed.