HTML kbd, samp, and var: separate input, output, and variables

Use the distinction

An operations note asks a reviewer to type a command using a case ID supplied by the current record. The command itself is user input; the case identifier is a replaceable value. The response line is a sample result, not another command to paste. Put any safety condition in prose before the snippet, especially if a real tool could change records. The example below is explanatory markup: the named command is not supplied by this lesson. If a product has a real command-line workflow, publish its precise permission model and verified output separately.

<main>
  <h1>Inspect a case state</h1>
  <p>In an authorized test environment, type
    <kbd>case-inspect --id <var>case_id</var></kbd>.
    Replace <var>case_id</var> with the current record ID.</p>
  <p>A successful test may return <samp>Case C-47: held</samp>.</p>
  <p>The response is sample output; it is not proof of a live case.</p>
</main>

Behavior and cost

These text elements add almost no transfer cost. The real maintenance work is keeping command examples synchronized with an actual tool, avoiding secrets in pasted output, and telling readers which fragments are literal. A syntax highlighter is optional; it does not replace the input-output distinction. Test copy-and-paste instructions carefully: a reader should not have to guess whether angle brackets, identifiers, or punctuation are part of the command. If an example could be destructive, state the environment and authorization boundary before it.

Common Mistakes

• Do not mark a program's response as something the user should type.
• Do not present a placeholder as a literal production identifier.
• Do not invent a command and imply it exists in the deployed application.

Connected lessons

• HTML pre and code: preserve source layout without hiding the meaning
• HTML inline text: emphasis, importance, code, and abbreviations
• HTML character references: escape data before inserting it into markup