Indent blockquotes in markdown guides

This is required to make sure all code blocks have proper syntax highlighting

Author: Jaden Dessureault

Diff for: css-in-javascript/README.md

@@ -14,7 +14,7 @@
 
   - Use camelCase for object keys (i.e. "selectors").
 
-  > Why? We access these keys as properties on the `styles` object in the component, so it is most convenient to use camelCase.
+    > Why? We access these keys as properties on the `styles` object in the component, so it is most convenient to use camelCase.
 
     ```js
     // bad
@@ -34,7 +34,7 @@
 
   - Use an underscore for modifiers to other styles.
 
-  > Why? Similar to BEM, this naming convention makes it clear that the styles are intended to modify the element preceded by the underscore. Underscores do not need to be quoted, so they are preferred over other characters, such as dashes.
+    > Why? Similar to BEM, this naming convention makes it clear that the styles are intended to modify the element preceded by the underscore. Underscores do not need to be quoted, so they are preferred over other characters, such as dashes.
 
     ```js
     // bad
@@ -64,7 +64,7 @@
 
   - Use `selectorName_fallback` for sets of fallback styles.
 
-  > Why? Similar to modifiers, keeping the naming consistent helps reveal the relationship of these styles to the styles that override them in more adequate browsers.
+    > Why? Similar to modifiers, keeping the naming consistent helps reveal the relationship of these styles to the styles that override them in more adequate browsers.
 
     ```js
     // bad
@@ -92,7 +92,7 @@
 
   - Use a separate selector for sets of fallback styles.
 
-  > Why? Keeping fallback styles contained in a separate object clarifies their purpose, which improves readability.
+    > Why? Keeping fallback styles contained in a separate object clarifies their purpose, which improves readability.
 
     ```js
     // bad
@@ -133,7 +133,7 @@
 
   - Use device-agnostic names (e.g. "small", "medium", and "large") to name media query breakpoints.
 
-  > Why? Commonly used names like "phone", "tablet", and "desktop" do not match the characteristics of the devices in the real world. Using these names sets the wrong expectations.
+    > Why? Commonly used names like "phone", "tablet", and "desktop" do not match the characteristics of the devices in the real world. Using these names sets the wrong expectations.
 
     ```js
     // bad
@@ -155,7 +155,7 @@
 
   - Define styles after the component.
 
-  > Why? We use a higher-order component to theme our styles, which is naturally used after the component definition. Passing the styles object directly to this function reduces indirection.
+    > Why? We use a higher-order component to theme our styles, which is naturally used after the component definition. Passing the styles object directly to this function reduces indirection.
 
     ```jsx
     // bad
@@ -198,7 +198,7 @@
 
   - Leave a blank line between adjacent blocks at the same indentation level.
 
-  > Why? The whitespace improves readability and reduces the likelihood of merge conflicts.
+    > Why? The whitespace improves readability and reduces the likelihood of merge conflicts.
 
     ```js
     // bad
@@ -234,7 +234,7 @@
 
   - Use inline styles for styles that have a high cardinality (e.g. uses the value of a prop) and not for styles that have a low cardinality.
 
-  > Why? Generating themed stylesheets can be expensive, so they are best for discrete sets of styles.
+    > Why? Generating themed stylesheets can be expensive, so they are best for discrete sets of styles.
 
     ```jsx
     // bad
@@ -373,7 +373,7 @@
 
   - Define tricky fallback properties in themes.
 
-  > Why? Many CSS-in-JavaScript implementations merge style objects together which makes specifying fallbacks for the same property (e.g. `display`) a little tricky. To keep the approach unified, put these fallbacks in the theme.
+    > Why? Many CSS-in-JavaScript implementations merge style objects together which makes specifying fallbacks for the same property (e.g. `display`) a little tricky. To keep the approach unified, put these fallbacks in the theme.
 
     ```js
     // bad

Diff for: react/README.md

@@ -110,7 +110,7 @@
     ```
   - **Higher-order Component Naming**: Use a composite of the higher-order component's name and the passed-in component's name as the `displayName` on the generated component. For example, the higher-order component `withFoo()`, when passed a component `Bar` should produce a component with a `displayName` of `withFoo(Bar)`.
 
-  > Why? A component's `displayName` may be used by developer tools or in error messages, and having a value that clearly expresses this relationship helps people understand what is happening.
+    > Why? A component's `displayName` may be used by developer tools or in error messages, and having a value that clearly expresses this relationship helps people understand what is happening.
 
     ```jsx
     // bad
@@ -137,7 +137,7 @@
 
   - **Props Naming**: Avoid using DOM component prop names for different purposes.
 
-  > Why? People expect props like `style` and `className` to mean one specific thing. Varying this API for a subset of your app makes the code less readable and less maintainable, and may cause bugs.
+    > Why? People expect props like `style` and `className` to mean one specific thing. Varying this API for a subset of your app makes the code less readable and less maintainable, and may cause bugs.
 
     ```jsx
     // bad
@@ -194,7 +194,7 @@
 
   - Always use double quotes (`"`) for JSX attributes, but single quotes (`'`) for all other JS. eslint: [`jsx-quotes`](http://eslint.org/docs/rules/jsx-quotes)
 
-  > Why? Regular HTML attributes also typically use double quotes instead of single, so JSX attributes mirror this convention.
+    > Why? Regular HTML attributes also typically use double quotes instead of single, so JSX attributes mirror this convention.
 
     ```jsx
     // bad
@@ -289,7 +289,7 @@
 
   - Do not use words like "image", "photo", or "picture" in `<img>` `alt` props. eslint: [`jsx-a11y/img-redundant-alt`](https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/img-redundant-alt.md)
 
-  > Why? Screenreaders already announce `img` elements as images, so there is no need to include this information in the alt text.
+    > Why? Screenreaders already announce `img` elements as images, so there is no need to include this information in the alt text.
 
     ```jsx
     // bad
@@ -466,7 +466,7 @@
 
   - Bind event handlers for the render method in the constructor. eslint: [`react/jsx-no-bind`](https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-bind.md)
 
-  > Why? A bind call in the render path creates a brand new function on every single render.
+    > Why? A bind call in the render path creates a brand new function on every single render.
 
     ```jsx
     // bad
@@ -499,7 +499,7 @@
     ```
 
   - Do not use underscore prefix for internal methods of a React component.
-  > Why? Underscore prefixes are sometimes used as a convention in other languages to denote privacy. But, unlike those languages, there is no native support for privacy in JavaScript, everything is public. Regardless of your intentions, adding underscore prefixes to your properties does not actually make them private, and any property (underscore-prefixed or not) should be treated as being public. See issues [#1024](https://github.com/airbnb/javascript/issues/1024), and [#490](https://github.com/airbnb/javascript/issues/490) for a more in-depth discussion.
+    > Why? Underscore prefixes are sometimes used as a convention in other languages to denote privacy. But, unlike those languages, there is no native support for privacy in JavaScript, everything is public. Regardless of your intentions, adding underscore prefixes to your properties does not actually make them private, and any property (underscore-prefixed or not) should be treated as being public. See issues [#1024](https://github.com/airbnb/javascript/issues/1024), and [#490](https://github.com/airbnb/javascript/issues/490) for a more in-depth discussion.
 
     ```jsx
     // bad