Specs: clean up the last remaining mentions of documents

sky/specs/pointer.md

 Pointer Events
 ==============
 
 Scope
 -----
 
 The following input devices are supported by sky:
  - fingers on multitouch screens
  - mice, including mouse wheels
  - styluses on screens
@@ skipping 42 matching lines @@
 Pointers
 --------
 
 Each touch or pointer is tracked individually.
 
 New touches and pointers can appear and disappear over time.
 
 Each pointer has a list of current targets.
 
 When a new one enters the system, a non-bubbling ``PointerAddedEvent``
-event is fired at the application's document, and the pointer's
-current targets list is initialised to just that Document object.
+event is fired at the application's element tree's root node, and the
+pointer's current targets list is initialised to just that Root
+object.
 
 When it is removed, a non-bubbling ``PointerRemovedEvent`` event is
-fired at the application's document and at any other objects in the
-pointer's current targets list. Currently, at the time of a
-``PointerRemoved``, the list will always consist of only the document.
+fired at the application's element tree's root node and at any other
+objects in the pointer's current targets list. Currently, at the time
+of a ``PointerRemoved``, the list will always consist of only the
+application's element tree's root node.
 
 A pointer can be "up" or "down". Initially all pointers are "up".
 
 A pointer switches from "up" to "down" when it is a touch or stylus
 that is in contact with the display surface, or when it is a mouse
 that is being clicked, and from "down" back to "up" when this ends.
 (Note that clicking a button on a stylus doesn't change it from up to
 down. A stylus can have a button pressed while "up".) In the case of a
 mouse with multiple buttons, the pointer switches back to "up" only
 when all the buttons have been released.
 
 When a pointer switches from "up" to "down", the following algorithm
 is run:
 
  1. Hit test the position of the pointer, let 'node' be the result.
  2. Fire a bubbling ``PointerDownEvent`` event at the layoutManager
     for 'node', with an empty array as the default return value. Let
     'result1' be the returned value.
  3. If result1 is not an array of EventTarget objects, set it to the
     empty array and (if this is debug mode) report the issue.
  4. Fire a bubbling ``PointerDownEvent`` event at the Element for
     'node', with an empty array as the default return value. Let
     'result2' be the returned value.
  5. If result2 is not an array of EventTarget objects, set it to the
     empty array and (if this is debug mode) report the issue.
  6. Let result be the concatenation of result1's contents, result2's
-    contents, and the application document.
+    contents, and the application's element tree's root node.
  7. Let 'result' be this pointer's current targets.
 
 When an object is one of the current targets of a pointer and no other
 pointers have that object as a current target so far, and either there
 are no buttons (touch, stylus) or only the primary button is active
 (mouse) and this is not an inverted stylus, then that pointer is
 considered the "primary" pointer for that object. The pointer remains
 the primary pointer for that object until the corresponding
 ``PointerUpEvent`` event (even if the buttons change).
 
 When a pointer moves, a non-bubbling ``PointerMoveEvent`` event is
 fired at each of the pointer's current targets in turn (maintaining
 the order they had in the ``PointerDownEvent`` event, if there's more
 than one). If the return value of a ``PointerMovedEvent`` event is
 'cancel', and the pointer is currently down, then the pointer is
 canceled (see below).
 
 When a pointer's button state changes but this doesn't impact whether
 it is "up" or "down", e.g. when a mouse with a button down gets a
 second button down, or when a stylus' buttons change state, but the
 pointer doesn't simultaneously move, then a ``PointerMovedEvent``
 event is fired anyway, as described above, but with dx=dy=0.
 
 When a pointer switches from "down" to "up", a non-bubbling
 ``PointerUpEvent`` event is fired at each of the pointer's current
 targets in turn (maintaining the order they had in the
 ``PointerDownEvent`` event, if there's more than one), and then the
 pointer's current target list is emptied except for the application's
-document. The buttons exposed on the ``PointerUpEvent`` event are
-those that were down immediately prior to the buttons being released.
+element tree's root node. The buttons exposed on the
+``PointerUpEvent`` event are those that were down immediately prior to
+the buttons being released.
 
 At the time of a ``PointerUpEvent`` event, for each object that is a
 current target of the pointer, and for which the pointer is considered
 the "primary" pointer for that object, if there is another pointer
 that is already down, which is of the same kind, which also has that
 object as a current target, and that has either no buttons or only its
 primary button active, then that pointer becomes the new "primary"
 pointer for that object before the ``PointerUpEvent`` event is sent.
 Otherwise, the "primary" pointer stops being "primary" just _after_
 the ``PointerUpEvent`` event. (This matters for whether the 'primary'
 field is set.)
 
 When a pointer is canceled, if it is "down", pretend that the pointer
 moved to "up", sending ``PointerUpEvent`` as described above, and
 entirely empty its current targets list. AFter the pointer actually
 switches from "down" to "up", replace the current targets list with an
-object that only contains the application's document.
+object that only contains the application's element tree's root node.
 
 Nothing special happens when a pointer's current target moves in the
 DOM.
 
 The x and y position of an -up or -down event always match those of
 the previous -moved or -added event, so their dx and dy are always 0.
 
 Positions are floating point numbers; they can have subpixel values.
 
 For each pointer, only a single ``PointerAddedEvent`` or
@@ skipping 276 matching lines @@
 class PointerMovedEvent extends PointerEvent<Null> {
   PointerMovedEvent = PointerEvent;
   bool get bubbles => false;
 }
 ```
 
 Wheel events
 ------------
 
 When a wheel input device is turned, a ``WheelEvent`` event that
-doesn't bubble is fired at the application's document, with the
-following fields:
+doesn't bubble is fired at the application's element tree's root node,
+with the following fields:
 
            wheel: an integer assigned to this wheel by the system. The
                   same wheel on the same system must always be given
                   the same ID. The primary wheel (e.g. the vertical
                   wheel on a mouse) must be given ID 1.
 
            delta: an floating point number representing the fraction of
                   the wheel that was turned, with positive numbers
                   representing a downward movement on vertical wheels,
                   rightward movement on horizontal wheels, and a
@@ skipping 25 matching lines @@
 
   final int wheel;
   final @nonnull double delta; // revolutions (or fractions thereof)
   final int pointer;
   final double x; // logical pixels
   final double y; // logical pixels
 
   bool get bubbles => false;
 }
 ```