Replaced '.' with '<<' in documentation of '<|' function
Merge pull request #20 from mcveat/documentation-fix

Replaced '.' with '<<' in documentation of '<|' function
Fix Json.customDecoder
Do not require Text module to show runtime error
Fix #811 where port error messages were not the best
doc fix
Merge pull request #21 from Dandandan/master

Simple documentation fix
Fix layout issue with flow right

direction was not applied when the node was actually replaced
Slightly improve documentation
Improve comment layout
improve comment layout
improve comment layout
improve comment layout, update for Signal.Channel
Make draw scheduling more robust.

The primary motivation here is to allow the draw scheduler to cooperate with
an external requestAnimationFrame loop, which users can implement via a port,
or using the experimental [Monitor][] package. Unlike fps, this makes it
possible to achieve 60 fps animation in Elm without regularly dropping frames.

[Monitor]: (https://github.com/jwmerrill/elm-animation-frame)

In the existing implementation, it is possible to block rendering forever
using an external requestAnimationFrame loop by scheduling a new domUpdate for
the beginning of each animation frame. This cancels the previous draw callback
(using cancelAnimationFrame), and schedules a new draw callback that will not
run until the *next* frame. If a new domUpdate is requested in the next frame
also, the new draw callback will also be cancelled, and the process can repeat
arbitrarily long until new domUpdates stop being requested.

The new implementation does not use cancelAnimationFrame. Instead, it uses a
small state machine to ensure that only one drawCallback is ever scheduled per
frame.

The new implementation also drops the vendor prefixes on requestAnimationFrame
because [no recent browser uses them][1]. In case requestAnimationFrame is not
available, it uses `setTimeout(cb, 1000/60)`. The existing implementation used
an immediate call, but I think it's better to throttle draw calls to make the
behavior more similar to the case where requestAnimationFrame is available.

[1]: (https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame#Browser_compatibility)

A final small advantage of the new implementation is that, unlike the existing
implementation, it does not create a new function closure on every draw call.
Reduce draw scheduler state machine to 2 states.

This is transitional. A two state state-machine is just a boolean flag. But I
wanted to checkpoint here to make it clear how the implementations relate to
eachother.
Convert state machine to a single boolean.

drawScheduled: false corresponds to EMPTY
drawScheduled: true corresponses to SCHEDULED
Merge pull request #25 from jwmerrill/robust-draw-loop

Make draw scheduling more robust.
Revert "Convert state machine to a single boolean."

This reverts commit f4f277b60a149af221e3e6a495da432488da08ee.
Revert "Reduce draw scheduler state machine to 2 states."

This reverts commit 610345904b89d5301613707e9d088b0a2358cd82.
Change names and add comments to make reasoning clearer