Merge pull request #195 from mccalluc/fix-its-apostrophe

Fix its apostrophe

.gitignore

@@ -5,6 +5,7 @@ public/
 .DS_Store
 .deploy*/
 support
+.idea/
 
 themes/cypress/source/css/vendor/
 themes/cypress/source/js/vendor/

source/api/commands/_scrollto.md

@@ -16,11 +16,11 @@ cy.scrollTo(x, y, options)
 
 ## Usage
 
-`cy.scrollTo()` can be chained off of `cy` to scroll to a position in the window or chained off another cy command that *yields* a DOM element - limiting scrolling to it's yielded element.
+`cy.scrollTo()` can be chained off of `cy` to scroll to a position in the window or chained off another cy command that *yields* a DOM element - limiting scrolling to its yielded element.
 
 ```javascript
 cy.scrollTo(0, 500)                     // Scroll the window 500px down
-cy.get('.sidebar').scrollTo('bottom')   // Scroll 'sidebar' to it's bottom
+cy.get('.sidebar').scrollTo('bottom')   // Scroll 'sidebar' to its bottom
 ```
 
 **{% fa fa-exclamation-triangle red %} Incorrect Usage**

source/api/commands/closest.md

@@ -3,7 +3,7 @@ title: closest
 comments: false
 ---
 
