fix improperly spaced markdown blocks and typos (for formatting on we…

…bsite (WebAssembly#837)

BinaryEncoding.md

@@ -71,21 +71,25 @@ Note: Gaps are reserved for future extensions. The use of a signed scheme is so
 
 ### `value_type`
 A `varint7` indicating a [value type](Semantics.md#types). One of:
+
 * `i32`
 * `i64`
 * `f32`
 * `f64`
+
 as encoded above.
 
 ### `block_type`
 A `varint7` indicating a block signature. These types are encoded as:
+
 * either a [`value_type`](#value_type) indicating a signature with a single result
 * or `-0x40` (i.e., the byte `0x40`) indicating a signature with 0 results.
 
 ### `elem_type`
 
 A `varint7` indicating the types of elements in a [table](AstSemantics.md#table).
 In the MVP, only one type is available:
+
 * [`anyfunc`](AstSemantics.md#table)
 
 Note: In the future, other element types may be allowed.
@@ -130,6 +134,7 @@ The description of a memory.
 
 ### `external_kind`
 A single-byte unsigned integer indicating the kind of definition being imported or defined:
+
 * `0` indicating a `Function` [import](Modules.md#imports) or [definition](Modules.md#function-and-code-sections)
 * `1` indicating a `Table` [import](Modules.md#imports) or [definition](Modules.md#table-section)
 * `2` indicating a `Memory` [import](Modules.md#imports) or [definition](Modules.md#linear-memory-section)
@@ -228,6 +233,7 @@ The import section declares all imports that will be used in the module.
 | entries | `import_entry*` | repeated import entries as described below |
 
 #### Import entry
+
 | Field | Type | Description |
 | ----- | ---- | ----------- |
 | module_len | `varuint32` | module string length |
@@ -330,6 +336,7 @@ The encoding of the [Export section](Modules.md#exports):
 | entries | `export_entry*` | repeated export entries as described below |
 
 #### Export entry
+
 | Field | Type | Description |
 | ----- | ---- | ----------- |
 | field_len | `varuint32` | field name string length |

DynamicLinking.md

@@ -20,6 +20,7 @@ achieved by having module A export functions, tables and memories that are
 imported by B. A C++ toolchain can expose this functionality by using the
 same function attributes currently used to export/import symbols from
 native DSOs/DLLs:
+
 ```
 #ifdef _WIN32
 #  define EXPORT __declspec(dllexport)
@@ -34,15 +35,19 @@ typedef void (**PF)();
 IMPORT PF imp();
 EXPORT void exp() { (*imp())(); }
 ```
+
 This code would, at a minimum, generate a WebAssembly module with imports for:
+
 * the function `imp`
 * the heap used to perfom the load, when dereferencing the return value of `imp`
 * the table used to perform the pointer-to-function call
 
 and exports for:
+
 * the function `exp`
 
 A more realistic module using libc would have more imports including:
+
 * an immutable `i32` global import for the offset in linear memory to place
   global [data segments](Modules.md#data-section) and later use as a constant
   base address when loading and storing from globals
@@ -57,6 +62,7 @@ toolchain to put implementation-internal names in a separate namespace, avoiding
 the need for `__`-prefix conventions).
 
 To implement run-time dynamic linking (e.g., `dlopen` and `dlsym`):
+
 * `dlopen` would compile and instantiate a new module, storing the compiled
   instance in a host-environment table, returning the index to the caller.
 * `dlsym` would be given this index, pull the instance out of the table,

Events.md

@@ -1,4 +1,4 @@
-## Past
+## Past Events
 
 | Date | Title | Slides | Video | Presenter(s) |
 |-----:|-------|:------:|:-----:|--------------|

FeatureTest.md

@@ -13,12 +13,14 @@ like.
 Since some WebAssembly features add operators and all WebAssembly code in a
 module is validated ahead-of-time, the usual JavaScript feature detection
 pattern:
+
 ```
 if (foo)
     foo();
 else
     alternativeToFoo();
 ```
+
 won't work in WebAssembly (if `foo` isn't supported, `foo()` will fail to
 validate).
 
@@ -68,6 +70,7 @@ that one function was an optimized, but feature-dependent, version of another
 function (similar to the
 [`ifunc` attribute](https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#index-g_t_0040code_007bifunc_007d-attribute-2529),
 but without the callback):
+
 ```
 #include <xmmintrin.h>
 void foo(...) {
@@ -85,6 +88,7 @@ void foo_f64x2(...) __attribute__((optimizes("foo","f64x2"))) {
 ...
 foo(...);                 // calls either foo or foo_f64x2
 ```
+
 In this example, the toolchain could emit both `foo` and `foo_f64x2` as
 function definitions in the "specific layer" binary format. The load-time
 polyfill would then replace `foo` with `foo_f64x2` if

FutureFeatures.md

@@ -1,4 +1,4 @@
-# Feature to add after the MVP
+# Features to add after the MVP
 
 These are features that make sense in the context of the
 [high-level goals](HighLevelGoals.md) of WebAssembly but are not considered part
@@ -14,6 +14,7 @@ This is covered in the [tooling](Tooling.md) section.
 ## Finer-grained control over memory
 
 Provide access to safe OS-provided functionality including:
+
 * `map_file(addr, length, Blob, file-offset)`: semantically, this operator
    copies the specified range from `Blob` into the range `[addr, addr+length)`
    (where `addr+length <= memory_size`) but implementations are encouraged
@@ -51,19 +52,21 @@ can allocate noncontiguous virtual address ranges. See the
 
 Some platforms offer support for memory pages as large as 16GiB, which 
 can improve  the efficiency of memory management in some situations. WebAssembly
-may offer programs the option to specify a larger page size than the [default] (Semantics.md#resizing).
+may offer programs the option to specify a larger page size than the [default](Semantics.md#resizing).
 
 ## More expressive control flow
 
 Some types of control flow (especially irreducible and indirect) cannot be
 expressed with maximum efficiency in WebAssembly without patterned output by the
 relooper and [jump-threading](https://en.wikipedia.org/wiki/Jump_threading)
 optimizations in the engine. Target uses for more expressive control flow are:
+
 * Language interpreters, which often use computed-`goto`.
 * Functional language support, where guaranteed tail call optimization is
   expected for correctness and performance.
 
 Options under consideration:
+
 * No action, `while` and `switch` combined with jump-threading are enough.
 * Just add `goto` (direct and indirect).
 * Add new control-flow primitives that address common patterns.
@@ -403,6 +406,7 @@ can begin.
 
 There are two future features that would allow streaming compilation
 of WebAssembly in browsers:
+
 * [ES6 Module integration](Modules.md#integration-with-es6-modules) would allow
   the browser's network layer to feed a stream directly into the engine.
 * The asynchronous [`WebAssembly.compile`](JS.md#wasmcompile) function could be 
@@ -444,6 +448,7 @@ it was possible to write a WebAssembly dynamic loader in WebAssembly. As a
 prerequisite, WebAssembly would need first-class support for 
 [GC references](GC.md) on the stack and in locals. Given that, the following
 could be added:
+
 * `get_table`/`set_table`: get or set the table element at a given dynamic
   index; the got/set value would have a GC reference type
 * `grow_table`: grow the current table (up to the optional maximum), similar to
@@ -453,6 +458,7 @@ could be added:
 Additionally, in the MVP, the only allowed element type of tables is a generic
 "anyfunc" type which simply means the element can be called but there is no
 static signature validation check. This could be improved by allowing:
+
 * functions with a particular signature, allowing wasm generators to use
   multiple homogeneously-typed function tables (instead of a single
   heterogeneous function table) which eliminates the implied dynamic signature

GC.md

@@ -3,6 +3,7 @@
 After the [MVP](MVP.md), to realize the [high-level goals](HighLevelGoals.md)
 of (1) integrating well with the existing Web platform and (2) supporting
 languages other than C++, WebAssembly needs to be able to:
+
 * reference DOM and other Web API objects directly from WebAssembly code;
 * call Web APIs (passing primitives or DOM/GC/Web API objects) directly from
   WebAssembly without calling through JavaScript; and
@@ -59,6 +60,7 @@ in a Web environment.
 Using [opaque reference types](GC.md#opaque-reference-types),
 JavaScript values could be made accessible to WebAssembly code through a builtin
 `js` module providing:
+
 * an exported `string` opaque reference type and exported functions
   to allocate, query length, and index `string` values;
 * an exported `object` opaque reference type and exported functions
@@ -81,6 +83,7 @@ Using [opaque reference types](GC.md#opaque-reference-types), it would be
 possible to allow direct access to DOM and Web APIs by mapping their
 [WebIDL](http://www.w3.org/TR/WebIDL) interfaces to WebAssembly builtin module 
 signatures. In particular:
+
 * WebIDL interfaces (like 
   [WebGLRenderingContextBase](https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.14)
   or [WebGLTexture](https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.9))
@@ -110,6 +113,7 @@ would effectively be skipped.
 
 Another important issue is mapping WebIDL values types that aren't simple
 [primitive types](http://www.w3.org/TR/WebIDL/#dfn-primitive-type):
+
 * [Dictionary types](http://www.w3.org/TR/WebIDL/#idl-dictionary)
   would [appear](http://www.w3.org/TR/WebIDL/#es-dictionary) to require
   JavaScript objects but are actually defined as values such that they can
@@ -144,6 +148,7 @@ direct GC allocation and field access from WebAssembly code through
 
 There is a lot of the design left to
 consider for this feature, but a few points of tentative agreement are:
+
 * To avoid baking in a single language's object model, define low-level GC
   primitives (viz., structs and arrays) and allow the source language compiler
   to build up features like virtual dispatch and access control.