[Docs] fixes

docs/how_to_extend_layout_test_framework.md

 # How to Extend the Layout Test Framework
 
 The Layout Test Framework that Blink uses is a regression testing tool that is
 multi-platform and it has a large amount of tools that help test varying types
 of regression, such as pixel diffs, text diffs, etc. The framework is mainly
 used by Blink, however it was made to be extensible so that other projects can
 use it test different parts of chrome (such as Print Preview). This is a guide
 to help people who want to actually the framework to test whatever they want.
 
 [TOC]
@@ skipping 13 matching lines @@
 
 The second part is creating a driver (program) to actually communicate the
 layout test framework. This part is significantly more tricky and dependant on
 what exactly exactly is being tested.
 
 ### Part 1
 
 This part isn’t too difficult. There are basically two classes that need to be
 extended (ideally, just inherited from). These classes are:
 
-    Driver
-
-Located in `layout_tests/port/driver.py`. Each instance of this is the class
-that will actually an instance of the program that produces the test data
-(program in Part 2).
-
-    Port
-
-Located in `layout_tests/port/base.py`. This class is responsible creating
-drivers with the correct settings, giving access to certain OS functionality to
-access expected files, etc.
+*   `Driver`. Located in `layout_tests/port/driver.py`. Each instance of this is
+    the class that will actually an instance of the program that produces the
+    test data (program in Part 2).
+*   `Port`. Located in `layout_tests/port/base.py`. This class is responsible
+    creating drivers with the correct settings, giving access to certain OS
+    functionality to access expected files, etc.
 
 #### Extending Driver
 
 As said, Driver launches the program from Part 2. Said program will communicate
 with the driver class to receive instructions and send back data. All of the
 work for driver gets done in `Driver.run_test`. Everything else is a helper or
 initialization function.
 
 `run_test()` steps:
 
@@ skipping 57 matching lines @@
 problems, therefore port itself shouldn’t be extend. Instead LinuxPort, WinPort,
 and MacPort (and maybe the android port class) should be extended as they
 provide platform specific overrides/extensions that implement most of the
 important functionality. While there are many functions in Port, overriding one
 function will affect most of the other ones to get the desired behavior. For
 example, if `layout_tests_dir()` is overriden, not only will the code look for
 tests in that directory, but it will find the correct TestExpectations file, the
 platform specific expected files, etc.
 
 Here are some of the functions that most likely need to be overridden.
+
 *   `driver_class`
     *   This should be overridden to allow the testing program to actually run.
         By default the code will run content_shell, which might or might not be
         what you want.
     *   It should be overridden to return the driver extension class created
         earlier. This function doesn’t return an instance on the driver, just
         the class itself.
 *   `driver_name`
     *   This should return the name of the program test p. By default it returns
         ‘content_shell’, but you want to have it return the program you want to
@@ skipping 124 matching lines @@
             *   In this case this is how your output should look.
                 *   “Content-type: image/png\n”
                 *   “ActualHash: hashData\n”
                 *   “Content-Length: lengthOfPng\n”
                 *   “pngdata”
                     *   This part doesn’t need a header specifying that you are
                         sending png data, just send it
                 *   “#EOF\n” on both stdout and stderr
             *   To see the structure of the data required, look at the
                 `read_block` functions in Driver.py