Permalink
Browse files

Formatting in modules specification.

  • Loading branch information...
1 parent 56f7f62 commit 918895313089501ad018eb516f19151efe32c21d @kriskowal committed May 10, 2012
Showing with 9 additions and 10 deletions.
  1. +9 −10 modules/specification.md
View
19 modules/specification.md
@@ -1,4 +1,3 @@
-
This specification establishes a convention for creating a style of
reusable JavaScript modules and systems that will load and link those
modules.
@@ -24,53 +23,53 @@ satisfy in order to function in any module system.
``exports``, and ``module`` in addition to the globals provided by
JavaScript.
- - *Depending on any other values limits portability to engines
+ 1. *Depending on any other values limits portability to engines
that do not provide those values and will cause reference errors
on those systems.*
1. A module must consider that every object in its scope may be
immutable.
- - *Depending on the mutability of an object precludes the use of
+ 1. *Depending on the mutability of an object precludes the use of
the module in a system that shares its global scope among
mutually suspcious programs, like between mashups in a secured
JavaScript context.*
- - *It may be acceptable to upgrade an object in scope (shim) if it
+ 1. *It may be acceptable to upgrade an object in scope (shim) if it
does not provide the needed, specified behavior, but this will
limit portability to secure contexts with legacy
implementations.*
1. A module must only depend on the specified behavior of values in
scope.
- - *Depending on any extension to the specified behavior limits
+ 1. *Depending on any extension to the specified behavior limits
portability.*
1. All calls to ``require`` must be given a single string literal as
the argument, or the value of ``require.main`` if it is defined.
- - *If the argument to ``require`` is not a string, the dependency
+ 1. *If the argument to ``require`` is not a string, the dependency
cannot be discovered and asynchronously loaded before executing
the module. This would limit portability to systems that read
the text of a module to discover dependencies and load them
asynchronously before execution, which is necessary for
portability to browsers and other systems that only support
asynchronous loading.*
- - *``require.main`` is guaranteed to already have been loaded, so
+ 1. *``require.main`` is guaranteed to already have been loaded, so
it is a reasonable exception to the rule that all dependencies
must be discoverable without executing the module.*
1. All calls to ``require`` must be by the name ``require``.
- - *If ``require`` takes on a different name, the dependency will
+ 1. *If ``require`` takes on a different name, the dependency will
not be discoverable without executing the module.*
1. All calls to ``require`` must be given a module identifier as the
argument.
- - *Some module loaders may accept values that are not module
+ 1. *Some module loaders may accept values that are not module
identifiers. Depending on this behavior inside a module limits
the portability of the module, particularly to systems that use
packages to isolate the module identifier name space for a set
@@ -82,7 +81,7 @@ Guarantees Made by Module Interpreters
1. The top scope of a module must not be shared with any other module.
- - *All ``var`` declarations in a module will only be accessible
+ 1. *All ``var`` declarations in a module will only be accessible
within that module and will not collide with declarations in
other modules*

0 comments on commit 9188953

Please sign in to comment.