Light edits to docs/topics/forms/index.txt

1 files changed, 12 insertions, 12 deletions

diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index 360eced0fa..8133478e82 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -27,10 +27,10 @@ objects or controls, and so on, and then send that information back to the
 server.
 
 Some of these form interface elements - text input or checkboxes - are fairly
-simple and built-in to HTML itself. Others are much more complex; an interface
-that pops up a date picker or allows you to move a slider or manipulate
-controls will typically use JavaScript and CSS as well as HTML form ``<input>``
-elements to achieve these effects.
+simple and are built into HTML itself. Others are much more complex; an
+interface that pops up a date picker or allows you to move a slider or
+manipulate controls will typically use JavaScript and CSS as well as HTML form
+``<input>`` elements to achieve these effects.
 
 As well as its ``<input>`` elements, a form must specify two things:
 
@@ -59,8 +59,8 @@ data is returned to ``/admin/``.
 ``GET`` and ``POST`` are the only HTTP methods to use when dealing with forms.
 
 Django's login form is returned using the ``POST`` method, in which the browser
-bundles up the form data, encodes it for transmission, sends it back to the
-server, and then receives its response.
+bundles up the form data, encodes it for transmission, sends it to the server,
+and then receives back its response.
 
 ``GET``, by contrast, bundles the submitted data into a string, and uses this
 to compose a URL. The URL contains the address where the data must be sent, as
@@ -102,7 +102,7 @@ do in code they wrote themselves.
 
 Django handles three distinct parts of the work involved in forms:
 
-* preparing and restructuring data ready for rendering
+* preparing and restructuring data to make it ready for rendering
 * creating HTML forms for the data
 * receiving and processing submitted forms and data from the client
 
@@ -138,7 +138,7 @@ validation when a form is submitted. A :class:`DateField` and a
 :class:`FileField` handle very different kinds of data and have to do
 different things with it.
 
-A form field is represented to a user in the browser as a HTML "widget" - a
+A form field is represented to a user in the browser as an HTML "widget" - a
 piece of user interface machinery. Each field type has an appropriate default
 :doc:`Widget class </ref/forms/widgets/>`, but these can be overridden as
 required.
@@ -156,7 +156,7 @@ Rendering a form in a template involves nearly the same work as rendering any
 other kind of object, but there are some key differences.
 
 In the case of a model instance that contained no data, it would rarely if ever
-be useful to do anything with one in a template. On the other hand, it makes
+be useful to do anything with it in a template. On the other hand, it makes
 perfect sense to render an unpopulated form - that's what we do when we want
 the user to populate it.
 
@@ -364,8 +364,8 @@ by a view, and rendered as an HTML ``<form>``.
 
 That's all you need to get started, but the forms framework puts a lot more at
 your fingertips. Once you understand the basics of the process described above,
-you should be aware of what else is readily available in the forms system
-and know a little bit about some of the underlying machinery.
+you should be prepared to understand other features of the forms system and
+ready to learn a bit more about the underlying machinery.
 
 More about Django :class:`Form` classes
 =======================================
@@ -560,7 +560,7 @@ in a Django template, will be rendered appropriately. For example:
         {{ form.cc_myself }}
     </div>
 
-Complete ``<label>`` element can also be generated using the
+Complete ``<label>`` elements can also be generated using the
 :meth:`~django.forms.BoundField.label_tag`. For example:
 
 .. code-block:: html+django