Fix nits in the README.md from abarth's review.

sky/sdk/lib/rendering/README.md

 Sky Rendering
 =============
 
 The Sky render tree is a low-level layout and painting system based on a
 retained tree of objects that inherit from [`RenderObject`](object.dart). Most
 developers using Sky will not need to interact directly with the rendering tree.
 Instead, most developers should use [Sky widgets](../widgets/README.md), which
 are built using the render tree.
 
 Overview
@@ skipping 119 matching lines @@
 ### RenderFlex (render_flex.dart)
 ### RenderParagraph (render_paragraph.dart)
 ### RenderStack (render_stack.dart)
 
 Writing new subclasses
 ----------------------
 
 ### The RenderObject contract
 
 If you want to define a `RenderObject` that uses a new coordinate
-system, then you have to inherit straight from `RenderObject`.
-Examples of doing this can be found in [`RenderBox`](box.dart), which
-deals in rectangles in cartesian space, and in the [sector_layout.dart
+system, then you should inherit straight from `RenderObject`. Examples
+of doing this can be found in [`RenderBox`](box.dart), which deals in
+rectangles in cartesian space, and in the [sector_layout.dart
 example](../../../examples/rendering/sector_layout.dart), which
 implements a toy model based on polar coordinates. The `RenderView`
 class, which is used internally to adapt from the host system to this
 rendering framework, is another example.
 
 A subclass of `RenderObject` must fulfill the following contract:
 
 * It must fulfill the [AbstractNode contract](../base/README.md) when
   dealing with children. Using `RenderObjectWithChildMixin` or
   `ContainerRenderObjectMixin` can make this easier.
 
 * Information about the child managed by the parent, e.g. typically
   position information and configuration for the parent's layout,
   should be stored on the `parentData` member; to this effect, a
   ParentData subclass should be defined and the `setParentData()`
   method should be overriden to initialise the child's parent data
   appropriately.
 
 * Layout constraints must be expressed in a Constraints subclass. This
-  subclass must implement operator== (and hashCode).
+  subclass must implement `operator==` (and `hashCode`).
 
 * Whenever the layout needs updating, the `markNeedsLayout()` method
   should be called.
 
 * Whenever the rendering needs updating without changing the layout,
   the `markNeedsPaint()` method should be called. (Calling
   `markNeedsLayout()` implies a call to `markNeedsPaint()`, so you
   don't need to call both.)
 
 * The subclass must override `performLayout()` to perform layout based
@@ skipping 179 matching lines @@
 
 * Avoid using save/restore on canvases.
 
 
 Dependencies
 ------------
 
  * [`package:sky/base`](../base)
  * [`package:sky/mojo`](../mojo)
  * [`package:sky/animation`](../mojo)