-Get the first DOM element that matches the selector (whether it be itself or one of it's ancestors).
+Get the first DOM element that matches the selector (whether it be itself or one of its ancestors).
 
 {% note info %}
 The querying behavior of this command matches exactly how {% url `.closest()` http://api.jquery.com/closest %} works in jQuery.

source/api/commands/contains.md

@@ -43,7 +43,7 @@ Get the DOM element containing the content.
 
 **{% fa fa-angle-right %} selector** ***(String selector)***
 
-Specify a selector to filter DOM elements containing the text. Cypress will *ignore* it's {% urlHash 'default preference order' Notes %} for the specified selector. Using a selector allows you to return more *shallow* elements (higher in the tree) that contain the specific text.
+Specify a selector to filter DOM elements containing the text. Cypress will *ignore* its {% urlHash 'default preference order' Notes %} for the specified selector. Using a selector allows you to return more *shallow* elements (higher in the tree) that contain the specific text.
 
 **{% fa fa-angle-right %} options** ***(Object)***
 
@@ -167,7 +167,7 @@ cy.contains('ul', 'apples')
 
 ## Scopes
 
-`.contains()` acts differently whether its starting a series of commands or being chained off of an existing.
+`.contains()` acts differently whether it's starting a series of commands or being chained off of an existing.
 
 ***When starting a series of commands:***
 

source/api/commands/fixture.md

@@ -63,7 +63,7 @@ Option | Default | Description
 
 ## Yields {% helper_icon yields %}
 
-`cy.fixture()` yields the contents of the file. Formatting is determined by it's file extension.
+`cy.fixture()` yields the contents of the file. Formatting is determined by its file extension.
 
 # Examples
 

source/api/commands/getcookie.md

@@ -3,7 +3,7 @@ title: getCookie
 comments: false
 ---
 
-Get a browser cookie by it's name.
+Get a browser cookie by its name.
 
 # Syntax
 

source/api/commands/request.md

@@ -109,7 +109,7 @@ beforeEach(function(){
 
 ***Issue a simple HTTP request***
 
-Sometimes it is quicker to simply test the contents of a page rather than {% url `cy.visit()` visit %} and wait for the entire page and all of it's resource to load.
+Sometimes it is quicker to simply test the contents of a page rather than {% url `cy.visit()` visit %} and wait for the entire page and all of its resource to load.
 
 ```javascript
 cy.request('/admin').its('body').should('include', '<h1>Admin</h1>')

source/api/commands/route.md

@@ -245,7 +245,7 @@ cy.route('/users/*', 'fixture:users/all.json').as('getUsers')
 cy.route('/admin/*', 'fx:users/admin.json').as('getAdmin')
 ```
 
-You may want to define the `cy.route()` after receiving the fixture and working with it's data.
+You may want to define the `cy.route()` after receiving the fixture and working with its data.
 
 ```javascript
 cy.fixture('user').then((user) => {
@@ -387,7 +387,7 @@ cy.route(() => {
 
 ***Understanding Stubbed vs Regular XHR's***
 
-Cypress indicates whether an XHR sent back a stubbed response or actually went out to a server in it's Command Log
+Cypress indicates whether an XHR sent back a stubbed response or actually went out to a server in its Command Log
 
 XHR's that display `(XHR STUB)` in the Command Log have been stubbed and their response, status, headers, and delay have been controlled by your matching `cy.route()`.
 

source/api/commands/scrollto.md

@@ -27,7 +27,7 @@ cy.scrollTo(x, y, options)
 
 ```javascript
 cy.scrollTo(0, 500)                     // Scroll the window 500px down
-cy.get('.sidebar').scrollTo('bottom')   // Scroll 'sidebar' to it's bottom
+cy.get('.sidebar').scrollTo('bottom')   // Scroll 'sidebar' to its bottom
 ```
 
 **{% fa fa-exclamation-triangle red %} Incorrect Usage**
@@ -125,7 +125,7 @@ cy.get('#slider').scrollTo('right', { duration: 2000} )
 
 ## Scopes
 
-`cy.scrollTo()` acts differently whether its starting a series of commands or being chained off of an existing.
+`cy.scrollTo()` acts differently whether it's starting a series of commands or being chained off of an existing.
 
 ***When starting a series of commands:***
 

source/api/commands/server.md

@@ -178,7 +178,7 @@ The idea is that we never want to interfere with static assets that are fetched
 ```javascript
 var whitelist = function(xhr){
   // this function receives the xhr object in question and
-  // will whitelist if its a GET that appears to be a static resource
+  // will whitelist if it's a GET that appears to be a static resource
   xhr.method === 'GET' && /\.(jsx?|html|css)(\?.*)?$/.test(xhr.url)
 }
 ```

source/api/commands/spread.md

@@ -6,7 +6,7 @@ comments: false
 Expand an array into multiple arguments.
 
 {% note info %}
-Identical to {% url `.then()` then %}, but always expects an array-like structure as it's subject.
+Identical to {% url `.then()` then %}, but always expects an array-like structure as its subject.
 {% endnote %}
 
 # Syntax
@@ -35,7 +35,7 @@ cy.location().spread()   // Errors, 'location' does not yield an array
 
 **{% fa fa-angle-right %} fn** ***(Function)***
 
-Pass a function that expands the array into it's arguments.
+Pass a function that expands the array into its arguments.
 
 **{% fa fa-angle-right %} options** ***(Object)***
 

source/api/commands/submit.md

@@ -73,7 +73,7 @@ cy.get('#contact').submit()
 
 `.submit()` is just a helpful command which is a simple shortcut. Normally a user has to perform a different "action" to submit a form. It could be clicking a submit `<button>`, or pressing `enter` on a keyboard.
 
-Oftentimes its much simpler and conveys what you're trying to test by just using `.submit()` directly.
+Oftentimes it's much simpler and conveys what you're trying to test by just using `.submit()` directly.
 
 If you want the other guarantees of waiting for an element to become actionable, you should use a different command like {% url `.click()` click %} or {% url `.type()` type %}.
 

source/api/commands/then.md

@@ -25,7 +25,7 @@ cy.location().then((loc) => {})   // Yields location object as first arg
 
 **{% fa fa-angle-right %} callbackFn** ***(Function)***
 
-Pass a function that takes the previously yielded subject as it's first argument.
+Pass a function that takes the previously yielded subject as its first argument.
 
 **{% fa fa-angle-right %} options** ***(Object)***
 

source/api/commands/viewport.md

@@ -162,7 +162,7 @@ You can {% url 'change these default dimensions' configuration#Viewport %} by ad
 }
 ```
 
-Additionally, Cypress automatically sets the viewport to it's default size between each test.
+Additionally, Cypress automatically sets the viewport to its default size between each test.
 
 ## Scaling
 

source/api/commands/wait.md

@@ -75,7 +75,7 @@ cy.wait(2000) // wait for 2 seconds
 {% note warning 'Anti-Pattern' %}
 You almost **never** need to wait for an arbitrary period of time. There are always better ways to express this in Cypress.
 
-Passing a number to `cy.wait()` exists because its sometimes helpful when debugging to isolate a test failure you're trying to temporarily understand.
+Passing a number to `cy.wait()` exists because it's sometimes helpful when debugging to isolate a test failure you're trying to temporarily understand.
 
 Read about {% url 'best practices' best-practices#Unnecessary-Waiting %} here.
 {% endnote %}

source/api/commands/within.md

@@ -30,7 +30,7 @@ cy.getCookies().within(function() {}) // Errors, 'getCookies' does not yield DOM
 
 **{% fa fa-angle-right %} callbackFn** ***(Function)***
 
-Pass a function that takes the current yielded subject as it's first argument.
+Pass a function that takes the current yielded subject as its first argument.
 
 **{% fa fa-angle-right %} options** ***(Object)***
 

source/api/commands/writefile.md

@@ -66,7 +66,7 @@ Option | Default | Description
 
 ***Write some text to a `txt` file***
 
-If the path to the file does not exist, the file and it's path will be created. If the file already exists, it will be over-written.
+If the path to the file does not exist, the file and its path will be created. If the file already exists, it will be over-written.
 
 ```javascript
 cy

source/api/cypress-api/custom-commands.md

@@ -352,9 +352,9 @@ Cypress.Commands.add('contains', {
   prevSubject: ['optional', 'window', 'document', 'element']
 }, (subject, options) => {
   // subject could be undefined
-  // since its optional.
+  // since it's optional.
   //
-  // if its present
+  // if it's present
   // then its window, document, or element.
   // - when window or document we'll query the entire DOM.
   // - when element we'll query only inside of its children.
@@ -369,7 +369,7 @@ Cypress.Commands.add('contains', {
 **{% fa fa-check-circle green %} Valid Usage**
 
 ```javascript
-cy.contains() // no subject, but valid because its optional
+cy.contains() // no subject, but valid because it's optional
 cy.get('#main').contains() // has subject, and is `element`
 cy.window().contains() // has subject, and is `window`
 cy.document().contains() // has subject, and is `document`
@@ -400,7 +400,7 @@ Take advantage of the {% url `Cypress.log()` cypress-log %} API. When you're iss
 
 Custom commands work well when you're needing to describe behavior that's desirable across **all of your tests**. Examples would be a `cy.setup()` or `cy.login()` or extending your application's behavior like `cy.get('.dropdown').dropdown('Apples')`. These are specific to your application and can be used everywhere.
 
-However, this pattern can be used and abused. Let's not forget - writing Cypress tests is just **JavaScript**, and its often much easier just to write a simple function for repeatable behavior that's specific to only **a single spec file**.
+However, this pattern can be used and abused. Let's not forget - writing Cypress tests is just **JavaScript**, and it's often much easier just to write a simple function for repeatable behavior that's specific to only **a single spec file**.
 
 If you're working on a `search_spec.js` file and want to compose several repeatable actions together, you should first ask yourself:
 

source/api/events/catalog-of-events.md

@@ -76,7 +76,7 @@ Event | Details
 --- | ---
 **Name:** | `fail`
 **Yields:** | the error **(Object)**, mocha runnable **(Object)**
-**Description:** | Fires when the test has failed. It is technically possible to prevent the test from actually failing by binding to this event and invoking an async `done` callback. However this is **strongly discouraged**. Tests should never legitimately fail. This event exists because its extremely useful for debugging purposes.
+**Description:** | Fires when the test has failed. It is technically possible to prevent the test from actually failing by binding to this event and invoking an async `done` callback. However this is **strongly discouraged**. Tests should never legitimately fail. This event exists because it's extremely useful for debugging purposes.
 
 Event | Details
 --- | ---
@@ -171,7 +171,7 @@ The `cy` object is bound to each individual test. Events bound to `cy` will **au
 
 ```javascript
 // likely want to do this in a support file
-// so its applied to all spec files
+// so it's applied to all spec files
 // cypress/support/index.js
 
 Cypress.on('uncaught:exception', (err, runnable) => {
@@ -187,7 +187,7 @@ Cypress.on('uncaught:exception', (err, runnable) => {
 ```javascript
 it('is doing something very important', function(done) {
   // this event will automatically be unbound when this
-  // test ends because its attached to 'cy'
+  // test ends because it's attached to 'cy'
   cy.on('uncaught:exception', (err, runnable) => {
     expect(err.message).to.include('something about the error')
 
@@ -244,7 +244,7 @@ $('button').on('click', (e) => {
 // test code
 it('redirects to another page on click', function (done) {
   // this event will automatically be unbound when this
-  // test ends because its attached to 'cy'
+  // test ends because it's attached to 'cy'
   cy.on('window:before:unload', (e) => {
     // no return value on the event
     expect(e.returnValue).to.be.undefined
@@ -332,7 +332,7 @@ it('can control application confirms', function (done) {
   // confirm method is called in your application
   //
   // this event will automatically be unbound when this
-  // test ends because its attached to 'cy'
+  // test ends because it's attached to 'cy'
   cy.on('window:confirm', (str) => {
     count += 1
 

source/dashboard/overview/runs-dashboard.md

@@ -28,7 +28,7 @@ You will also see a summary at the bottom indicating the files we've created dur
 
 ## {% fa fa-exclamation-triangle fa-fw %} Test Failures
 
-Any tests that fail during a test run can be found under the **Failures** tab. Each failure is listed under it's test title.
+Any tests that fail during a test run can be found under the **Failures** tab. Each failure is listed under its test title.
 
 ***Each failure displays:***
 

source/faq/questions/general-questions-faq.md

@@ -37,7 +37,7 @@ Cypress essentially replaces Karma because it does all of this already and much
 
 ***Capybara***
 
-The a `Ruby` specific tool that allows you to write integration tests for your web application is {% url "Capybara" http://teamcapybara.github.io/capybara/ %}. In the Rails world, this is the *go-to* tool for testing your application. It uses {% url "Sauce Labs" https://SauceLabs.com/ %} (or another headless driver) to interact with browsers. It's API consists of commands that query for DOM elements, perform user actions, navigate around, etc.
+The a `Ruby` specific tool that allows you to write integration tests for your web application is {% url "Capybara" http://teamcapybara.github.io/capybara/ %}. In the Rails world, this is the *go-to* tool for testing your application. It uses {% url "Sauce Labs" https://SauceLabs.com/ %} (or another headless driver) to interact with browsers. Its API consists of commands that query for DOM elements, perform user actions, navigate around, etc.
 
 Cypress essentially replaces Capybara because it does all of these things and much more. The difference is that instead of testing your application in a GUI-less console, you'd see your application at all times. You'd never have to take a screenshot to debug because all commands instantly provide you the state of your application while they run. Upon any command failing, you'll get a human-readable error explaining why it failed. There's no "guessing" when debugging.
 
@@ -115,7 +115,7 @@ Yes. Cypress works on anything rendered to a browser.
 
 ## {% fa fa-angle-right %} Can I use Cypress to script user-actions on an external site like `gmail.com`?
 
-No. There are already lots of tools to do that. Using Cypress to test against a 3rd party application is not it's intended use. It *may* work but will defeat the purpose of why it was created. You use Cypress *while* you develop your application, it helps you write your tests.
+No. There are already lots of tools to do that. Using Cypress to test against a 3rd party application is not its intended use. It *may* work but will defeat the purpose of why it was created. You use Cypress *while* you develop your application, it helps you write your tests.
 
 ## {% fa fa-angle-right %} Is there code coverage?
 

source/guides/core-concepts/conditional-testing.md

@@ -423,13 +423,13 @@ If you cannot accurately know the state of your application then no matter what
 
 Still not convinced?
 
-Not only is this an anti pattern, but its an actual logical fallacy.
+Not only is this an anti pattern, but it's an actual logical fallacy.
 
 You may think to yourself... okay fine, but 4 seconds - man that's not enough. Network requests could be slow, let's bump it up to 1 minute!
 
 Even then, it's still possible a WebSocket message could come in... so 5 minutes!
 
-Even then, not enough, its possible a setTimeout could trigger... 60 minutes.
+Even then, not enough, it's possible a setTimeout could trigger... 60 minutes.
 
 Continually raising the timeout only beleaguers the point. As you approach infinity your confidence does continue to rise on the chances you could prove the desired state will be reached, but you can never prove it will. Instead you could theoretically be waiting for the heat death of the universe for a condition to come that is only a moment away from happening. There is no way to prove or disprove that it *may* conditionally happen.
 

source/guides/core-concepts/interacting-with-elements.md

@@ -53,7 +53,7 @@ The following calculations factor in CSS translations and transforms.
 - Its `width` or `height` is `0`.
 - Its CSS property (or ancestors) is `visibility: hidden`.
 - Its CSS property (or ancestors) is `display: none`.
-- Its CSS property is `position: fixed` and its offscreen or covered up.
+- Its CSS property is `position: fixed` and it's offscreen or covered up.
 
 ***Additionally an element is considered hidden if:***
 
@@ -118,7 +118,7 @@ Before interacting with an element we will *always* scroll it into view (includi
 This scrolling logic only applies to {% urlHash "commands that are actionable above" Actionability %}. **We do not scroll elements** into view when using DOM commands such as {% url "`cy.get()`" get %} or {% url "`.find()`" find %}.
 {% endnote %}
 
-The scrolling algorithm works by scrolling the top, leftmost point of the element we issued the command on to the top, leftmost scrollable point of it's scrollable container.
+The scrolling algorithm works by scrolling the top, leftmost point of the element we issued the command on to the top, leftmost scrollable point of its scrollable container.
 
 After scrolling the element, if we determine that it is still being covered up, we will continue to scroll and "nudge" the page until it becomes visible. This most frequently happens when you have `position: fixed` or `position: sticky` navigation elements which are fixed to the top of the page.
 
@@ -160,7 +160,7 @@ We recommend placing `debugger` or using the {% url `.debug()` debug %} command
 
 Make sure your Developer Tools are open and you can get pretty close to "seeing" the calculations Cypress is performing.
 
-As of `0.20.0` you can also {% url 'bind to Events' catalog-of-events %} that Cypress fires as its working with your element. Using a debugger with these events will give you a much lower level view into how Cypress works.
+As of `0.20.0` you can also {% url 'bind to Events' catalog-of-events %} that Cypress fires as it's working with your element. Using a debugger with these events will give you a much lower level view into how Cypress works.
 
 ```js
 // break on a debugger before the action command