Fix spelling mistakes in //docs.

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]
 
 ## Background
 
 Before you can start actually extending the framework, you should be familiar
 with how to use it. See the
 [layout tests documentation](testing/layout_tests.md).
 
 ## How to Extend the Framework
 
 There are two parts to actually extending framework to test a piece of software.
 The first part is extending certain files in:
-[/third_party/Webkit/Tools/Scripts/webkitpy/layout_tests/](/third_party/Webkit/Tools/Scripts/webkitpy/layout_tests/)
+[/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/](/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/)
 The code in `webkitpy/layout_tests` is the layout test framework itself
 
 The second part is creating a driver (program) to actually communicate the
-layout test framework. This part is significantly more tricky and dependant on
+layout test framework. This part is significantly more tricky and dependent 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).
@@ skipping 65 matching lines @@
 
 This class is responsible for providing functionality such as where to look for
 tests, where to store test results, what driver to run, what timeout to use,
 what kind of files can be run, etc. It provides a lot of functionality, however
 it isn’t really sufficient because it doesn’t account of platform specific
 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
+example, if `layout_tests_dir()` is overridden, 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
@@ skipping 129 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