wording fixes

_layouts/default.html

@@ -73,7 +73,7 @@ <h1><a href="/">Joosy Guides</a></h1>
                   <dd><a href="/guides/advanced/permissions.html">Permissions and ACL</a></dd>
                   <dd><a href="/guides/advanced/template-engine.html">Template engines</a></dd>
                 </dl>
-              </div>      
+              </div>
             </li> 
             <li><a href="/contribute.html">Contribute</a></li>
             <li><a href="/credits.html">Credits</a></li>

credits.html

@@ -5,31 +5,31 @@
 
 <div class="entry-content" id="container">
   <div class="wrapper">
-	<div id="mainCol">
+  <div id="mainCol">
     <h3 class="section">Joosy Authors</h3>
-		<div class="module">
-			<img height="91" width="91" src="http://www.gravatar.com/avatar/7c4ac3f00d81fbb8ba329163b3dc6b2a.png?size=91" class="left pic" alt="Boris Staal">
-			<div class="right">
-				<h3>Boris Staal</h3>
-				<p>
+    <div class="module">
+      <img height="91" width="91" src="http://www.gravatar.com/avatar/7c4ac3f00d81fbb8ba329163b3dc6b2a.png?size=91" class="left pic" alt="Boris Staal">
+      <div class="right">
+        <h3>Boris Staal</h3>
+        <p>
           Ruby-world open-source enthusiast working as an evangelist at <a href="http://www.roundlake.ru">Round Lake</a>. Author of several wide-known gems, contributor to several known Node.js packages like <a href="http://netzpirat.github.com/codo/">Codo</a>. Shares strange thoughts at <a href="http://borisstaal.com/">his Tumblr blog</a>.
         </p>
-			</div>
-		</div>
-		<div class="module">
-			<img height="91" width="91" src="img/photo.gif" class="left pic" alt="Andrew Shaydurov">
-			<div class="right">
+      </div>
+    </div>
+    <div class="module">
+      <img height="91" width="91" src="img/photo.gif" class="left pic" alt="Andrew Shaydurov">
+      <div class="right">
         <h3>Andrew Shaydurov</h3>
         <p>Ruby fan, CoffeeScript lover. CTO of the MainPeople network. Addicted to start-ups, commercials, web-interfaces and playing piano.</p>
-			</div>
-		</div>
-		<div class="module">
-			<img height="91" width="91" src="http://www.gravatar.com/avatar/0dd4414dec1137cde9a69f41090c6735.png?size=91" class="left pic" alt="Alexander Pavlenko">
-			<div class="right">
+      </div>
+    </div>
+    <div class="module">
+      <img height="91" width="91" src="http://www.gravatar.com/avatar/0dd4414dec1137cde9a69f41090c6735.png?size=91" class="left pic" alt="Alexander Pavlenko">
+      <div class="right">
         <h3>Alexander Pavlenko</h3>
         <p>Impressive description goes here.</p>
-			</div>
-		</div>
+      </div>
+    </div>
     <h3 class="section">Guides Designers</h3>
     <div class="module">
       <img height="91" width="91" src="img/photo.gif" class="left pic" alt="Heiko Webers">
@@ -38,5 +38,5 @@ <h3><a href="http://guides.rubyonrails.org/credits.html">Rails guides contributo
         <p>Design was shamelessly copied from original Rails guides. Credit and a deep bow goes to original authors.</p>
       </div>
     </div>
-	</div>
-</div>
+  </div>
+</div>

guides/basics/getting-started.md

