Spell-checking and proof-reading WhitespaceLayoutObjects.md.

third_party/WebKit/Source/core/dom/WhitespaceLayoutObjects.md

 # Whitespace LayoutObjects
 
 Text nodes which only contain whitespace sometimes have a layout object and
 sometimes they don't. This document tries to explain why and how these layout
 objects are created.
 
 ## Why
 
 For layout purposes, whitespace nodes are sometimes significant, but not
 always. In Blink, we try to create as few of them as possible to save memory,
@@ skipping 31 matching lines @@
 In the example above, we don't need to create a whitespace layout object since
 it will be the first in-flow child of the block, and will not contribute to the
 layout/rendering.
 
 Example:
 
     <span>A</span> <span style="position:absolute">Z</span> <span>B</span>
 
 In the example above, we need to create a whitespace layout object to separate
 the A and B in the rendering. However, we only need to create a layout object
-for one of the whitespace nodes as whitespaces collapse.
+for one of the whitespace nodes as whitespace collapse.
 
 ### Preformatted text and editing
 
-Some values of the CSS white-space property will cause whitespace not to
+Some values of the CSS white-space property will cause whitespace to not
 collapse and affect layout and rendering also in block layout. In those cases
 we always create layout objects for whitespace nodes.
 
 Whitespace nodes are also significant in editing mode.
 
 ## How
 
 ### Initial layout tree attachment
 
 When attaching a layout tree, we walk the flat-tree in a depth-first order
 walking the siblings from left to right. As we reach a text node, we check if
 we need to create a layout object in textLayoutObjectIsNeeded(). In particular,
 if we found that it only contains whitespace, we start traversing the
 previously added layout object siblings, skipping out-of-flow elements, to
 decide if we need to create a whitespace layout object.
 
 Important methods:
 
     Text::attachLayoutTree()
     Text::textLayoutObjectIsNeeded()
 
 ### Layout object re-attachment
 
-During style recalculation, elements whose computed value for display change
+During style recalculation, elements whose computed value for display changes
 will have its layout sub-tree re-attached. Attachment of the descendant layout
-objects happens the same way as for inital layout tree attachment, but the
+objects happens the same way as for initial layout tree attachment, but the
 interesting part for whitespace layout objects is how they are affected by
 re-attachment of sibling elements. Sibling nodes may or may not be re-attached
 during the same style recalc traversal depending on whether they change their
-computed display value or not.
+computed display values or not.
 
 #### Style recalc traversal
 
-An important pre-requisite for how whitespace layout objects are re-attached
+An important prerequisite for how whitespace layout objects are re-attached
 is the traversal order we use for style recalc. The current traversal order
-makes it hard or costly to implement whitespace re-attachement without bugs in
+makes it hard or costly to implement whitespace re-attachment without bugs in
 the presence of shadow trees, but let's describe what we do here.
 
 Style recalc happens in the shadow-including tree order with the exception that
 siblings are traversed from right to left. The ::before and ::after pseudo
 elements are recalculated in left-to-right (!?!) order, before and after
 shadow-including descendants respectively.
 
 Inheritance happens down the flat-tree. Since we are not traversing in
 flat-tree order, we implement this propagation from slot/content elements down
 to assigned/distributed nodes by marking these nodes with LocalStyleChange when
@@ skipping 31 matching lines @@
     <div id="host">
         <:shadow-root>
             <span style="position:absolute">A</span><slot></slot>
         </:shadow-root>
         <span>B</span>
     </div>
 
 Initially, the whitespace before the B span above does not get a layout object.
 If we change the absolute positioned span in the shadow tree to static, we need
 to have a layout object for that whitespace node. However, since we traverse
-traverse the light-tree children of #host after the shadow tree, we do not see
-the text node before re-attaching the absolute positioned span.
+the light-tree children of #host after the shadow tree, we do not see the text
+node before re-attaching the absolute positioned span.
 
 Likewise we currently have issues with ::before and ::after elements because we
 do not keep track of text nodes and pass them to ::before/::after element
 re-attachments. See the "Known issues" below.
 
 Important methods:
 
     Element::recalcStyle()
     ContainerNode::recalcDescendantStyles()
     Node::reattachWhitespaceSiblingsIfNeeded()
     Text::textLayoutObjectIsNeeded()
     Text::reattachLayoutTreeIfNeeded()
     Text::recalcTextStyle()
 
 Known issues:
 
     https://crbug.com/648931
     https://crbug.com/648951
     https://crbug.com/650168