14455 2011-10-13 18:51:23 +0000 When tapping within a contenteditable, mobile browsers display a VKB that hogs the screen. But what if users don't want to enter any new text? They might instead make a selection, copy it, drag to move it, format it, or paste in something else. Ideally 2011-10-24 14:56:02 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#contenteditable P3 normal --- 1 contributor ayg ayg mike public-html-admin public-html-wg-issue-tracking public-webapps sideshowbarker+html-editing-api oldest_to_newest 58199 0 contributor 2011-10-13 18:51:23 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html Multipage: http://www.whatwg.org/C#contenteditable Complete: http://www.whatwg.org/c#contenteditable Comment: When tapping within a contenteditable, mobile browsers display a VKB that hogs the screen. But what if users don't want to enter any new text? They might instead make a selection, copy it, drag to move it, format it, or paste in something else. Ideally rather than boolean, contenteditable should account for edits that don't require text input. Posted from: 192.100.106.9 User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.83 Safari/535.2 58749 1 ayg 2011-10-24 14:56:02 +0000 This doesn't seem like a strong enough use-case to justify a new mode for contenteditable at this point. There are lots of other things that are much more important. Also, the mobile browser could be smart enough to not pop up the virtual keyboard if you're making a selection, dragging something, etc., and we don't need to change the spec for that. Thanks for your suggestion, though. Please reopen if you think there's something I've missed.