@lowdefy/docs-content 0.0.0-experimental-20260928120643 → 6.1.0

package/content/concepts/cli.md

@@ -53,14 +53,12 @@ The `dev` command starts a Lowdefy development server, running locally. It can b
 - `--log-level <level>`: The minimum severity of logs to show in the CLI output. Options are `debug`, `info`, `warn` or `error`. The default is `info`.
 - `--mock-user [user]`: Start the dev server authenticated as a mock user, bypassing the login flow. Pass a JSON user object to set the identity and roles (e.g. `--mock-user '{"sub":"dev","roles":["admin"]}'`), or use the bare flag for a default user with no roles. This is the same mechanism as `auth.dev.mockUser`. Dev server only. See [Auth Configuration](/auth-configuration#mock-user-for-testing-dev-server-only).
 - `--no-open`: Do not open a new tab in the default browser.
-- `--port <port>`: Change the port the server is hosted at. The default is `3000`. A port you set (with this option, the `PORT` environment variable, or `cli.port`) is used or the command fails; only the default moves to the next free port when it is taken.
+- `--port <port>`: Change the port the server is hosted at. The default is `3000`.
 - `--ref-resolver <ref-resolver-function-path>`: Path to a JavaScript file containing a `_ref` resolver function to be used as the app default `_ref` resolver.
 - `--watch <paths...>`: A list of paths to files or directories that should be watched for changes. Globs are supported. Specify each path to watch separated by spaces.
 - `--watch-ignore <patterns...>`: A list of paths to files or directories that should be ignored by the file watcher. Globs are supported. Specify each path to watch separated by spaces.
 - `--skip-codemod-check`: Suppress warnings about pending codemod upgrades.
 
-One app runs one dev server. The running server records itself in `.lowdefy/instance.json` (its pid, port, URL, state and whether a person or the [Lowdefy hub](#hub) started it), and a second `lowdefy dev` for the same app exits before touching anything, naming the server already running. A record copied from another checkout (for example into a git worktree) is ignored.
-
 ## emails
 
 The `emails` command previews the [notification](/notifications) emails your app renders, using [React Email](https://react.email/)'s preview server. It builds the app, renders each notification from its `testData`, and opens the preview so you can iterate on templates without sending real mail. It warns when a template renders a data key your `testData` is missing (which would show as an empty section), and errors if the app has no `notifications:` section.
@@ -76,27 +74,12 @@ The preview tooling (`react-email`) is installed just-in-time by this command
 
 ## agent-setup
 
-The `agent-setup` command sets up a project for AI coding agents. It writes `.mcp.json` registering the [`lowdefy-docs` MCP server](/ai-agent-docs) — `lowdefy mcp`, run over stdio from the app's installed CLI — a Claude Code skill at `.claude/skills/lowdefy-config/SKILL.md`, and a `## Lowdefy` section in `AGENTS.md`. Existing files are merged, not overwritten. Entries pointing at a dev server port (`http://localhost:<port>/lowdefy-docs/mcp`) are replaced, and the skill and section an earlier `agent-setup` wrote are updated. When several `package.json` scripts run `lowdefy dev`, it asks you to set [`cli.devScript`](#configuration).
+The `agent-setup` command sets up a project for AI coding agents. It writes `.mcp.json` registering the dev server's [`lowdefy-docs` MCP endpoint](/ai-agent-docs), a Claude Code skill at `.claude/skills/lowdefy-config/SKILL.md`, and a `## Lowdefy` section in `AGENTS.md`. Existing files are merged, not overwritten.
 
 - `--config-directory <config-directory>`: Change the config directory. The default is the current working directory.
 - `--disable-telemetry`: Disable telemetry.
 - `--log-level <level>`: The minimum severity of logs to show in the CLI output. Options are `debug`, `info`, `warn` or `error`. The default is `info`.
-- `--project-directory <project-directory>`: Change the directory where agent files are written. The default is the nearest ancestor directory containing `.git`.
-
-## mcp
-
-The `mcp` command runs the Lowdefy MCP server for coding agents over stdio. Agent clients start it themselves from `.mcp.json` (see `agent-setup`), one per session — you do not run it by hand. It routes every tool call to the dev server of the app and git checkout the agent is working in, and starts that server through the [hub](#hub) when it is not running. See [AI agent docs](/ai-agent-docs).
-
-## hub
-
-The Lowdefy hub is a small per-user background process that runs dev servers for coding agents. `lowdefy mcp` starts it when an agent first needs a dev server, and it exits on its own after ten idle minutes. It gives each app its own port (from 4100 up, kept across restarts), runs the app's own dev script, and stops a server when no agent session has used it for 30 minutes and no browser tab has it open, or when its directory is removed. It only ever stops servers it started: a `lowdefy dev` you run in a terminal is used by agents but never stopped by them.
-
-- `lowdefy hub status`: List the dev servers the hub runs.
-- `lowdefy hub start [directory] [--restart] [--clean]`: Start (or return) an app's dev server through the hub. `--clean` deletes the build directory first.
-- `lowdefy hub stop [directory] [--all]`: Stop a dev server the hub runs, or all of them.
-- `lowdefy hub logs [directory] [--lines <n>] [--grep <text>]`: Print the recent output of a dev server the hub runs.
-
-The hub keeps its state in `~/.lowdefy/hub` (set `LOWDEFY_HOME` to move it). It starts servers with the script `cli.devScript` names, or the one `package.json` script that runs `lowdefy dev`, so wrappers such as a secrets manager apply to agent-started servers too.
+- `--port <port>`: The port your dev server runs on, used in the generated URLs. The default is `3000`.
 
 ## init
 
@@ -130,19 +113,6 @@ The `init-vercel` command initializes the installation scripts needed to deploy
 - `--disable-telemetry`: Disable telemetry.
 - `--log-level <level>`: The minimum severity of logs to show in the CLI output. Options are `debug`, `info`, `warn` or `error`. The default is `info`.
 
-## test
-
-The `test` command runs the app's config tests — the journeys in `tests/journeys/*.yaml`. It starts the development server headless on a free port, runs every journey through the dev server's journey route, prints `PASS`/`FAIL` per journey with the failing step, stops the server, and exits with code `1` if any journey failed. See [Config Tests](/config-tests).
-
-- `--config-directory <config-directory>`: Change the config directory. The default is the current working directory.
-- `--dev-directory <dev-directory>`: Change the dev directory, the directory in which the development server is placed. The default is `<config-directory>/.lowdefy/dev`.
-- `--disable-telemetry`: Disable telemetry.
-- `--filter <name>`: Only run journeys whose `name` contains this string (case-insensitive). Exits with code `1` if no journey matches.
-- `--log-level <level>`: The minimum severity of logs to show in the CLI output. Options are `debug`, `info`, `warn` or `error`. The default is `info`.
-- `--port <port>`: The port to start the development server on. If it is in use, the next free port is used. The default is `3000`.
-- `--ref-resolver <ref-resolver-function-path>`: Path to a JavaScript file containing a `_ref` resolver function to be used as the app default `_ref` resolver.
-- `--url <url>`: Run the journeys against an already running development server (for example `--url http://localhost:3000` while `lowdefy dev` is running) instead of starting one.
-
 ## upgrade
 
 The `upgrade` command upgrades a Lowdefy app to a newer version by walking you through migration prompts that handle breaking changes.
@@ -217,7 +187,6 @@ All the CLI options can either be set as command line options, or the `cli` conf
 
 Options set in the `lowdefy.yaml` should be defined in camelCase. The options that can be set are:
 - `devDirectory: string`: Change the dev directory, the directory in which the development server is placed. The default is `<config-directory>/.lowdefy/dev`.
-- `devScript: string`: The `package.json` script the [hub](#hub) runs to start this app's dev server for coding agents. Required when several scripts run `lowdefy dev`.
 - `disableTelemetry: boolean`: Disable telemetry.
 - `logLevel: enum`: The minimum severity of logs to show in the CLI output. Options are `debug`, `info`, `warn` or `error`. The default is `info`.
 - `noOpen`: Do not open a new tab in the default browser.

package/content/concepts/connections-and-requests.md

@@ -4,406 +4,4 @@ In a Lowdefy app you can integrate with other services like API's or databases u
 
 > Sensitive information like passwords or API keys are often required to use external services. The <a href = "./_secret">_secret</a> operator should be used to reference these secrets, they should never be coded directly in your app, or committed to source control.
 
-To implement requests, the following steps are required:
-- Define a connection.
-- Define a request.
-- Call the request using a [Request](/Request) action.
-- Use returned data by making use of the [_request](/_request) operator.
-
-## Connections
-
-Connections are defined at the root of your Lowdefy configuration, in the `connections` array. Each connection must have an `id`, a `type`, and `properties` defining the connection. Operators in connection properties are evaluated every time a request is called.
-
-The schema for a Lowdefy connection is:
-
-- `id: string`: __Required__ - A unique identifier for the connection. This is used by requests to specify which connection to use.
-- `type: string`: __Required__ - The connection type to be used.
-- `properties: object`: The settings passed to the connection. __Operators are evaluated__.
-
-###### Connections definition example:
-```yaml
-lowdefy: 6.0.0
-connections:
-  - id: connection1
-    type: ConnectionType1
-    properties:
-      # ...
-  - id: connection2
-    type: ConnectionType2
-    properties:
-      # ...
-pages:
-  # ...
-```
-
-Our goal is to make connections for everything. As the Lowdefy community grows, we will continue to develop the most requested connections. If the connection you require is not supported yet, please head over to our [new connections voting board](https://github.com/lowdefy/lowdefy/discussions/309) to request and vote for new connections.
-
-## Requests
-
-Requests can be defined on any block, and the results of the request can be access using the `_request` operator anywhere on the same page. Requests must have an `id`, `type`, `connectionId` field specifying the connection to use, and `properties` defining the request settings. Requests can be called using the [`Request`](/Request) action.
-
-Data that should be passed to the request from the client can be defined in the `payload` field. Operators can be used to create the payload. An example of this would be to use the `_state` operator to include the value of an input block in the payload. The data in the payload can be accessed in the request by making use of the [`_payload`](/_payload) operator in the `properties` field. The operators defined in the properties field are evaluated on the server, while those defined in the payload field are evaluated on the client. Operators in the request are evaluated every time a request is called.
-
 > The <code>_user</code> operator should be used under <code>properties</code> and not <code>payload</code>. This is important since operators under <code>payload</code> are evaluated on the client, and are therefore vulnerable to users with malicious intent.
-
-The schema for a Lowdefy request is:
-
-- `id: string`: __Required__ - A identifier for the request. It must be unique within the page the request is defined in.
-- `type: string`: __Required__ - The request type to be used. It must be a type supported by the connection type.
-- `payload: object`: The operators to be used inside of the request. __Operators are evaluated on the client__.
-- `connectionId: string`: __Required__ - The `id` of the connection that should be used.
-- `properties: object`: The settings passed to the request. Make use of [`_payload`](/_payload) operator to use operators that were evaluated in `payload` mentioned above. __Operators are evaluated on the server__.
-
-###### Requests definition example:
-```yaml
-id: block_with_requests
-type: BlockType
-requests:
-  - id: request1
-    type: RequestType1
-    connectionId: connectionId1 # Connection with id: connectionId1 must be defined
-    payload:
-      field:
-        _state: field
-    properties:
-      # ...
-  - id: request2
-    type: RequestType2
-    connectionId: connectionId2 # Connection with id: connectionId2 must be defined
-    properties:
-      # ...
-properties:
-  # ...
-```
-
-## Request Action
-
-The `Request` action calls a request, or if used during an `onInit` event, calls those requests while a page loads. Read more about the `Request` action [here](/Request).
-
-###### Call a single request:
-```yaml
-- id: call_one_request
-  type: Request
-  params: request1
-```
-
-## _request operator
-
-The `_request` operator returns the response value of a request. If the request has not yet been called, or is still executing, the returned value is `null`. Read more about the `_request` operator [here](/_request). For more detailed information about a request, the [_request_details](/_request_details) operator can be used.
-
-###### Using a request response:
-```yaml
-_request: my_request
-```
-
-## General Example
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: connection1
-    type: ConnectionType1
-    properties:
-      # ...
-
-pages:
-  - id: page1
-    type: PageHeaderMenu
-    properties:
-      title: Page 1
-    requests:
-      - id: request1
-        type: RequestType1
-        connectionId: connection1
-        properties:
-          # ...
-    events:
-      onInit:
-        - id: call_request
-          type: Request
-          params: request1
-    blocks:
-      - id: content_card
-        type: Card
-        blocks:
-          - id: paragraph
-            type: Paragraph
-            properties:
-              content:
-                _request: request1
-```
-
-## Working Example
-
-For this example, a connection to [{JSON}Placeholder](https://jsonplaceholder.typicode.com/) will be used.
-To create this `connection`, define the connection as follows in the `lowdefy.yaml` file:
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: my_api
-    type: AxiosHttp
-    properties:
-      baseURL: https://jsonplaceholder.typicode.com
-
-pages:
-  - id: home
-    type: PageHeaderMenu
-```
-
-To use this connection, a `request` must be defined, which references the corresponding `connectionId`. A request to get the list of users can be added to the home page as follows:
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: my_api
-    type: AxiosHttp
-    properties:
-      baseURL: https://jsonplaceholder.typicode.com
-
-pages:
-  - id: home
-    type: PageHeaderMenu
-
-    requests:
-      - id: get_users
-        type: AxiosHttp
-        connectionId: my_api
-        properties:
-          url: /users
-```
-
-This request should be called when the page is mounted. To do this, the [`Request`](/Request) action will be used during the `onMount` event of the home page[`PageHeaderMenu`](/PageHeaderMenu) block.
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: my_api
-    type: AxiosHttp
-    properties:
-      baseURL: https://jsonplaceholder.typicode.com
-
-pages:
-  - id: home
-    type: PageHeaderMenu
-
-    requests:
-      - id: get_users
-        type: AxiosHttp
-        connectionId: my_api
-        properties:
-          url: /users
-
-    events:
-      onMount:
-        - id: fetch_get_users
-          type: Request
-          params: get_users
-```
-
-A block can be added to the page, that can use or display the data returned by this request. The [`_request`](/_request) operator is used to get the the results of the request.
-In this example, a [`Selector`](/Selector) block will be added. The [`_array.map`](/_array) operator is used to get the data in a form that can be used by the Selector.
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: my_api
-    type: AxiosHttp
-    properties:
-      baseURL: https://jsonplaceholder.typicode.com
-
-pages:
-  - id: home
-    type: PageHeaderMenu
-
-    requests:
-      - id: get_users
-        type: AxiosHttp
-        connectionId: my_api
-        properties:
-          url: /users
-
-    events:
-      onMount:
-        - id: fetch_get_users
-          type: Request
-          params: get_users
-
-    blocks:
-      - id: user_id
-        type: Selector
-        properties:
-          title: Select a User
-          options:
-            _array.map:
-              - _request: get_users.data
-              - _function:
-                  label:
-                    __args: 0.name
-                  value:
-                    __args: 0.id
-```
-
-To get the posts made by the selected user, a new request should be created and called once the value of the Selector changes.
-To do this, create a new request that will make use of a `payload` to get the posts with the selected user id. Add an `onChange` event on the `Selector` block, during which the new request is called.
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: my_api
-    type: AxiosHttp
-    properties:
-      baseURL: https://jsonplaceholder.typicode.com
-
-pages:
-  - id: home
-    type: PageHeaderMenu
-
-    requests:
-      - id: get_users
-        type: AxiosHttp
-        connectionId: my_api
-        properties:
-          url: /users
-      - id: get_posts
-        type: AxiosHttp
-        connectionId: my_api
-        payload:
-          id:
-            _state: user_id
-        properties:
-          url:
-            _string.concat:
-              - /users/
-              - _payload: id
-              - /posts
-
-    events:
-      onMount:
-        - id: fetch_get_users
-          type: Request
-          params: get_users
-
-    blocks:
-      - id: user_id
-        type: Selector
-        properties:
-          title: Select a User
-          options:
-            _array.map:
-              - _request: get_users.data
-              - _function:
-                  label:
-                    __args: 0.name
-                  value:
-                    __args: 0.id
-        events:
-          onChange:
-            - id: fetch_get_posts
-              type: Request
-              params: get_posts
-```
-
-Set the data from the result of this request in state by using the [`SetState`](/SetState) action. To display the posts, make use of a [`List`](/List) block. In this `List` block, display the data returned of each post in a [`Markdown`](/Markdown) block.
-This is done as follows:
-
-###### lowdefy.yaml
-```yaml
-lowdefy: 6.0.0
-
-connections:
-  - id: my_api
-    type: AxiosHttp
-    properties:
-      baseURL: https://jsonplaceholder.typicode.com
-
-pages:
-  - id: home
-    type: PageHeaderMenu
-
-    requests:
-      - id: get_users
-        type: AxiosHttp
-        connectionId: my_api
-        properties:
-          url: /users
-
-      - id: get_posts
-        type: AxiosHttp
-        connectionId: my_api
-        payload:
-          id:
-            _state: user_id
-        properties:
-          url:
-            _string.concat:
-              - /users/
-              - _payload: id
-              - /posts
-
-    events:
-      onMount:
-        - id: fetch_get_users
-          type: Request
-          params: get_users
-
-    blocks:
-      - id: user_id
-        type: Selector
-        properties:
-          title: Select a User
-          options:
-            _array.map:
-              - _request: get_users.data
-              - _function:
-                  label:
-                    __args: 0.name
-                  value:
-                    __args: 0.id
-        events:
-          onChange:
-            - id: fetch_get_posts
-              type: Request
-              params: get_posts
-            - id: set_posts
-              type: SetState
-              params:
-                posts:
-                  _request: get_posts.data
-
-      - id: posts
-        type: List
-        blocks:
-          - id: posts.$
-            type: Markdown
-            style:
-              padding: 10
-            properties:
-              content:
-                _string.concat:
-                  - |
-                    ```yaml
-                  - _custom_yaml_stringify:
-                      - _state: posts.$
-                  - |
-                    ```
-
-```
-
-### TLDR
-  - `connections` define links to other services, like connecting to a database. They are defined at the root of the lowdefy configuration.
-  - `requests` use connections to make a call to the connected external services.
-  - Use the `payload` object on a request to pass data such as state values from the app client to the server as required.
-  - Use the [`_secret`](/_secret) operator to reference API keys or other secrets as required - do not code secrets into your config or commit secrets to your config source control.

package/content/concepts/custom-html.md

@@ -1,43 +1,3 @@
 # Custom HTML
 
 > SECURITY WARNING: Custom HTML can execute JavaScript inside your Lowdefy app. Insecure code can expose your app or data. Since Lowdefy doesn't validate your custom code, make sure that you only load trusted code.
-
-It is possible to extend the functionality of a Lowdefy app by loading custom code (HTML, CSS and JavaScript) into the HTML `head` and `body` of all pages. This can be useful for executing third party code such as Google Analytics, Intercom, etc. However, if the goal is to extend the functionality of your Lowdefy app with custom blocks, operators, actions or requests, use [plugins](/plugins).
-
-The content loaded into the `head` and `body` tag can be any valid HTML. Be sure to only load trusted code into your app, as this code will be able to execute JavaScript on all pages of your Lowdefy app, which could expose you app or data to security vulnerabilities. Your own code can also be hosted from the [Lowdefy public folder](/hosting-files).
-
-## Schema to load custom code
-
-- `app.html.appendHead: string`: Any valid HTML content can be loaded just before the `</head>` tag of the page.
-- `app.html.appendBody: string`: Any valid HTML content can be loaded just before the `</body>` tag of the page.
-
-Most often it is convenient to abstract this HTML out to a separate file using the [`_ref`](/_ref) operator.
-
-> __Warning__: Code imported using `appendHead` or `appendBody` will be loaded, and can execute JavaScript on every page of your Lowdefy app.
-
-#### Examples
-
-###### Loading third party code snippet like Google Analytics:
-
-To add [Google Analytics](/https://developers.google.com/analytics/devguides/collection/analyticsjs) to a Lowdefy app, the `lowdefy.yaml` can be setup with:
-
-```yaml
-name: google-analytics-example
-lowdefy: 6.0.0
-# ...
-app:
-  html:
-    appendHead: |
-      <!-- Google Analytics -->
-      <script>
-      (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
-      (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
-      m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
-      })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
-
-      ga('create', 'UA-XXXXX-Y', 'auto');
-      ga('send', 'pageview');
-      </script>
-      <!-- End Google Analytics -->
-# ...
-```

package/content/concepts/custom-styling.md

@@ -3,7 +3,7 @@
 Lowdefy provides several ways to style blocks and customize the look of your app:
 
 - **`class`** — Apply CSS class names (including Tailwind CSS utility classes) to blocks.
-- **`style`** — Apply inline CSS styles to blocks. Use `.`-prefixed keys to target specific parts (CSS slots).
+- **`style`** — Apply inline CSS styles to blocks. Use `--`-prefixed keys to target specific parts (CSS slots).
 - **`properties.theme`** — Override antd design tokens per block. See [Theming](/theming) for details.
 - **`public/styles.css`** — A global CSS file for custom styles.
 
@@ -11,7 +11,7 @@ Lowdefy provides several ways to style blocks and customize the look of your app
 
 The `class` property applies CSS class names to a block. [Tailwind CSS](https://tailwindcss.com/) is always available in Lowdefy apps, so you can use any Tailwind utility classes directly.
 
-`class` can be a string, an array of strings, an object keyed by the block's CSS keys, or an operator that computes the classes at runtime:
+`class` can be a string, an array of strings, or an object keyed by the block's CSS keys:
 
 ```yaml
 # String — applied to the block wrapper
@@ -27,60 +27,15 @@ The `class` property applies CSS class names to a block. [Tailwind CSS](https://
     - shadow-lg
     - rounded-xl
 
-# Object — target specific parts of the block using CSS keys (. prefix)
+# Object — target specific parts of the block using CSS keys (-- prefix)
 - id: my_card
   type: Card
   class:
     .element: "shadow-lg"
     .header: "bg-gray-100"
     .body: "p-8"
-
-# Operator — the block's classes are computed at runtime
-- id: status_badge
-  type: Box
-  class:
-    _if:
-      test:
-        _eq:
-          - _state: status
-          - error
-      then: bg-red-100 text-red-700
-      else: bg-green-100 text-green-700
-```
-
-An operator's result may be a string, an array of strings, or an object of `{ class: boolean }` where each class with a truthy value is applied:
-
-```yaml
-- id: status_badge
-  type: Box
-  class:
-    _if:
-      test:
-        _eq:
-          - _state: status
-          - error
-      then:
-        bg-red-100: true
-        text-red-700: true
-      else: bg-green-100
 ```
 
-An operator at the root of `class` computes the classes of the block wrapper. To compute a specific part's classes, place the operator under that CSS key:
-
-```yaml
-- id: my_card
-  type: Card
-  class:
-    .header:
-      _if:
-        test:
-          _state: highlighted
-        then: bg-yellow-100
-        else: bg-gray-100
-```
-
-> **Note:** An operator's result is never expanded into a map of CSS keys — a root operator always sets the block wrapper's classes. A result with dot-prefixed keys (`{ .element: p-4 }`) is reported as a config error, and those keys are not applied as classes.
-
 Tailwind responsive prefixes work as expected:
 
 ```yaml
@@ -103,7 +58,7 @@ See [Theming](/theming) for the full list of bridged tokens and how to add custo
 
 ## The `style` property
 
-The `style` property applies inline CSS styles to a block. When used with flat CSS properties (no `.` prefix), it targets the block's layout wrapper:
+The `style` property applies inline CSS styles to a block. When used with flat CSS properties (no `--` prefix), it targets the block's layout wrapper:
 
 ```yaml
 - id: my_block
@@ -148,7 +103,7 @@ Each block's documentation page lists its supported CSS keys.
 
 Each block declares named style targets in its `meta.cssKeys`. For example, the [Card](/Card) block supports: `element`, `header`, `body`, `cover`, `actions`, `extra`.
 
-Both `class` (object form) and `style` use `.`-prefixed versions of these keys to target specific parts of a block. The `.` prefix mirrors CSS selector convention and avoids confusion with CSS property names.
+Both `class` (object form) and `style` use `--`-prefixed versions of these keys to target specific parts of a block. The `--` prefix mirrors CSS custom property convention and avoids confusion with CSS property names.
 
 To find the CSS keys for a block, check the block's documentation page.