Fix table rendering in the GYP Language Specification.

docs/LanguageSpecification.md

 # Language Specification
 
 [TOC]
 
 ## Objective
 
 Create a tool for the Chromium project that generates native Visual Studio,
 Xcode and SCons and/or make build files from a platform-independent input
 format.  Make the input format as reasonably general as possible without
 spending extra time trying to "get everything right," except where not doing so
@@ skipping 118 matching lines @@
 ### Structural Elements
 
 ### Top-level Dictionary
 
 This is the single dictionary in the `.gyp` file that defines the
 targets and how they're to be built.
 
 The following keywords are meaningful within the top-level dictionary
 definition:
 
-|:-------------     |:------------------|
+| *Keyword*         | *Description*     |
+|:------------------|:------------------|
 | `conditions`      | A conditional section that may contain other items that can be present in a top-level dictionary, on a conditional basis.  See the "Conditionals" section below. |
 | `includes`        | A list of `.gypi` files to be included in the top-level dictionary. |
 | `target_defaults` | A dictionary of default settings to be inherited by all targets in the top-level dictionary.  See the "Settings keywords" section below. |
 | `targets`         | A list of target specifications.  See the "targets" below. |
 | `variables`       | A dictionary containing variable definitions.  Each key in this dictionary is the name of a variable, and each value must be a string value that the variable is to be set to. |
 
 ### targets
 
 A list of dictionaries defining targets to be built by the files
 generated from this `.gyp` file.
 
 Targets may contain `includes`, `conditions`, and `variables` sections
 as permitted in the root dictionary. The following additional keywords
 have structural meaning for target definitions:
 
-|:----------                   |:------------------------------------------|
+| *Keyword*         | *Description*     |
+|:---------------------------- |:------------------------------------------|
 | `actions`                    | A list of special custom actions to perform on a specific input file, or files, to produce output files.  See the "Actions" section below. |
 | `all_dependent_settings`     | A dictionary of settings to be applied to all dependents of the target, transitively.  This includes direct dependents and the entire set of their dependents, and so on.  This section may contain anything found within a `target` dictionary, except `configurations`, `target_name`, and `type` sections.  Compare `direct_dependent_settings` and `link_settings`. |
 | `configurations`             | A list of dictionaries defining build configurations for the target.  See the "Configurations" section below.  |
 | `copies`                     | A list of copy actions to perform. See the "Copies" section below. |
 | `defines`                    | A list of preprocesor definitions to be passed on the command line to the C/C++ compiler (via `-D` or `/D` options). |
 | `dependencies`               | A list of targets on which this target depends.  Targets in other `.gyp` files are specified as `../path/to/other.gyp:target_we_want`. |
 | `direct_dependent_settings`  | A dictionary of settings to be applied to other targets that depend on this target.  These settings will only be applied to direct dependents.  This section may contain anything found within a `target` dictionary, except `configurations`, `target_name`, and `type` sections.  Compare with `all_dependent_settings` and `link_settings`. |
 | `include_dirs`               | A list of include directories to be passed on the command line to the C/C++ compiler (via `-I` or `/I` options). |
 | `libraries`                  | A list of list of libraries (and/or frameworks) on which this target depends. |
 | `link_settings`              | A dictionary of settings to be applied to targets in which this target's contents are linked.  `executable` and `shared_library` targets are linkable, so if they depend on a non-linkable target such as a `static_library`, they will adopt its `link_settings`.  This section can contain anything found within a `target` dictionary, except `configurations`, `target_name`, and `type` sections.  Compare `all_dependent_settings` and `direct_dependent_settings`. |
@@ skipping 27 matching lines @@
 the same set of configurations.  This continues to apply even when a
 project spans across multiple `.gyp` files.
 
 A configuration dictionary may contain anything that can be found within
 a target dictionary, except for `actions`, `all_dependent_settings`,
 `configurations`, `dependencies`, `direct_dependent_settings`,
 `libraries`, `link_settings`, `sources`, `target_name`, and `type`.
 
 Configuration dictionaries may also contain these elements:
 
+| *Keyword*            | *Description*                                       |
 |:---------------------|:----------------------------------------------------|
 | `configuration_name` | Required attribute.  The name of the configuration. |
 
 ### Conditionals
 
 Conditionals may appear within any dictionary in a `.gyp` file.  There
 are two tpes of conditionals, which differ only in the timing of their
 processing.  `conditons` sections are processed shortly after loading
 `.gyp` files, and `target_conditons` sections are processed after all
 dependencies have been computed.