@@ -11,7 +11,7 @@ Here is the typical transport flow for the Rails web application:
 
 ![Typical](http://f.cl.ly/items/322w1b1j2y2X0C212O1U/typical.png)
 
-Joosy moves the HTML rendering, events handling and everything that is connected to the views right into your browser. During preloading, Joosy gets all the templates from the server and uses Rails backend as a REST data provider. And your application looks like this:
+Joosy moves HTML rendering, event handling and everything that is connected to the views right to your browser. During preloading, Joosy gets all the templates from the server and uses Rails backend as a REST data provider. And your application looks like this:
 
 ![Joosy](http://f.cl.ly/items/0k3f1W2p1H0B1j0r231Z/joosy.png)
 
@@ -35,7 +35,7 @@ And last but no the least: viva la [HAML](http://haml.info/)! Joosy uses templat
 
 ### Not am MVC? But...
 
-The idea is simple. REST in not an SQL. Application Server is not an RDBMS. You can't have real logic inside your models. Therefore you don't have models. Inside your browser you don't need to be linked to REST structure since your only goal is an interaction with user. That's why you don't need controllers. Joosy operates with View terms. It has pages, layouts and widgets. Each of them works with templates, resources (doh... models) and forms. That's pretty much it, the typical separation for the View part.
+The idea is simple. REST in not SQL. Application Server is not an RDBMS. You can't have real logic inside your models. Therefore you don't have models. Inside your browser you don't need to be linked to REST structure since your only goal is the interaction with user. That's why you don't need controllers. Joosy operates with View terms. It has pages, layouts and widgets. Each of them works with templates, resources (doh... models) and forms. That's pretty much it, the typical separation for the View part.
 
 ![Scheme](http://cl.ly/1M470v24220L2e080h1L/scheme.png)
 
@@ -60,7 +60,7 @@ To send data back Joosy has a `Form`. It wraps your basic HTML form and turns it
 
 ### Okay, it's like Rails. Anything else?
 
-Unlike Rails server application it has a state. For example if you use the only `Layout` for every page it will never get reloaded. Unlike the data it holds. To ease the DOM updates Joosy has `dynamic rendering` feature. It allows you to bind your resource to a template to automatically update DOM whenever resource changes. No manual events handling and rerendering. You just call `@renderDynamic` for a partial and it always stays actual.
+Unlike Rails server application it has the state. For example if you use the only `Layout` for every page it will never get reloaded. Unlike the data it holds. To ease the DOM updates Joosy has `dynamic rendering` feature. It allows you to bind your resource to a template to automatically update DOM whenever resource changes. No manual events handling and rerendering. You just call `@renderDynamic` for a partial and it always stays actual.
 
 {% assign gist_file = 'Partial Sample.haml' %}
 {% include gist.html %}

guides/basics/joosy-vs-x.md

@@ -5,11 +5,11 @@ title: "Joosy vs X"
 
 ### How is Joosy different from X
 
-Joosy was created to be the foundation of a large browser applications. Since large applications are always tightly bound to a server implementation Joosy is not trying to achieve abstraction and independency. It uses Rails as an Application Server and lives among Views terms.
+Joosy was created to be the foundation of the large browser applications. Since large applications are always tightly bound to the server implementation, Joosy is not trying to achieve abstraction and independency. It uses Rails as the Application Server and lives among Views terms.
 
 Talking about an MVC paradigm, Joosy is a View part while Controllers and Models are still in Rails. The great description of Joosy paradigm can be met at [Getting Started](/guides/basics/getting-started.html) guide. Please read it before passing on to direct comparison parts so you are sure to understand it correctly.
 
-The another thing we inherit from Rails is a passion to have a nice set of ready conventions to solve common problems you meet day to day. Real-life orientation is a great Joosy feature. Most of conventions are shamelessly copied from Rails to ease adaptation and cooperation.
+The another thing we inherit from Rails is a passion to have a nice set of ready conventions to solve common problems you meet from day to day. Real-life orientation is a great Joosy feature. Most of conventions are shamelessly copied from Rails to ease adaptation and cooperation.
 
 ### Highlights comparison
 
@@ -113,8 +113,9 @@ The another thing we inherit from Rails is a passion to have a nice set of ready
 </table>
 <br /><br />
 
-Bundled means:
+Bundled size is the size of the framework and related assets and
+libraries:
 
 * **Backbone**: jQuery
 * **Ember.js**: jQuery
-* **Joosy**: jQuery, Sugar.js
+* **Joosy**: jQuery, Sugar.js

guides/blog/dynamic-rendering.md

@@ -5,7 +5,7 @@ title: "Dynamic rendering"
 
 {% assign gist_id = 2827878 %}
 
-During this chapter we'll implement inline post title edit. It will be available at `post/show` page. As you click on the title it gets replaced with the inline form. After that the submit title shows up again, but with the new value.
+During this chapter we'll implement inline post title editing. It will be available at `post/show` page. As you click on the title it gets replaced with the inline form. After that the submit title shows up again, but with the new value.
 
 ## Templates and partials scopes
 
@@ -41,4 +41,4 @@ Everything else should be quite familiar if you did read the previous guides. Th
 
 Note the Line 14. As soon as server responds successfully, we modify the resource and it immediately gets updated at DOM.
 
-And now that our inline editor is ready why not copy that to index page? To keep code clean and avoid duplication <a href="/guides/blog/widgets.html">the next chapter</a> will describe the clear way to achieve this using Widgets.
+And now that our inline editor is ready why not copy that to index page? To keep code clean and avoid duplication <a href="/guides/blog/widgets.html">the next chapter</a> will describe the clear way to achieve this using Widgets.

guides/blog/elements-events-and-filters.md

@@ -48,4 +48,4 @@ Together with `afterLoad` Joosy gives you the `beforeLoad` hook. Within beforeLo
 
 Both `afterLoad` and `beforeLoad` can be chained. They will be called in exact order you define those among your container. Moreover, if you use classes inheritance, Joosy will call parents hooks. The order is still under controll. Joosy will start from the upper parent and step down towards children.
 
-The <a href="/guides/blog/forms.html">next chapter</a> is all about forms. We will finally come up with the way to create and edit blog posts.
+The <a href="/guides/blog/forms.html">next chapter</a> is all about forms. We will finally come up with the way to create and edit blog posts.

guides/blog/forms.md

@@ -64,7 +64,7 @@ And you can go check your forms again. Invalidated fields will get it's class an
 
 <div class="warning">
   <p>
-    Forms is one of the most important parts of Joosy. You really should finish reading this chapter sooner or later. We won't need more info about forms for the whole blog guide though. But you realy should come back later even if decide to pass on to a <a href="/guides/blog/dynamic-rendering.html">Dynamic rendering</a> chapter.
+    Forms are one of the most important parts of Joosy. You really should finish reading this chapter sooner or later. We won't need more info about forms for the whole blog guide though. But you realy should come back later even if decide to pass on to a <a href="/guides/blog/dynamic-rendering.html">Dynamic rendering</a> chapter.
   </p>
 </div>
 
@@ -95,7 +95,7 @@ For the basic form (no resource) invalidation convention is something really eas
 
 As soon as your form is "attached" you can fill it with the Resource. Do it with `form.fill(resource)` call. In fact passing the `resource` parameter to attach is a shortcut to `fill`. Resource will modify form's behavior slightly.
 
-At firt this will try to fill the form with the actual fields values. Joosy will seek the fields by input names. According to Rails conventions you are supposed to call them `model[field]`. Same rule is applied to Joosy. Earlier in this guide we've already seen this convention at our edit form.
+At first this will try to fill the form with the actual fields values. Joosy will seek the fields by input names. According to Rails conventions you are supposed to call them `model[field]`. Same rule applies to Joosy. Earlier in this guide we've already seen this convention at our edit form.
 
 At second it will properly modify the action and method of form. If the given resource was new, it gets targeted to POST /models. Otherwise it gets targeted to PUT /models/:id. So you just bind your resource, no matter new or existing and form just works.
 

guides/blog/helpers.md

@@ -21,14 +21,14 @@ This section defines three useful helpers:
 {% assign gist_file = 'Wrapped.haml' %}
 {% include gist.html %}
 
-Being a indentation-dependent syntax, HAML has a weak part: wrapping. You can easily insert inline part of code as a partial but opposite turns into a hell. This helper was meant to solve the problem. The partial you render will get the same context as the current template. The content given to the helper as the second parameter will be put at `@yield` variable inside wrapping partial.
+Being an indentation-dependent syntax, HAML has a weak part: wrapping. You can easily insert inline part of code as a partial but opposite turns into a hell. This helper was meant to solve the problem. The partial you render will get the same context as the current template. The content given to the helper as the second parameter will be put at `@yield` variable inside wrapping partial.
 
 #### Nl2Br
 
 {% assign gist_file = 'Nl2br.haml' %}
 {% include gist.html %}
 
-Simple replaces all the newlines with the `<br />` tag.
+Simply replaces all the newlines with the `<br />` tag.
 
 ## Forms
 
@@ -69,4 +69,4 @@ To include this namespace to our widget use this string inside your widget class
 
 Yarr! Now you are officially an encapsulated pirate!
 
-Most of our blog work is complete. As it was mentioned from the start Joosy has set of preloading strategies bundled. Now is the time to ensure our app loads properly with the [next chapter](/guides/blog/preloaders.html).
+Most of our blog work is complete. As it was mentioned from the start Joosy has set of preloading strategies bundled. Now is the time to ensure our app loads properly with the [next chapter](/guides/blog/preloaders.html).

guides/blog/layouts-pages-and-routing.md

@@ -13,7 +13,7 @@ Joosy behaves the same way but unlike elder brother it has to deal with events a
 
 <div class="info">
   <p>
-    Joosy tries to keep logic elements alive as long as possible. When the new page gets loaded, current layout (object instance, bindings, DOM, included widgets, etc.) will stay untouched unless new pages requires another layout. In this case Page will be linked to an existing instance.
+    Joosy tries to keep logic elements alive as long as possible. When the new page gets loaded, current layout (object instance, bindings, DOM, included widgets, etc.) will stay untouched unless new pages require another layout. In this case Page will be linked to an existing instance.
   </p>
 </div>
 
@@ -35,7 +35,7 @@ Take a look at the last tricky line. Using `{:id => @yield()}` we mark the `.con
 
 <div class="info">
   <p>
-    This may look like a silly name cause it clearly is not an `yield` in it's real meaning. But wait! Listen! We had a reason to use this name. It helps you to not remember another `longMethodToCall`. It mimics Rails in the closest possible way. 
+    This may look like a silly name 'cause it clearly is not an `yield` in it's real meaning. But wait! Listen! We had a reason to use this name. It helps you to not remember another `longMethodToCall`. It mimics Rails in the closest possible way. 
   </p>
 </div>
 

guides/blog/preloaders.md

@@ -11,7 +11,7 @@ RICH applications that we create with Joosy can weight a lot. While 200KB look n
 
 This preloader will use localStorage of client browser to manually load and save all the assets. This will guarantee stable cache and proper reloading. Beware though: client browser is supposed to support the localStorage feature. Shims are not doing very well here since for the elder browsers the amount of available storage is often not enough. Remember that 200k is your gziped value while it saves the unarchived JS inside localStorage.
 
-The practice shows however that even extremely large application always fit under 1Mb of minified JS. Which is far away from basicly available 5Mb limit.
+The practice shows, however, that even extremely large application always fit under 1Mb of minified JS. Which is far away from basicly available 5Mb limit.
 
 ## Inline
 

index.md

@@ -11,7 +11,7 @@ Joosy allows you to create web apps which work completely in the browser. So tha
 
 Besides Rails, Joosy is based on top of [CoffeeScript](http://coffeescript.org/), [jQuery](http://jquery.com/) and [Sugar.js](http://sugarjs.com/) in role of ActiveSupport.
 
-Finally, Joosy boosts your development drastically. Just like the Rails do.
+Finally, Joosy boosts your development drastically. Just like Rails does.
 
 ## Joosy basics
 
@@ -32,11 +32,11 @@ Finally, Joosy boosts your development drastically. Just like the Rails do.
 * ### [Resources](guides/blog/resources.html)
 
   Resources are your models data representations. Before we get to the application itself, we'll learn how to fetch
-  the backend and manage the data after you received it.
+  from the backend and manage the data after you received it.
 
 * ### [Layouts, pages and routing](guides/blog/layouts-pages-and-routing.html)
 
-  In this chapter we'll create basic blog pages with layouts and learn how routing in Joosy works. We'll either learn how to load basic data from server during page load.
+  In this chapter we'll create basic blog pages with layouts and learn how routing in Joosy works. We'll alse learn how to load basic data from server during page load.
 
 * ### [Elements, events and filters](guides/blog/elements-events-and-filters.html)
 
@@ -82,4 +82,4 @@ Finally, Joosy boosts your development drastically. Just like the Rails do.
 
 * ### [How to switch template engine](guides/advanced/how-to-switch-template-engine.html)
 
-  <span style="color:red">In progress.</span>
+  <span style="color:red">In progress.</span>