Re: [editing] nested contenteditable
On Sun, Dec 22, 2013 at 2:22 AM, Johannes Wilm wrote: > 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)? I am not aware of any news on this. Authors should definitely use whatever tool works best for them -- last I checked, editors tend to need to use contenteditable for at least some things if they want the editing area to integrate nicely and behave as all users expect, but you need a lot of JavaScript to get it working acceptably. Browser implementers still need to care about contenteditable, because many websites still use it, so they can't just forget about it.
Re: [editing] nested contenteditable
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 wrote: > On Sat, Jun 1, 2013 at 1:27 AM, Ojan Vafai 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
Re: [editing] nested contenteditable
On Sat, Jun 1, 2013 at 1:27 AM, Ojan Vafai 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.
Re: [editing] nested contenteditable
On Thu, May 30, 2013 at 3:52 AM, Aryeh Gregor wrote: > On Tue, May 28, 2013 at 8:27 PM, Travis Leithead > wrote: > > As far as I know, there is no actively maintained editing spec at the > > moment. Aryeh’s document is a great start but by no means should it be > > considered complete, or the standard to which you should target an > > implementation… I think we would [currently] prefer to discuss specific > > issues here on the mailing list until a regular editor can be found—so > > thanks for bringing this up! > > > > > > > > By the way, what you suggest sounds reasonable for the behavior. > > Agreed on all points, FWIW. I'm not totally sure what the most > sensible behavior is for backspacing into a non-editable element is, > but selecting is a reasonable idea that the spec already recommends > for tables (although I don't think anyone implements that point last I > checked). It makes it clear that the next backspace will delete the > whole thing, which would otherwise be very surprising -- e.g., suppose > it were a simple run of text that wasn't visually distinguishable from > the surrounding editable content. > 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/ 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). 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.
Re: [editing] nested contenteditable
Ok, great! So we all agree. Now what is the next step from here going forward? How do we determine if there is dissent? If there is not, what are the steps needed to get it into the specification? How about the other email about moving around SVGS, moving in front of stub elements and noneditable elements that are at the start of an editable element, etc.? On Thu, May 30, 2013 at 6:52 AM, Aryeh Gregor wrote: > On Tue, May 28, 2013 at 8:27 PM, Travis Leithead > wrote: > > As far as I know, there is no actively maintained editing spec at the > > moment. Aryeh’s document is a great start but by no means should it be > > considered complete, or the standard to which you should target an > > implementation… I think we would [currently] prefer to discuss specific > > issues here on the mailing list until a regular editor can be found—so > > thanks for bringing this up! > > > > > > > > By the way, what you suggest sounds reasonable for the behavior. > > Agreed on all points, FWIW. I'm not totally sure what the most > sensible behavior is for backspacing into a non-editable element is, > but selecting is a reasonable idea that the spec already recommends > for tables (although I don't think anyone implements that point last I > checked). It makes it clear that the next backspace will delete the > whole thing, which would otherwise be very surprising -- e.g., suppose > it were a simple run of text that wasn't visually distinguishable from > the surrounding editable content. > -- Johannes Wilm http://www.johanneswilm.org tel US: +1 (520) 399 8880 tel NO: +47 94109013 tel DE: +49 176 370 18082
Re: [editing] nested contenteditable
On Tue, May 28, 2013 at 8:27 PM, Travis Leithead wrote: > As far as I know, there is no actively maintained editing spec at the > moment. Aryeh’s document is a great start but by no means should it be > considered complete, or the standard to which you should target an > implementation… I think we would [currently] prefer to discuss specific > issues here on the mailing list until a regular editor can be found—so > thanks for bringing this up! > > > > By the way, what you suggest sounds reasonable for the behavior. Agreed on all points, FWIW. I'm not totally sure what the most sensible behavior is for backspacing into a non-editable element is, but selecting is a reasonable idea that the spec already recommends for tables (although I don't think anyone implements that point last I checked). It makes it clear that the next backspace will delete the whole thing, which would otherwise be very surprising -- e.g., suppose it were a simple run of text that wasn't visually distinguishable from the surrounding editable content.
Re: [editing] nested contenteditable
+Ryosuke - he is actively working on editing in WebKit. On Wed, May 29, 2013 at 2:27 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > As far as I know, there is no actively maintained editing spec at the > moment. Aryeh’s document is a great start but by no means should it be > considered complete, or the standard to which you should target an > implementation… I think we would [currently] prefer to discuss specific > issues here on the mailing list until a regular editor can be found—so > thanks for bringing this up! > > ** ** > > By the way, what you suggest sounds reasonable for the behavior. > > ** ** > > *From:* johannesw...@gmail.com > [mailto:johannesw...@gmail.com] > *On Behalf Of *Johannes Wilm > *Sent:* Tuesday, May 28, 2013 6:36 AM > *To:* public-webapps@w3.org; ro...@w3.org; Alex Mogilevsky; Travis > Leithead; a...@aryeh.name; yo...@chromium.org > *Subject:* [editing] nested contenteditable > > ** ** > > Hey, > > is there any progress on finding out who is to maintain this spec: > https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still > a fulltime student? > > ** ** > > There is an effort at Chromium to make deletion of non-editable > subelements work according to the spec, but the spec doesn't seem to > anything about this. > > ** ** > > See: https://code.google.com/p/chromium/issues/detail?id=238000 > > > ** ** > > ** ** > > Who could we ask to get the sepcification updated with information about > this? > > ** ** > > Our current suggestion is that backspacing/deleting into it selects it, > and a second hit on backspace/delete will remove it. The most important to > me though is to have clarity on this. > > ** ** > > ** ** > > -- > > Johannes Wilm > > Fidus Writer > > http://www.fiduswriter.com > -- Takayoshi Kochi
[editing] nested contenteditable
Hey, is there any progress on finding out who is to maintain this spec: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still a fulltime student? There is an effort at Chromium to make deletion of non-editable subelements work according to the spec, but the spec doesn't seem to anything about this. See: https://code.google.com/p/chromium/issues/detail?id=238000 Who could we ask to get the sepcification updated with information about this? Our current suggestion is that backspacing/deleting into it selects it, and a second hit on backspace/delete will remove it. The most important to me though is to have clarity on this. -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
[editing] deletion and moving caret across stub and contenteditable=false elements (was: Re: [editing] nested contenteditable)
Ok, great! Then I have three other, slightly related suggestions which I would be interested in hearing your opinion about: 1. How should the stub elements images, canvas elements and inline SVGs be treated in a contenteditable environment? My suggestion is that they are treated the same: as if they were individual letters. That means that moving the cursor across them (hitting right or left while it the caret is directly to the right or left of it) should move the cursor all the way across them, but no further. The caret should be able to go between two stub elements, and before a stub element at the very start of a paragraph and after a stub element at the very end of a paragraph. This is already the current behavior for -elements in IE10, Chrome and FF. Chrome fails at inline SVG elements, but handles canvas elements this way already. FF fails at canvas elements but handles inline SVG elements this way already. IE10 fails moving across canvas elements, but handles SVG elements this way already. See the first three examples of these bug reports: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 https://code.google.com/p/chromium/issues/detail?id=242110 2. How should contenteditable=false elements be handled that do not have a nested contenteditable=true inside of them? I suggest that they are handled the same way as those that do have a contenteditable=true element inside of them wen it comes to backspace/delete: if the caret is on one side of the element and the backspace (when caret is on right side)/delete key (when caret is on left side) is hit, they are selected entirely (as described in my previous email). A second hit will remove them entirely. This is the way this specification draft suggests handling tables. 3. What should happen if the caret moves across contenteditable=false WITHOUT nested contenteditable=true elements? I suggest that it should behave like stub elements (point 1). This is already the behavior of Chrome. FF moves across them, but jumps an extra letter. IE10 jumps to the start of the contenteditable element. The behavior of IE10 and FF does not seem sensible. 4. What should happen if the caret moves across contenteditable=false WITH nested contenteditable=true elements? I suggest the caret should move inside the nested elements asmit has been described in previous specs. None of the browsers seem to work very well with that scenario currently. *) tested with Chrome 29, FF 21, IE 10.0.9200.16580 On Tue, May 28, 2013 at 1:27 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > As far as I know, there is no actively maintained editing spec at the > moment. Aryeh’s document is a great start but by no means should it be > considered complete, or the standard to which you should target an > implementation… I think we would [currently] prefer to discuss specific > issues here on the mailing list until a regular editor can be found—so > thanks for bringing this up! > > ** ** > > By the way, what you suggest sounds reasonable for the behavior. > > ** ** > > *From:* johannesw...@gmail.com > [mailto:johannesw...@gmail.com] > *On Behalf Of *Johannes Wilm > *Sent:* Tuesday, May 28, 2013 6:36 AM > *To:* public-webapps@w3.org; ro...@w3.org; Alex Mogilevsky; Travis > Leithead; a...@aryeh.name; yo...@chromium.org > *Subject:* [editing] nested contenteditable > > ** ** > > Hey, > > is there any progress on finding out who is to maintain this spec: > https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still > a fulltime student? > > ** ** > > There is an effort at Chromium to make deletion of non-editable > subelements work according to the spec, but the spec doesn't seem to > anything about this. > > ** ** > > See: https://code.google.com/p/chromium/issues/detail?id=238000 > > > ** ** > > ** ** > > Who could we ask to get the sepcification updated with information about > this? > > ** ** > > Our current suggestion is that backspacing/deleting into it selects it, > and a second hit on backspace/delete will remove it. The most important to > me though is to have clarity on this. > > ** ** > > ** ** > > -- > > Johannes Wilm > > Fidus Writer > > http://www.fiduswriter.com > -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
RE: [editing] nested contenteditable
As far as I know, there is no actively maintained editing spec at the moment. Aryeh's document is a great start but by no means should it be considered complete, or the standard to which you should target an implementation... I think we would [currently] prefer to discuss specific issues here on the mailing list until a regular editor can be found-so thanks for bringing this up! By the way, what you suggest sounds reasonable for the behavior. From: johannesw...@gmail.com<mailto:johannesw...@gmail.com> [mailto:johannesw...@gmail.com] On Behalf Of Johannes Wilm Sent: Tuesday, May 28, 2013 6:36 AM To: public-webapps@w3.org<mailto:public-webapps@w3.org>; ro...@w3.org<mailto:ro...@w3.org>; Alex Mogilevsky; Travis Leithead; a...@aryeh.name<mailto:a...@aryeh.name>; yo...@chromium.org<mailto:yo...@chromium.org> Subject: [editing] nested contenteditable Hey, is there any progress on finding out who is to maintain this spec: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still a fulltime student? There is an effort at Chromium to make deletion of non-editable subelements work according to the spec, but the spec doesn't seem to anything about this. See: https://code.google.com/p/chromium/issues/detail?id=238000 Who could we ask to get the sepcification updated with information about this? Our current suggestion is that backspacing/deleting into it selects it, and a second hit on backspace/delete will remove it. The most important to me though is to have clarity on this. -- Johannes Wilm Fidus Writer http://www.fiduswriter.com<http://www.fiduswriter.com/>
