Doc update.

foxxtrot · Nov 2, 2011 · 553ee03 · 553ee03
1 parent bf1d393
commit 553ee03
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/docs/history.html b/docs/history.html
@@ -15,7 +15,7 @@ <h1>RequireJS History</h1>
 
 <p>In the process of implementing the transport format, it became clearer that CommonJS modules allowed an imperative require() usage, which is awkward on the web. Many cases would not work in a web context, and a better solution was to allow for a callback-based require for those cases. However, some of the participants on the CommonJS list wanted to keep the imperative use even in a callback-style require, which made that API more wordy than it should have been.</p>
 
-<p>There was some tuning of the Transport/C proposal, and Kris Zyp felt like it actually felt more like a module API proposal instead of just a transport format, and he created a proposal on the CommonJS wiki for an Asynchronous Module Definition (AMD) API. During the discussion of that API, Tom Robinson suggested the use of Function.prototype.toString() to scan a factory function for dependencies, although Tom did not care for the AMD API in general. The toString() scanning was incorporated in the AMD API as a simplified CommonJS wrapping, since not all JS environments supported usable toString() values.</p>
+<p>There was some tuning of the Transport/C proposal, and Kris Zyp figured out how to get anonymous modules to work within that format. At that point, Kris felt like it could function as a module API proposal instead of just a transport format, and he created a proposal on the CommonJS wiki for an Asynchronous Module Definition (AMD) API. During the discussion of that API, Tom Robinson suggested the use of Function.prototype.toString() to scan a factory function for dependencies, although Tom did not care for the AMD API in general. The toString() scanning was incorporated in the AMD API as a simplified CommonJS wrapping, since not all JS environments supported usable toString() values.</p>
 
 <p>Some participants on the CommonJS list that felt the AMD API proposal was not in line with the original CommonJS module goals and since it did not keep the full imperative require() style in CommonJS modules. They also felt that proposal was sprung on the list and implemented and evangelized improperly, although from my perspective it was marked as a proposal, and there were other people talking about their implementations of other CommonJS proposals.</p>