Return home.
One option that could help fix contentEditable, suggested by our friends at
substance, would be to simply expose a primitive way of
making an element accept focus and a cursor, but have this cursor do nothing at all apart
from being movable. None of the DOM manipulations possible with contentEditable
such as inserting characters, deleting, running commands is possible. Those are entirely
the responsibility of code written to handle them.
While this may seem like a step back, it can actually provide a far more reliable entry point with which to write editors. The less the browser does, the fewer bugs there will be. It also enables a simple MVC approach whereby script intercepts events that intend to manipulate the content, use those to modify a data model that is not the underlying DOM, and that data model change then causes a rendering change. It may seem indirect but is actually a much saner way of handling editing.
This behaviour is enabled by setting a cursed attribute on a given element
(while I await inspiration as to a better name).
In addition to simple, selecting but not editing behaviour, whenever the user tries to move
the caret across the top or bottom boundary of a given element an event is triggered
(currently called cursed-boundary) with ev.detail.side set to
top or bottom. The point of this event is to enable the use case
in which individual elements are made cursed but in between each of those is an item that
must not be editable (possibly some affordance), thereby making it less convenient to set
their common parent as cursed. The boundary event can be caught so as to move the focus
between editable siblings.
The current behaviour of selections and ranges in browsers is so much all over the place (and in many case so useless) that a proper polyfill for this is probably impossible.
WARNING: This code works in Gecko, it is known NOT to work in Blink and WebKit. IE has not been tested yet.
Gecko also has an appalling selection bug that causes it to report the position of the cursor at the end of the previous line when it is in fact at the start of the current. This causes wrong behaviours: when arrowing up or down it can detect boundary too early, paralysing the cursor. There is no code workaround that I knew to devise. Arrow right to get unstuck.
All of the paragraphs in this section have been cursed. A red border gets added when the boundary event is triggered.
The preceding sections have demonstrated that information can be measured on different scales: in hits, in bits, in dollars. The next question: is there some property that should be common to all the information measures?
To begin with, we imagine two newspapers, one in English and the other in Chinese, both giving the same account of an event. Then, objectively speaking, both newspapers contain the same amount of information about the event. Still, an Englishman may be of the opinion that only the English paper contains information, because he does not understand Chinese. If we allow such subjective judgements, anybody may have any opinion on the information content in a message, and no rules apply. But, what if we want to measure the information content of the message itself, disconnected from the shortcomings of a receiver?
We have already asked "Information about what?". Now we ask "Information to whom?". The true information content of a message can be imagined as the information received by somebody with a complete understanding, who is aptly called the ideal receiver in semantic information theory.