docs: Remove tocs (#17133)

docs/src/browser-contexts.md

@@ -3,14 +3,9 @@ id: browser-contexts
 title: "Browser Contexts"
 ---
 
-<!-- TOC -->
-
 ## Browser context
 
-A [BrowserContext] is an isolated incognito-alike session within a browser instance. Browser contexts are fast and
-cheap to create. We recommend running each test scenario in its own new Browser context, so that
-the browser state is isolated between the tests. If you are using [Playwright Test](./intro.md), this happens out of the
-box for each test. Otherwise, you can create browser contexts manually:
+A [BrowserContext] is an isolated incognito-alike session within a browser instance. Browser contexts are fast and cheap to create. We recommend running each test scenario in its own new Browser context, so that the browser state is isolated between the tests. If you are using [Playwright Test](./intro.md), this happens out of the box for each test. Otherwise, you can create browser contexts manually:
 
 ```js
 const browser = await chromium.launch();

docs/src/cli.md

@@ -5,8 +5,6 @@ title: "Command line tools"
 
 Playwright comes with the command line tools.
 
-<!-- TOC -->
-
 ## Usage
 
 ```bash js

docs/src/dialogs.md

@@ -5,8 +5,6 @@ title: "Dialogs"
 
 Playwright can interact with the web page dialogs such as [`alert`](https://developer.mozilla.org/en-US/docs/Web/API/Window/alert), [`confirm`](https://developer.mozilla.org/en-US/docs/Web/API/Window/confirm), [`prompt`](https://developer.mozilla.org/en-US/docs/Web/API/Window/prompt) as well as [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) confirmation.
 
-<!-- TOC -->
-
 ## alert(), confirm(), prompt() dialogs
 
 By default, dialogs are auto-dismissed by Playwright, so you don't have to handle them. However, you can register a dialog handler before the action that triggers the dialog to accept or decline it.
@@ -37,10 +35,10 @@ await page.Locator("button").ClickAsync();
 ```
 
 :::note
-[`event: Page.dialog`] listener **must handle** the dialog. Otherwise your action will stall, be it [`method: Page.click`], [`method: Page.evaluate`] or any other. That's because dialogs in Web are modal and block further page execution until they are handled.
+[`event: Page.dialog`] listener **must handle** the dialog. Otherwise your action will stall, be it [`method: Page.click`], [`method: Page.evaluate`] or any other. That's because dialogs in Web are modals and therefore block further page execution until they are handled.
 :::
 
-As a result, following snippet will never resolve:
+As a result, the following snippet will never resolve:
 
 :::warning
 WRONG!
@@ -83,9 +81,9 @@ If there is no listener for [`event: Page.dialog`], all dialogs are automaticall
 
 ## beforeunload dialog
 
-When [`method: Page.close`] is invoked with the truthy [`option: runBeforeUnload`] value, it page runs its unload handlers. This is the only case when [`method: Page.close`] does not wait for the page to actually close, because it might be that the page stays open in the end of the operation.
+When [`method: Page.close`] is invoked with the truthy [`option: runBeforeUnload`] value, the page runs its unload handlers. This is the only case when [`method: Page.close`] does not wait for the page to actually close, because it might be that the page stays open in the end of the operation.
 
-You can register a dialog handler to handle the beforeunload dialog yourself:
+You can register a dialog handler to handle the `beforeunload` dialog yourself:
 
 ```js
 page.on('dialog', async dialog => {

docs/src/events.md

@@ -7,12 +7,9 @@ Playwright allows listening to various types of events happening in the web page
 as network requests, creation of child pages, dedicated workers etc. There are several
 ways to subscribe to such events:
 
-<!-- TOC -->
-
 ## Waiting for event
 
-Most of the time, scripts will need to wait for a particular event to happen. Below are some of the typical event
-awaiting patterns.
+Most of the time, scripts will need to wait for a particular event to happen. Below are some of the typical event awaiting patterns.
 
 Wait for a request with the specified url:
 
@@ -173,7 +170,7 @@ await page.GotoAsync("https://www.openstreetmap.org/");
 ## Adding one-off listeners
 * langs: js, python, java
 
-If certain event needs to be handled once, there is a convenience API for that:
+If a certain event needs to be handled once, there is a convenience API for that:
 
 ```js
 page.once('dialog', dialog => dialog.accept("2021"));

docs/src/frames.md

@@ -3,10 +3,6 @@ id: frames
 title: "Frames"
 ---
 
-<!-- TOC -->
-
-## Frames
-
 A [Page] can have one or more [Frame] objects attached to it. Each page has a main frame and page-level interactions
 (like `click`) are assumed to operate in the main frame.
 

docs/src/input.md

@@ -3,7 +3,7 @@ id: input
 title: "Input"
 ---
 
-<!-- TOC -->
+Run tests on HTML Input elements such as text inputs, checkboxes, radio buttons, select options, mouse clicks, type characters, keys and shortcuts as well as upload files and focus elements.
 
 ## Text input
 

docs/src/selectors.md

@@ -7,8 +7,6 @@ Selectors are strings that are used to create [Locator]s. Locators are used to p
 
 Writing good selectors is part art, part science so be sure to checkout the [Best Practices](#best-practices) section.
 
-<!-- TOC -->
-
 ## Quick guide
 
 - Text selector

docs/src/test-advanced-js.md

@@ -3,8 +3,6 @@ id: test-advanced
 title: "Advanced: configuration"
 ---
 
-<!-- TOC -->
-
 ## Configuration object
 
 Configuration file exports a single [TestConfig] object. See [TestConfig] properties for available configuration options.

docs/src/test-annotations-js.md

@@ -3,10 +3,6 @@ id: test-annotations
 title: "Annotations"
 ---
 
-<!-- TOC -->
-
-## Annotations
-
 Playwright Test supports test annotations to deal with failures, flakiness, skip, focus and tag tests:
 - [`method: Test.skip#1`] marks the test as irrelevant. Playwright Test does not run such a test. Use this annotation when the test is not applicable in some configuration.
 - [`method: Test.fail#1`] marks the test as failing. Playwright Test will run this test and ensure it does indeed fail. If the test does not fail, Playwright Test will complain.

docs/src/test-assertions-js.md

@@ -3,8 +3,7 @@ id: test-assertions
 title: "Assertions"
 ---
 
-Playwright Test uses [expect](https://jestjs.io/docs/expect) library for test assertions. This library provides
-a lot of matchers like `toEqual`, `toContain`, `toMatch`, `toMatchSnapshot` and many more:
+Playwright Test uses [expect](https://jestjs.io/docs/expect) library for test assertions. This library provides a lot of matchers like `toEqual`, `toContain`, `toMatch`, `toMatchSnapshot` and many more:
 
 ```js
 expect(success).toBeTruthy();
@@ -17,15 +16,10 @@ the expected condition is met. Consider the following example:
 await expect(page.locator('.status')).toHaveText('Submitted');
 ```
 
-Playwright Test will be re-testing the node with the selector `.status` until fetched Node has the `"Submitted"`
-text. It will be re-fetching the node and checking it over and over, until the condition is met or until the timeout is
-reached. You can either pass this timeout or configure it once via the [`property: TestConfig.expect`] value
-in test config.
+Playwright Test will be re-testing the node with the selector `.status` until fetched Node has the `"Submitted"` text. It will be re-fetching the node and checking it over and over, until the condition is met or until the timeout is reached. You can either pass this timeout or configure it once via the [`property: TestConfig.expect`] value in test config.
 
 By default, the timeout for assertions is set to 5 seconds. Learn more about [various timeouts](./test-timeouts.md).
 
-<!-- TOC -->
-
 ## Negating Matchers
 
 In general, we can expect the opposite to be true by adding a `.not` to the front

docs/src/test-cli-js.md

@@ -3,10 +3,6 @@ id: test-cli
 title: "Command line"
 ---
 
-<!-- TOC -->
-
-## Examples
-
 Here are the most common options available in the command line.
 
 - Run all the tests

docs/src/test-configuration-js.md

@@ -11,8 +11,6 @@ You can specify any options globally in the configuration file, and most of them
 
 See the full list of [test options][TestOptions] and all [configuration properties][TestConfig].
 
-<!-- TOC -->
-
 ## Global configuration
 
 Create `playwright.config.js` (or `playwright.config.ts`) and specify options in the [`property: TestConfig.use`] section.

docs/src/test-fixtures-js.md

@@ -3,10 +3,6 @@ id: test-fixtures
 title: "Advanced: fixtures"
 ---
 
-<!-- TOC -->
-
-## Introduction to fixtures
-
 Playwright Test is based on the concept of test fixtures. Test fixtures are used to establish environment for each test, giving the test everything it needs and nothing else. Test fixtures are isolated between tests. With fixtures, you can group tests based on their meaning, instead of their common setup.
 
 ### Built-in fixtures

docs/src/test-parallel-js.md

@@ -12,8 +12,6 @@ Playwright Test runs tests in parallel. In order to achieve that, it runs severa
 
 You can control the number of [parallel worker processes](#limit-workers) and [limit the number of failures](#limit-failures-and-fail-fast) in the whole test suite for efficiency.
 
-<!-- TOC -->
-
 ## Worker processes
 
 All tests run in worker processes. These processes are OS processes, running independently, orchestrated by the test runner. All workers have identical environments and each starts its own browser.

docs/src/test-parameterize-js.md

@@ -5,8 +5,6 @@ title: "Parametrize tests"
 
 You can either parametrize tests on a test level or on a project level.
 
-<!-- TOC -->
-
 ## Parameterized Tests
 
 ```js tab=js-js

docs/src/test-reporters-js.md

@@ -3,10 +3,6 @@ id: test-reporters
 title: "Reporters"
 ---
 
-<!-- TOC -->
-
-## Using reporters
-
 Playwright Test comes with a few built-in reporters for different needs and ability to provide custom reporters. The easiest way to try out built-in reporters is to pass `--reporter` [command line option](./test-cli.md).
 
 

docs/src/test-retries-js.md

@@ -3,7 +3,7 @@ id: test-retries
 title: "Test retry"
 ---
 
-<!-- TOC -->
+Test retries are a way to automatically re-run a test when it fails. This is useful when a test is flaky and fails intermittently. Test retries are configured in the [configuration file](./test-configuration.md).
 
 ## Failures
 

docs/src/test-timeouts-js.md

@@ -3,10 +3,6 @@ id: test-timeouts
 title: "Timeouts"
 ---
 
-<!-- TOC -->
-
-## Overview
-
 Playwright Test has multiple configurable timeouts for various tasks.
 
 |Timeout    |Default             |Description                      |

docs/src/videos.md

@@ -3,10 +3,7 @@ id: videos
 title: "Videos"
 ---
 
-<!-- TOC -->
-
-Playwright can record videos for all pages in a [browser context](./browser-contexts.md). Videos are saved
-upon context closure, so make sure to await [`method: BrowserContext.close`].
+Playwright can record videos for all pages in a [browser context](./browser-contexts.md). Videos are saved upon context closure, so make sure to await [`method: BrowserContext.close`].
 
 ```js
 const context = await browser.newContext({ recordVideo: { dir: 'videos/' } });