- From: Johannes Wilm <johannes@fiduswriter.org>
- Date: Tue, 24 Jun 2014 13:41:30 +0200
- To: Robin Berjon <robin@w3.org>
- Cc: Xavier Morel <xmo@openerp.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, public-editing-tf@w3.org
- Message-ID: <CABkgm-Qu-i-9biEGaWLN2Ui61TkEB9U-AQ4GWOkXxzL9vXAkkA@mail.gmail.com>
On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon <robin@w3.org> wrote: <snip> > > From discussions I've had in the past on this topic, it's not so much that > browser-folks don't want to fix this. The problem is more that 1) this is > hard, so fixing can often only happen if someone really owns the problem > rather than contributing the odd fix, and such a person isn't always > available; 2) the current state of contentEditable is such a mess, notably > with libraries doing per-UA workarounds, that fixes that make the behaviour > globally saner actually break deployed code. > Don't worry. I don't think browser people are evil. :) It may just be that this isn't a priority for browser makers, as it's not that widely used, and CkEditor/TinyMCE are doing a good job most places. > > This has conspired to make the situation rot. Hopefully we can fix this > with the new tack taken here, notably by using contentEditable=cursor as a > "sanity hook" which doesn't have to be backwards compatible with the > existing madness. > > You point to several bugs, but I think the one most worth reading is: > > https://code.google.com/p/chromium/issues/detail?id=238000 > > This has a wealth of issues and information, as well as a number of good > ideas. Piotr's point about the behaviour of deletion when a selection > crosses an even number of editing boundaries is particularly useful. > Deletion is indeed a difficult thing and I would estimate that maybe half of our code that deals with contenteditable deals with backspace, del, and the error keys in some way or another. > The way we've been thinking about this so far is that with cE=cursor, the > browser would perform no DOM modification on your behalf but rather you'd > have to handle events in order to carry out the modifications yourself. > This increases the amount of work that script has to do but in this case it > would likely enable you to produce the precise handling you require. > Having said that, considering this specific problem makes me realise that > the deletion event model that I had in mind does not work. <snip> > Thoughts? Yes, exactly. All your proposals sound fine concerning this. Yet even if it's up to the javascript library to decide what should happen, it would still be nice to have some kind of standard behavior defined so that web users get used to one way. For example, it was mentioned several times in various discussions that del/backspace in the case of "complex elements" that are being treated as a single character when it comes to cursor movement, should be selected rather than deleted if the range is empty. A second press on backspace or delete will then delete them and collapse the selection range. This was what the previous draft on cursor movement in contenteditable said about tables. It doesn't need to specifically be that way, but it could. Wikimedia have implemented this in their latest attempt at a WYSIWYG editor: https://en.wikipedia.org/w/index.php?title=Repulsion_theory&veaction=edit (try deleting the "[2]" with the cursor either in front or behind it). I would think that elements involving several editing boundaries should in just about all cases be classified as "complex elements". > > > > Use cases for this: >> >> 1. We use it for footnotes which we float of to the right of the text in >> a <span class="footnote" contneteditable=false><span><span >> contenteditable="true">[FOOTNOTE TEXT]</span></span></span>. If one has >> access to CSS regions, one can even float them to be under the text on >> each page. The other <span class="footnote"> is used to draw the >> footnote number in the main text. If one hits backspace behind it, the >> entire footnote should disappear. as it is now, instead the "back wall" >> of the footnote is removed which means that the rest of the paragraph >> is being added to the footnote. >> > > A question for you: how would you like selection to work in this case, > notably for copy/pasting? As a user, I would tend to expect that if I > select from before the <sup>1</sup> to after it and copy, I would get a > buffer containing the <sup>1</sup> but *not* the footnote content > (otherwise you get the famed "PDF effect" with lots of junk in your > buffer). It also looks visually weird if you have the footnote to the side > of the page being selected. But with the logical document order you use, it > would get selected. Do you make use of selection-preventing tricks? > Actually in our case, we would expect for the footnote and its contents to also be selected and copied along with the main text that surrounds it. But our use case may be very specific and different from how others use footnotes: In our case the student/academic decides that two paragraphs from the beginning of chapter 2 should be moved to the end of chapter 4 instead. The footnotes should move along with the main text, and should therefor be part of the selection-copy-paste process. *Placing footnotes to the right/left of the main text was a solution we found when it became clear that CSS Regions would be removed from Chrome. Previously we "flowed" them to below the text for Chrome and Safari users. However, it now turns out that while footnotes make sense at the bottom of a printed page, in the case of an editor, it's not always convenient to have to scroll down to read a footnote and then back up again to continue reading the main text. A little piece of Javascript that maintains a page-wide CSS-deifnition makes sure that the footnotes never overlap.* > > These likely have their own amusing interactions with deletion: if you > make the footnote non-selectable but wish to drop it when a selection > encompassing it is deleted, you're facing a fun new challenge. > > > -- > Robin Berjon - http://berjon.com/ - @robinberjon > -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Received on Tuesday, 24 June 2014 11:41:58 UTC