- From: Johannes Wilm <johanneswilm@gmail.com>
- Date: Sun, 22 Dec 2013 01:22:01 +0100
- To: Aryeh Gregor <ayg@aryeh.name>
- Cc: Ojan Vafai <ojan@chromium.org>, Travis Leithead <travis.leithead@microsoft.com>, Alex Mogilevsky <alexmog@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Robin Berjon (robin@w3.org)" <robin@w3.org>, "yosin@chromium.org" <yosin@chromium.org>, Adrian Bateman <adrianba@microsoft.com>
Hey, is there any news on this or on content editable in general? Would it be a better idea to just forget about contenteditable and instead implement everything using javascript, the way Codemirror has done it ( http://codemirror.net/demo/variableheight.html)? On Mon, Jun 10, 2013 at 1:45 PM, Aryeh Gregor <ayg@aryeh.name> wrote: > On Sat, Jun 1, 2013 at 1:27 AM, Ojan Vafai <ojan@chromium.org> wrote: >> The main use case I can think of for mixed editability is an image with a caption. If anyone has other use-cases, that would be helpful in reasoning about this. http://jsfiddle.net/UAJKe/ > > A video with JavaScript controls comes to mind. Any embedded widget, really. > >> Looking at that, I think we should make it so that a selection can never cross an editing boundary. So, in the image caption example, put your cursor right before the uneditable div, then: >> 1. Right arrow should move your cursor into the caption text. >> 2. Shift+right arrow should select the whole uneditable div. >> >> And delete/backspace can just be defined as extending the selection one position and then removing the selected DOM. Relatedly, if you are at the beginning of the caption text and hit backspace, nothing happens because the backspace had nothing to select (i.e. selections are contained within their first contentEditable=true ancestor). > > Delete/backspace are more complicated than just selecting one position > and removing. For instance, backspacing at the beginning of a block > is complicated, and the spec says (following Word and OpenOffice) that > backspacing after a link should unlink it rather than delete the last > character. (Browsers don't do the latter yet, but it's particularly > essential when autolinking is supported -- otherwise it's annoying to > unlink something that the browser helpfully linked it without asking > you.) > > The rest of what you say sounds reasonable. > >> As to the question of whether delete/backspace should select or remove non-editable elements, I'm not opposed to giving this a try in Chromium and seeing if users are confused by it, but I'm skeptical it will make sense to people. > > I'm not sure either. It's what the "behavior when typing in > contentEditable elements" document recommends for tables. Maybe it > makes more sense to just delete it, and assume the user is clever > enough to undo if they didn't want it deleted. -- Johannes Wilm http://www.johanneswilm.org tel US: +1 (520) 399 8880 tel NO: +47 94109013 tel DE: +49 176 370 18082
Received on Sunday, 22 December 2013 00:22:31 UTC