Re: [editing] Should the caret move by default, and should we define this behavior? (#58)

I think the track changes one is a good example: I don't think anyone knows why it worked about a year ago and what exactly make it stop. The way to create it was simply: Create some basic code and some basic tests. Add if clauses to the code until the tests all work. Then try it out in real-life. Whenever you run into another issue, create another test and add another if clause somewhere in the code until it works. Then you test on other browsers and add more if clauses, and so on. Every time a new Firefox or Chrome version comes out, run all the tests. If something is broken, add more if clauses in the code until all the tests run again, etc. . So it's just one gigantic mess of spaghetti code. What you can do is try to remove some of the if statements and then see what happens and what breaks in what browser. This track changes plugin can now be found in derived versions as plugins for the main contenteditable-based editors. And I think it's the only one so far.

As for some bug reports:

Your issue  nr 3 (non-editable islands): https://code.google.com/p/chromium/issues/detail?id=238000#c6

Most relevant for caret movement is this one: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 (also reported to Chrome and also contacted Webkit team at the time they still were united). The caret cannot move between these elements. It can move between some in Firefox and others in Chrome. Just moving around images is working in both. These are important because using canvases, within a line is a way to make sure that footnotes are placed correctly and can be moved with copy and pasting -- I created a demo with that here: http://johanneswilm.github.io/canvasContentEditable/ .


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/58#issuecomment-108652046