Merge pull request gss#35 from oslego/fix-copy

paulyoung · paulyoung · commit 0c63757229a9 · 2015-08-07T11:33:17.000-07:00
Fix typos and clarify statements.
diff --git a/guides/_posts/2014-01-11-ifelse.html b/guides/_posts/2014-01-11-ifelse.html
@@ -6,20 +6,19 @@
 layout: post
 ---
 
-The age of "Responsive Web Design" is upon us and it's mandate for designs that elegantly adapt to the user's viewing context has made
+The age of "Responsive Web Design" is upon us and its mandate for designs that elegantly adapt to the user's viewing context has made
 web dev "hard, really hard, actually" as Mr Jeff Croft [lamented](http://jeffcroft.com/blog/2012/mar/02/implementing-responsive-design/).
 Conceptualizing Responsive layouts is difficult enough, but implementing such layouts with
 [CSS Media Queries](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries) is an awkward affair
-because as Ian Taylor [illuminated](http://ianstormtaylor.com/media-queries-are-a-hack/), Media Queries are a hack.
+because, as Ian Taylor [illuminated](http://ianstormtaylor.com/media-queries-are-a-hack/), Media Queries are a hack.
 
 ## Element Queries
 
 Media Queries allow layouts to adapt to the size of the viewport, but if you want to adapt to anything else, tough luck.
 W3C members have received an [onslaught](http://www.xanthir.com/b4PR0) of requests for "Element Queries" - because web designers
 are desperate to achieve higher levels of adaptiveness with their layouts.  The idea with Element Queries is simple - individual elements
 can be responsive to their own size, which would allow for richer designs & more modular Style Sheets. W3C have
-[start discussion](http://responsiveimagescg.github.io/eq-usecases/) about element queries but as this point they still don't have official
-endorsement of element queries.
+[started a discussion](http://responsiveimagescg.github.io/eq-usecases/) about element queries but at this point they still don't have official endorsement of element queries.
 
 Yet, even with the hypothetical Element Query, elements could only be adaptive to their size.  Why not allow elements to be adaptive to any property
 like `col-count` or even to a custom variable?
@@ -30,10 +29,10 @@
 much desired Element Query, that allow CSS rules to be adaptive to any arbitrary property or custom constraint variable.
 <a href="http://codepen.io/thegridgssdocs/pen/emEaQR" target="_blank">Live example.</a>
 
-Instead of continuing the tradition of the Query types; `min-width`, `max-width`, `min-height` & `max-height`; for every
+Instead of continuing the tradition of the Query types (`min-width`, `max-width`, `min-height` & `max-height`) for every
 available CSS property, `@if` `@else` directives use the conditional operators: `<`, `<=`, `>`, `>=`, `!=`, `==`, `or`, and `and`.
 
-As an example, if we wanted a set of CSS rules to kick when the screen is less than 960px:
+For example, if we want a set of CSS rules to kick-in when the viewport is narrower than 960px:
 
 {% highlight css %}
 
@@ -72,7 +71,7 @@
 constrained by the @if block, otherwise by the @else block.
 
 ### Constraint evaluation within conditionals
-In order to determine if a conditional holds, GSS needs to evaluate every constraints outside of the conditional before evaluating if it is met.
+In order to determine if a conditional holds, GSS needs to evaluate every constraint outside of the conditional before evaluating if it is met.
 This includes constraints appearing after the conditional's declaration.
 
 As explained in the [CCSS guide](/guides/ccss), the constraint declaration order can affect the
diff --git a/guides/_posts/2015-02-05-layout.html b/guides/_posts/2015-02-05-layout.html
@@ -9,7 +9,7 @@
 <a name="position"></a>
 ## Positioning
 
-Elements are positioned relative to the scope element, so its top left corner is considered a (0, 0) point. GSS initialized upon `document`, `<html>`, `<body>` or `<head>` position against the `<html>` element. Global properties like `$left`, `$right`, `$scroll-top` and `$bottom` point to respective properties of `::window`.
+Elements are positioned relative to the scope element, so its top-left corner is considered a (0, 0) point. GSS initialized upon `document`, `<html>`, `<body>` or `<head>` position against the `<html>` element. Global properties like `$left`, `$right`, `$scroll-top` and `$bottom` point to respective properties of `::window`.
 
 Cassowary is a general purpose solver, so it does not make any assumptions about the positioning or even geometry. If there's nothing that is bound to absolute values like zero or edges of the screen, the whole layout can be solved to be positioned off-screen. Negative `top` and `left` values is a common gotcha in *underconstrained* systems.
 
@@ -91,7 +91,7 @@
 {% endhighlight %}
 
 Position the `#someElm` top-left corner to be at 100px from the top-left of the page.
-Same thing for `#otherElm` excepts its the top-right corner that's been position 200px
+Same thing for `#otherElm` except it's the top-right corner that's been positioned 200px
 from the top-left of the page.
 
 ### bottom-left, bottom-right
@@ -102,7 +102,7 @@
 {% endhighlight %}
 
 Position the `#someElm` bottom-left corner to be at 100px from the top-left of the page.
-Same thing for `#otherElm`, excepts its the bottom-right corner that's been position 200px
+Same thing for `#otherElm`, except it's the bottom-right corner that's been positioned 200px
 from the top-left of the page.
 
 ### center-x, cx
@@ -118,7 +118,7 @@
 
 {% endhighlight %}
 
-Horizontally place the horizontal center of the element at 100px from the left of the page.
+Set the horizontal coordinate for the center of the element at 100px from the left of the page.
 
 ### center-y, cy
 
@@ -134,7 +134,7 @@
 
 {% endhighlight %}
 
-Place the vertical center of the element 100px from the top of the page.
+Set the vertical coordinate for center of the element at 100px from the top of the page.
 
 ### Center
 
@@ -188,11 +188,11 @@
 
 By employing CSS to lay out big chunks of layout, we make each section solution independent. This leads to smaller individual constraint graphs and better overall performance.
 
-With the `position: relative` declared in the `style` attribute, GSS will solve independently each sections which
-should results in better performance. <a href="http://codepen.io/thegridgssdocs/pen/pvwaNN" target="_blank">Live example.</a>
+With the `position: relative` declared in the `style` attribute, GSS will solve independently each section which
+should result in better performance. <a href="http://codepen.io/thegridgssdocs/pen/pvwaNN" target="_blank">Live example.</a>
 
 ## Dimensions
-GSS provides property to constrain the dimension of an element. We've already saw the `width` and `height`.
+GSS provides a property to constrain the dimension of an element. We already saw the `width` and `height` properties.
 GSS provides syntax sugar called 2d properties to constrain both height and width of an element as a single property.
 
 {% highlight css %}
@@ -205,34 +205,34 @@
 
 ## Intrinsic values
 
-Positioning elements with `top` and `left` properties doesn't require GSS to know the dimensions of that elements. But `right` and `bottom` properties need to know about `width` and `height` of the element respectively. Properly constrained system will provide those values indirectly with no regard to elements contents.
+Positioning elements with `top` and `left` properties doesn't require GSS to know the dimensions of those elements. But `right` and `bottom` properties need to know about `width` and `height` of the element respectively. Properly constrained systems will provide those values indirectly with no regard to an element's contents.
 
-However it's often desirable to know the computed dimensions of specific elements which GSS has no control over - be it text, images or blocks styled with CSS. Measurements provide dynamic "islands" to the layout, which can be automatically recomputed, whenever measured things are updated from the outside. It also may act as a feedback to the solver, disallowing content to shrink too much or helping to decide if things fit.
+However, it's often desirable to know the computed dimensions of specific elements which GSS has no control over - be it text, images or blocks styled with CSS. Measurements provide dynamic "islands" to the layout, which can be automatically recomputed, whenever measured things are updated from the outside. It also may act as a feedback to the solver, disallowing content to shrink too much or helping to decide if things fit.
 
-Prepending property with `intrinsic-` or `computed-` prefix makes GSS measure the values.
+Prefixing a property with `intrinsic-` or `computed-` prefix makes GSS measure the value.
 
-Using `intrinsic` property is used on the element, makes the property to be *read-only*. Declaration of `intrinsic-width` [propertywill ensure that `width` style is never applied to that element. This allows dimensions to change and update naturally. Otherwise, the width would be computed and applied only the first time, making it static.
+Prefixing a property with `intrinsic-` makes it *read-only* and it won't apply on the element. For example, declaring `intrinsic-width` will ensure that the `width` style is never applied to that element. This allows dimensions to change and update naturally. Otherwise, the width would be computed and applied only the first time, making it static.
 
-`computed` properties can be used to measure styles regardless of their origin - either GSS constraints or CSS styles. Computed properties will not make styles *read-only*, unlike intrinsic properties.
+`computed`-prefixed properties can be used to measure styles regardless of their origin - either GSS constraints or CSS styles. Computed properties will not make styles *read-only*, unlike `intrinsic`-prefixed properties.
 
 {% highlight css %}
 
-  // apply static width, measure height
-  // (height style will not be set)
-  .selectorA {
-    width: == 200;
-    height: == &intrinsic-height;
-  }
+// apply static width, measure height
+// (height style will not be set)
+.selectorA {
+  width: == 200;
+  height: == &intrinsic-height;
+}
 
-  // only measure dimensions
-  // (height & width styles will not be set)
-  .selectorB {
-    width: == &intrinsic-width;
-    height: == &intrinsic-height;
-  }
+// only measure dimensions
+// (height & width styles will not be set)
+.selectorB {
+  width: == &intrinsic-width;
+  height: == &intrinsic-height;
+}
 
-  // use dimension information to position elements
-  .selectorA[right] == .selectorB[left];
+// use dimension information to position elements
+.selectorA[right] == .selectorB[left];
 
 {% endhighlight %}
 
@@ -241,7 +241,7 @@
 
 Learn how to use [CCSS constraints](/guides/ccss)
 
-GSS provides conditionnal statements to allow you to do responsive design. Read our [@if @else guide](/guides/ifelse) to learn more.
+GSS provides conditional statements to allow you to do responsive design. Read our [@if @else guide](/guides/ifelse) to learn more.
 
 With only CCSS constraints at your disposal, constraining common layout scenarios quickly becomes tedious. Read our
 [VFL guide](/guides/ifelse) to learn how to more efficiently constrain your layout.
