Card documentation

This merge request intends to start discussing the documentation for the Card component.

#287

contents/components/card.md

@@ -10,7 +10,7 @@ Cards are used to connect similar concepts and/or activities to help make it eas
 
 | Do | Don't |
 | --- | --- |
-| Use cards for snapshots or an overview of information. | Don't use a card for an entire workflow. Consider a dedicated content area (a drawer, modal, or even a dedicated page) for deep dives.|
+| Use cards for snapshots or an overview of information. | Don't use a card for an entire workflow. Consider a dedicated content area (a drawer, modal, or even a dedicated page) for deep dives. |
 
 ### Types
 
@@ -25,11 +25,11 @@ There are two main types of Cards: Static and Dynamic.
 
 #### Table
 
-If the purpose of using the component is to compare and contrast 5 or more static (non-draggable) pieces of content, or if you're utilizing column headers to organize your content horizontally, a better option would be to structure the data within a [table component](https://design.gitlab.com/components/table).
+If the purpose of using the component is to compare and contrast 5 or more static (non-draggable) pieces of content, or if you're utilizing column headers to organize your content horizontally, a better option would be to structure the data within a [table component](/components/table).
 
 #### Single Stat
 
-If the purpose of using the component is to show a high level overview of incoming data (e.g. Security vulnerabilities, Threat Monitoring statistics), use a single stat component [todo: add link].
+If the purpose of using the component is to show a high level overview of incoming data such as Security vulnerabilities or Threat Monitoring statistics, use a single stat component.
 
 ## Demo
 
@@ -47,7 +47,7 @@ The header is **optional** and acts as the title of the proceeding body content.
 
 #### Body
 
-The card body is **always required**. The content in the body should never be ambiguous or unclear. Strive to be as concise as possible and provide the user with content regarding a single topic. If a Card's purpose is to communicate a pricing plan, the body would contain the plan's price point and key feature information. 
+The card body is **always required**. The content in the body should never be ambiguous or unclear. Strive to be as concise as possible and provide the user with content regarding a single topic. For example, if a card's purpose is to communicate a pricing plan, the body would contain the plan's price point and key feature information. 
 
 Use multiple sections within the body when you have two or more related but distinct pieces of information to communicate to users. Multiple sections can help break up complicated concepts like pricing data. Content in this area can include media, photos
 
@@ -63,11 +63,13 @@ Todo: Add more context here (e.g. cards and alerts) and examples
 
 #### Responsiveness
 
-The Card width is fluid by default. When presenting two or more static cards in a row, care must be taken to ensure the appropriate stacking occurs across breakpoints.
+The card width is fluid by default. When presenting two or more static cards in a row, care must be taken to ensure the appropriate stacking occurs across breakpoints.
 
 #### Interactions
 
-Dynamic Cards can be draggable and re-ordered within a list. To help layer the component within this particular use-case a drop shadow is required. A draggable Card will maintain the ability to house individual links and actions. Its empty space becomes the trigger to enable the drag functionality. The cursor should change to a pointer hand icon to convey functionality. When dragging the card to a new location, any cards in it's position behind it should move to show their new placement if the user were to let go of the selected card and drop it into the current position.
+Dynamic cards can be draggable and re-ordered within a list. To help layer the component within this particular use-case, a drop shadow is required. A draggable card will maintain the ability to house individual links and actions. Its empty space becomes the trigger to enable the drag functionality. The cursor should change to a pointer hand icon to convey functionality. 
+
+When dragging the card to a new location, any cards positioned behind it should move to show their new placement as if the user were to let go of the selected card and drop it into the current position.
 
 On mobile, there should be a longer hold on the card in order to grab it and move it, so as not to interfere with a lighter, quicker touch for scrolling.