@@ skipping 11 matching lines @@
 global and/or local dictionaries that constructed from the `.gyp` input
 data, and overrides the `__builtin__` dictionary, to prevent the
 execution of arbitrary Python code.
 
 ### Actions
 
 An `actions` section provides a list of custom build actions to perform
 on inputs, producing outputs.  The `actions` section is organized as a
 list.  Each item in the list is a dictionary having the following form:
 
+| *Keyword*     | *Type* | *Description*                |
 |:--------------|:-------|:-----------------------------|
 | `action_name` | string | The name of the action.  Depending on how actions are implemented in the various generators, some may desire or require this property to be set to a unique name; others may ignore this property entirely. |
 | `inputs`      | list   | A list of pathnames treated as inputs to the custom action. |
 | `outputs`     | list   | A list of pathnames that the custom action produces. |
 | `action`      | list   | A command line invocation used to produce `outputs` from `inputs`.  For maximum cross-platform compatibility, invocations that require a Python interpreter should be specified with a first element `"python"`.  This will enable generators for environments with specialized Python installations to be able to perform the action in an appropriate Python environment. |
 | `message`     | string | A message to be displayed to the user by the build system when the action is run. |
 
 Build environments will compare `inputs` and `outputs`.  If any `output`
 is missing or is outdated relative to any `input`, the custom action
 will be invoked.  If all `outputs` are present and newer than all
@@ skipping 37 matching lines @@
         },
       ],
 ```
 
 ### Rules
 
 A `rules` section provides custom build action to perform on inputs, producing
 outputs.  The `rules` section is organized as a list.  Each item in the list is
 a dictionary having the following form:
 
+| *Keyword*   | *Type* | *Description*                            |
 |:------------|:-------|:-----------------------------------------|
 | `rule_name` | string | The name of the rule.  Depending on how Rules are implemented in the various generators, some may desire or require this property to be set to a unique name; others may ignore this property entirely. |
 | `extension` | string | All source files of the current target with the given extension will be treated successively as inputs to the rule. |
 | `inputs`    | list   | Additional dependencies of the rule. |
 | `outputs`   | list   | A list of pathnames that the rule produces. Has access to `RULE_INPUT_` variables (see below). |
 | `action`    | list   | A command line invocation used to produce `outputs` from `inputs`.  For maximum cross-platform compatibility, invocations that require a Python interpreter should be specified with a first element `"python"`.  This will enable generators for environments with specialized Python installations to be able to perform the action in an appropriate Python environment. Has access to `RULE_INPUT_` variables (see below). |
 | `message`   | string | A message to be displayed to the user by the build system when the action is run. Has access to `RULE_INPUT_` variables (see below). |
 
 There are several variables available to `outputs`, `action`, and `message`.
 
+|  *Variable*          | *Description*                       |
 |:---------------------|:------------------------------------|
 | `RULE_INPUT_PATH`    | The full path to the current input. |
 | `RULE_INPUT_DIRNAME` | The directory of the current input. |
 | `RULE_INPUT_NAME`    | The file name of the current input. |
 | `RULE_INPUT_ROOT`    | The file name of the current input without extension. |
 | `RULE_INPUT_EXT`     | The file name extension of the current input. |
 
 Rules can be thought of as Action generators. For each source selected
 by `extension` an special action is created. This action starts out with
 the same `inputs`, `outputs`, `action`, and `message` as the rule. The
 source is added to the action's `inputs`. The `outputs`, `action`, and
 `message` are then handled the same but with the additional variables.
 If the `_output` variable is used in the `action` or `message` the
 `RULE_INPUT_` variables in `output` will be expanded for the current
 source.
 
 ### Copies
 
 A `copies` section provides a simple means of copying files.  The
 `copies` section is organized as a list.  Each item in the list is a
 dictionary having the following form:
 
+| *Keyword*     | *Type* | *Description*                 |
 |:--------------|:-------|:------------------------------|
 | `destination` | string | The directory into which the `files` will be copied. |
 | `files`       | list   | A list of files to be copied. |
 
 The copies will be created in `destination` and have the same file name
 as the file they are copied from. Even if the `files` are from multiple
 directories they will all be copied into the `destination` directory.
 Each `destination` file has an implicit build dependency on the file it
 is copied from.
 
@@ skipping 83 matching lines @@
     * Target platform
     * V8 vs. JSC
     * Debug vs. Release
     * Toolchain (VS version, gcc, version)
     * Host platform
     * L10N
     * Vendor
     * Purify / Valgrind
   * Will everyone upgrade VS at once?
   * What does a dylib dependency mean?