Content Widgets

Turns link lists into a responsive grid. Best on index and hub pages that send readers somewhere else.

• Each heading becomes a small uppercase label above its grid. Headings are optional.
• - [Title](/href) — Description. gives a card with a title and a description.
• End an item with {icon-name} to add an icon, e.g. {rocket}, {book-open}. Names come from the Lucide set. An unknown name is dropped silently — the braces never reach the page.
• An item without a link renders as a non-clickable card.

<!-- widget:cards -->
 
## Start Here
 
- [Overview](/docs/zh/content/features/overview) — What this product is {compass}
- [Getting Started](/docs/zh/content/features/quick-start) — Begin in 3 minutes {rocket}
 
<!-- /widget -->

Turns headed sections into rows the reader expands. Best for material people scan rather than read: FAQs, troubleshooting, per-option details.

• Each heading becomes one row; everything under it until the next heading of the same level becomes the row's body.
• Any markdown works inside a row, including code blocks and tables.
• Every row starts collapsed, so write headings that say enough to choose from without opening.
• Content before the first heading renders above the accordion as an intro.

Turns headed sections into a connected, top-to-bottom sequence. Use it when the order matters — installation, setup, a multi-stage tutorial. If the order does not matter, use accordion instead.

• Each heading becomes one step, numbered in document order.
• Adding or removing a step renumbers the rest automatically.

Turns REST endpoint sections into a form the reader can send a real request from, with their own key and parameters.

• A heading that is a method and a path — ## POST /api/v1/chat — becomes one endpoint block.
• The first table under it with a Field (or Name / Parameter) column becomes the request form, one input per row. Type, Required and Description columns are used when present.
• Templated path segments like /project/update/{projectId} always get their own input.
• An Authorization input is always added. The reader's key is sent from their own browser and never reaches Docsbook.
• A ### subsection containing a code block — ### Example, ### Response — moves into a samples pane beside the form, keeping its title. Any other subsection, such as an ### Errors table, stays in the document flow below.

A small bordered block closing a page with the one thing the reader should do next.

• The first heading becomes the block's title. It renders as a styled line rather than a real heading, so it stays out of your page outline.
• A leading paragraph that is only **bold text** becomes a small uppercase eyebrow.
• A paragraph containing only links becomes the buttons: the first is solid, the rest outlined. A sentence that merely contains a link stays prose.
• Use one per page and at most two links. A second block competes with the first and both convert worse.

<!-- widget:cta -->
 
## Publish your docs in three minutes
 
Connect a repository and your markdown is live.
 
[Start free](https://example.io/signup) · [See pricing](/docs/zh/content/features/pricing)
 
<!-- /widget -->

The same block, with the primary action rendered as a one-field form. What the reader types is carried into the target URL, so they can start without retyping it on the next page.

• The first link's URL is the form target, and its link text labels the button.
• Name the field with an empty query parameter: ?email= submits what the reader typed as email. Without a query string the field is named email.
• A parameter that already has a value rides along unchanged — ?email=&ref=docs keeps ref=docs on the submitted URL, which is useful for attribution.
• Set the placeholder with the link's markdown title: [Join](https://example.io/signup?email= "you@company.com").
• The keyboard follows the field name: email gets an email keyboard, url / site / domain a URL one.
• A target that cannot take a form, such as mailto: or an in-page anchor, degrades to a plain button.

Point it only at a URL that actually reads the parameter. A page that ignores it silently drops what the reader typed, which is worse than a plain button.