Oct 17, 2019 · Jul 16, 2019 · Jul 16, 2019 · Jul 18, 2019 · Jul 19, 2019 · Jul 21, 2019
diff --git a/docs_source_files/content/getting_started_with_webdriver/_index.md b/docs_source_files/content/getting_started_with_webdriver/_index.md
diff --git a/docs_source_files/content/webdriver/driver_requirements.md b/docs_source_files/content/webdriver/driver_requirements.md
diff --git a/docs_source_files/content/webdriver/waits.md b/docs_source_files/content/webdriver/waits.md
diff --git a/docs_source_files/layouts/partials/menu-footer.html b/docs_source_files/layouts/partials/menu-footer.html
Original file line number	Diff line number	Diff line change
Expand Up		@@ -25,4 +25,5 @@ through a user-facing interface that enables the different browser backends
		to be used transparently,
		enabling cross-browser and cross-platform automation.

	More details about drivers can be found in [Driver Idiosyncrasies](drivers.md).
	More details about drivers can be found in
	[Driver Idiosyncrasies]({{< ref "/driver_idiosyncrasies/_index.md" >}}).
Original file line number	Diff line number	Diff line change
Expand Up		@@ -13,7 +13,7 @@ WebDriver's aim is to emulate a real user's interaction
		with the browser as closely as possible.
		This is possible at varying levels in different browsers.
		For more details on the different driver idiosyncracies,
	please see _[Driver Idiosyncracies](drivers.md)_.
	please see _[Driver Idiosyncracies]({{< ref "/driver_idiosyncrasies/_index.md" >}})_.

		Even though all the drivers share a single user-facing interface
		for controlling the browser,
Expand Down Expand Up		@@ -427,7 +427,7 @@ has an excellent writeup on Microsoft's implementation.
		Current releases of Opera are built on top of the Chromium engine,
		and WebDriver is now supported via the closed-source
		[Opera Chromium Driver](//github.com/operasoftware/operachromiumdriver/releases),
	which can be [added to your PATH](#adding_executables_to_your_path) or as a
	which can be [added to your PATH](#adding-executables-to-your-path) or as a
		system property.

		Instantiating a driver session is similar to Firefox and Chromium:
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -65,7 +65,7 @@ assert.strictEqual(await element.getText(), 'Hello from JavaScript!');
		{{< / code-tab >}}

		The issue here is that the default
	[page load strategy](#page_load_strategy)
	[page load strategy]({{< ref "/webdriver/page_loading_strategy.md" >}})
		used in WebDriver listens for the `document.readyState`
		to change to `"complete"` before returning from the call to _navigate_.
		Because the `p` element is
Expand All		@@ -76,14 +76,15 @@ about elements or events that trigger asynchronously
		without explicitly waiting—or blocking—on those events.

		Fortunately, using the normal instruction set available on
	the [_WebElement_](#web_element) interface—such
	the [_WebElement_]({{< ref "/webdriver/web_element.md" >}}) interface—such
		as _WebElement.click_ and _WebElement.sendKeys_—are
		guaranteed to be synchronous,
		in that the function calls won't return
		(or the callback won't trigger in callback-style languages)
		until the command has been completed in the browser.
		The advanced user interaction APIs,
	[_Keyboard_](#keyboard) and [_Mouse_](#mouse),
	[_Keyboard_]({{< ref "/webdriver/keyboard.md" >}})
	and [_Mouse_]({{< ref "/webdriver/mouse.md" >}}),
		are exceptions as they are explicitly intended as
		"do what I say" asynchronous commands.

Expand All		@@ -95,7 +96,7 @@ between the browser and your WebDriver script,
		most Selenium clients ship with a _wait_ package.
		When employing a wait,
		you are using what is commonly referred to
	as an [_explicit wait_](#explicit_wait).
	as an [_explicit wait_](#explicit-wait).


		## Explicit wait
Expand Down Expand Up		@@ -271,15 +272,15 @@ to find an exhaustive list of expected conditions:
		## Implicit wait

		There is a second type of wait that is distinct from
	[explicit wait](#explicit_wait) called _implicit wait_.
	[explicit wait](#explicit-wait) called _implicit wait_.
		By implicitly waiting, WebDriver polls the DOM
		for a certain duration when trying to find _any_ element.
		This can be useful when certain elements on the webpage
		are not available immediately and need some time to load.

		Implicit waiting for elements to appear is disabled by default
		and will need to be manually enabled on a per-session basis.
	Mixing [explicit waits](#explicit_wait) and implicit waits
	Mixing [explicit waits](#explicit-wait) and implicit waits
		will cause unintended consequences, namely waits sleeping for the maximum
		time even if the element is available or condition is true.

Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -2,7 +2,7 @@
		© {{ replace .Site.Copyright "{year}" now.Year }}
		</p>
		<p>
	<a href=attr.html>Software Freedom Conservancy</a>
	<a href="//seleniumhq.github.io/docs/new_site/front_matter/copyright_and_attributions/">Software Freedom Conservancy</a>
		</p>
		<p>
		<a href=//github.com/seleniumhq/docs/issues>Report a bug</a>
Expand Down