Specs: clean up the last remaining mentions of documents

Review URL: https://codereview.chromium.org/940593003

specs/gestures.md

@@ -170,7 +170,7 @@ class GestureManager {
   GestureManager(this.target) {
     target.events.where((event) => event is PointerDownEvent).listen(_handler);
   }
-  final @nonnull EventTarget target; // usually the ApplicationDocument object
+  final @nonnull EventTarget target; // usually the ApplicationRoot object
 
   Map<@nonnull int, @nonnull PointerState> _pointers = new SplayTreeMap<int, PointerState>();
 

specs/markup.md

@@ -161,8 +161,8 @@ it's the runtime library). None of these elements have shadow trees.
 
 ``<template>``
  - The contents of the element aren't placed in the Element itself.
-   They are instead placed into a DocumentFragment that you can obtain
-   from the element's "content" attribute.
+   They are instead placed into a Fragment that you can obtain from
+   the element's "content" attribute.
 
 ``<script>``
  - Blocks until all previous imports have been loaded, then loads the
@@ -170,7 +170,7 @@ it's the runtime library). None of these elements have shadow trees.
    [scripts.md](scripts.md).
 
 ``<style>``
- - Adds the contents to the document's styles.
+ - Adds the contents to the module's styles.
 
 ``<content>``
 ``<content select="...">``
@@ -202,10 +202,10 @@ it's the runtime library). None of these elements have shadow trees.
    for "foo.bin".
 
 ``<title>``
- - Sets the contents as the document's title (as provided by Sky to
+ - Sets the contents as the application's title (as provided by Sky to
    the view manager). (Actually just ensures that any time the element
-   is mutated, theTitleElement.ownerScope.ownerDocument.title is set
-   to the element's contents.)
+   is mutated, module.application.title is set to the element's
+   contents.)
 
 
 Sky Markup: Global Attributes

specs/modules.md

@@ -13,16 +13,16 @@ most basic form, you import a module as follows:
 <import src="path/to/module.sky" />
 ```
 
-As these ``import`` elements are inserted into a document, the
-document's list of outstanding dependencies grows. When an imported
-module completes, it is removed from the document's list of
-outstanding dependencies.
+As these ``import`` elements are inserted into a module's element
+tree, the module's list of outstanding dependencies grows. When an
+imported module completes, it is removed from the importing module's
+list of outstanding dependencies.
 
 Before compiling script or inserting an element that is not already
 registered, the parser waits until the list of outstanding
 dependencies is empty. After the parser has finished parsing, the
-document waits until its list of outstanding dependencies is empty
-before the module it represents is marked complete.
+module waits until its list of outstanding dependencies is empty
+before marking itself complete.
 
 The ``as`` attribute on the ``import`` element binds a name to the
 imported module:
@@ -49,13 +49,14 @@ final Module module = new Module();
 final Module module = new Application();
 ```
 
-The ``<script>`` elements found in the document create the subsequent
-libraries. Each one first imports the ``dart:mirror`` library, then
-the ``dart:sky`` module, then the first library described above, then
-all the modules referenced by ``<import>`` element up to that
-``<script>`` element and all the libraries defined by ``<script>``
-elements up to that point, interleaved so as to maintain the same
-relative order as those elements were first seen by the parser.
+The ``<script>`` elements found in the module's element tree create
+the subsequent libraries. Each one first imports the ``dart:mirror``
+library, then the ``dart:sky`` module, then the first library
+described above, then all the modules referenced by ``<import>``
+element up to that ``<script>`` element and all the libraries defined
+by ``<script>`` elements up to that point, interleaved so as to
+maintain the same relative order as those elements were first seen by
+the parser.
 
 When a library imports a module, it actually imports all the libraries
 that were declared by that module except the aforementioned element

specs/parsing.md

@@ -783,10 +783,10 @@ Then, pass the tokens to the tree construction stage.
 Tree construction stage
 -----------------------
 
-To construct a node tree from a _sequence of tokens_ and a document
-_document_ (this is implemented in JS):
+To construct a node tree from a _sequence of tokens_ and an element
+tree rooted at a `Root` node _root_ (this is implemented in JS):
 
-1. Initialize the _stack of open nodes_ to be _document_.
+1. Initialize the _stack of open nodes_ to be _root_.
 2. Initialize _imported modules_ to an empty list.
 3. Consider each token _token_ in the _sequence of tokens_ in turn, as
    follows. If a token is to be skipped, then jump straight to the
@@ -814,8 +814,9 @@ _document_ (this is implemented in JS):
      5. Append _node_ to the top node in the _stack of open nodes_.
      6. Push _node_ onto the top of the _stack of open nodes_.
      7. If _node_ is a ``template`` element, then:
-        1. Let _fragment_ be the ``DocumentFragment`` object that the
-           ``template`` element uses as its template contents container.
+        1. Let _fragment_ be the ``Fragment`` object that the
+           ``template`` element uses as its template contents
+           container.
         2. Push _fragment_ onto the top of the _stack of open nodes_.
         If _node_ is an ``import`` element, then:
         1. Let ``url`` be the value of _node_'s ``src`` attribute.
@@ -840,6 +841,6 @@ _document_ (this is implemented in JS):
         associated names as appropriate.
    - If _token_ is an automatic end tag token:
      1. Pop the top node from the _stack of open nodes_, unless it is
-        the document.
+        the _root_ node.
 4. Yield until _imported modules_ has no promises.
 5. Fire a ``load`` event at the _parsing context_ object.

specs/pointer.md

@@ -60,13 +60,15 @@ 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".
 
@@ -93,7 +95,7 @@ is run:
  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
@@ -122,8 +124,9 @@ When a pointer switches from "down" to "up", a non-bubbling
 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
@@ -140,7 +143,7 @@ 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.
@@ -437,8 +440,8 @@ 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

specs/style.md

@@ -159,11 +159,11 @@ same classname), or specifying other redundant or conflicting
 selectors (e.g. [foo][foo=bar], or [foo=bar][foo=baz]) will be
 flagged.
 
-Alternatively, a selector can be the special value "@document",
+Alternatively, a selector can be the special value "@root",
 optionally followed by a pseudo-element, as in:
 
 ```css
-@document::bar
+@root::bar
 ```
 
 
@@ -573,9 +573,9 @@ and pseudoElement from each such Rule.
 Update the render tree
 ----------------------
 
-Simultaneously walk the tree rooted at the application Document,
-taking into account shadow trees and child distribution, and the tree
-rooted at the document's RenderNode.
+Simultaneously walk the tree rooted at the application's element
+tree's root node, taking into account shadow trees and child
+distribution, and the tree rooted at that Root node's RenderNode.
 
 If you come across a node that doesn't have an assigned RenderNode,
 then create one, placing it in the appropriate place in the RenderTree