13 |
14 | Return home.
15 |
16 |
17 | One option that could help fix contentEditable, suggested by our friends at
18 | substance, would be to simply expose a primitive way of
19 | making an element accept focus and a cursor, but have this cursor do nothing at all apart
20 | from being movable. None of the DOM manipulations possible with contentEditable
21 | such as inserting characters, deleting, running commands is possible. Those are entirely
22 | the responsibility of code written to handle them.
23 |
24 |
25 | While this may seem like a step back, it can actually provide a far more reliable entry
26 | point with which to write editors. The less the browser does, the fewer bugs there will
27 | be. It also enables a simple MVC approach whereby script intercepts events that intend to
28 | manipulate the content, use those to modify a data model that is not the underlying
29 | DOM, and that data model change then causes a rendering change. It may seem indirect but is
30 | actually a much saner way of handling editing.
31 |
32 |
33 | This behaviour is enabled by setting a cursed attribute on a given element
34 | (while I await inspiration as to a better name).
35 |
36 |
37 | In addition to simple, selecting but not editing behaviour, whenever the user tries to move
38 | the caret across the top or bottom boundary of a given element an event is triggered
39 | (currently called cursed-boundary) with ev.detail.side set to
40 | top or bottom. The point of this event is to enable the use case
41 | in which individual elements are made cursed but in between each of those is an item that
42 | must not be editable (possibly some affordance), thereby making it less convenient to set
43 | their common parent as cursed. The boundary event can be caught so as to move the focus
44 | between editable siblings.
45 |
46 |
47 | The current behaviour of selections and ranges in browsers is so much all over the place
48 | (and in many case so useless) that a proper polyfill for this is probably impossible.
49 |
50 |
51 | WARNING: This code works in Gecko, it is known
52 | NOT to work in Blink and WebKit. IE has not been
53 | tested yet.
54 |
55 |
56 | Gecko also has an appalling selection bug that causes it to report the position of the
57 | cursor at the end of the previous line when it is in fact at the start of the current. This
58 | causes wrong behaviours: when arrowing up or down it can detect boundary too early,
59 | paralysing the cursor. There is no code workaround that I knew to devise. Arrow right to get
60 | unstuck.
61 |
62 |
63 |