HTML — Computercode

<think> Here's a thinking process:

1. Analyze User Input:

• Role: Expert programming tutor, beginner-friendly tutorial site.
• Rules: 100% original content, plain language, short sentences, explain every term on first use, warm but not childish tone.
• Topic: HTML "Computercode" (This is a bit unusual. HTML doesn't have a standard tag called "computercode". I think the user might mean <code>, <pre>, <kbd>, <samp>, <var>, <tt> (deprecated), or maybe they're referring to displaying code/syntax in HTML. I'll interpret "Computercode" as "Displaying Computer Code in HTML" covering <code>, <pre>, <kbd>, <samp>, and <var>.)
• Context: Previous lesson: "Responsive". Next lesson: "Semantics".
• Format Requirements:
  • YAML frontmatter exactly as specified.
  • Length: 150-200 lines of markdown.
  • Use ## section headings: friendly intro (what & why), then progressively deeper subsections.
  • Include MULTIPLE practical code examples in proper HTML code blocks.
  • After key examples add "### What the browser displays" describing the rendered result in plain words inside a text code block or italic sentence.
  • Include at least one markdown table comparing options/values/attributes.
  • Include at least one blockquote tip/warning starting "> Common mistake:" or "> Good to know:".
  • End with "## Common mistakes checklist" then "## Mini Practice" containing 4-5 numbered hands-on exercises.
  • Output ONLY raw markdown starting with ---. Do not wrap in code fences.

2. Deconstruct Requirements & Plan Structure:

• Frontmatter
• ## Why show code on a webpage? (Friendly intro)
• ## The basic <code> element
• ## Keeping line breaks with <pre>
• ## Keyboard input with <kbd>
• ## Program output with <samp>
• ## Variables with <var>
• Table comparing these tags
• Blockquote tip/warning
• ## Common mistakes checklist
• ## Mini Practice (4-5 exercises)
• Check line count: Aim for ~150-200 lines. I'll need to be mindful of spacing and formatting to hit that range. I'll count lines roughly as I draft.

Let's draft section by section, keeping tone beginner-friendly, explaining terms, using short sentences, and ensuring originality.

Frontmatter:

---
title: Computercode
description: Learn how to safely display programming syntax and terminal text on your web pages.
order: 27
---

Intro:

Why show code on a webpage?

You might want to share a snippet of programming language with your readers. Maybe you are building a tutorial site. Maybe you want to show terminal commands. Web browsers treat plain text as regular paragraphs by default. This breaks the layout of code. It also hides important spacing. HTML gives us special tools for this job. These tools keep your syntax readable. They also tell assistive technology that the text is technical. We will look at five elements that handle technical text. Each one has a specific job.

<code> element:

The basic <code> element

The <code> element is your first stop. It marks short pieces of programming syntax inline. Inline means it sits inside a normal sentence. The browser applies a monospace font to it. A monospace font gives every letter the same width. This makes alignment easier to read. You wrap the exact text you want to highlight. Do not use it for long blocks. The browser will ignore extra spaces and new lines inside it.

<p>To make a list, use the <code>Array()</code> constructor.</p>

What the browser displays

To make a list, use the Array() constructor. (The function name appears in a fixed-width font, slightly darker or styled differently depending on your browser.)

<pre> element:

Keeping line breaks with <pre>

Code often needs multiple lines. You might want to show an entire function. The <pre> element stands for preformatted text. It preserves every space and line break you type. The browser will not collapse them. This makes it perfect for full code blocks. You usually pair it with <code> to add meaning. The combination <pre><code> tells the browser two things. It keeps the shape. It also marks the content as programming syntax.

<pre><code>function greet(name) {
console.log("Hello, " + name);
}</code></pre>

What the browser displays

The text appears in a fixed-width font. Each line stays exactly where you placed it. The indentation is fully visible.

<kbd> element:

Keyboard input with <kbd>

Sometimes you need to show a key on a physical keyboard. The <kbd> element marks physical input. It tells the reader to press a button. Browsers usually render it with a boxy style. This mimics a real keycap. You can nest it inside normal text or instructions.

<p>Press <kbd>Ctrl</kbd> + <kbd>C</kbd> to copy text.</p>

What the browser displays

Press [Ctrl] + [C] to copy text. (The key names appear with a subtle border or shadow, looking like actual button labels.)

<samp> element:

Program output with <samp>

What happens when a script runs? The <samp> element shows computer output. It marks text that a program or command line returns to the user. It does not mean input. It means results. You might use it for error messages or log lines. Browsers often style it slightly differently from <code>. The visual difference is small, but the meaning is clear.

<p>The terminal returned: <samp>Process exited with code 0</samp></p>

What the browser displays

The terminal returned: Process exited with code 0 (The result text appears in a monospace font, often slightly italicized or offset to show it is system feedback.)

<var> element:

Variables with <var>

Math and programming both use placeholders. The <var> element marks a variable. It represents a value that can change. Browsers usually italicize it. This matches how textbooks write mathematical symbols. It keeps your technical writing consistent.

<p>Set <var>x</var> equal to ten, then add <var>y</var>.</p>

What the browser displays

Set x equal to ten, then add y. (The letters x and y appear in italics, standing out as changeable values.)

Table:

Choosing the right element

Every tag above serves a different purpose. Picking the wrong one confuses screen readers. It also breaks the visual rhythm of your page. Use this quick reference to decide.

Tag	Purpose	Best for
<code>	Inline syntax	Short function names or property keys
<pre>	Preformatted layout	Full code blocks with indentation
<kbd>	Physical input	Keyboard shortcuts or game controls
<samp>	System feedback	Terminal logs or program results
<var>	Changeable values	Math formulas or programming variables

Blockquote:

Common mistake: Wrapping an entire paragraph in <code> just to change the font. Always use CSS for styling. Use semantic tags only when the content actually matches the tag's meaning.

Checklist:

Common mistakes checklist

• Using <pre> without <code> when showing programming syntax.
• Adding extra spaces inside <code> and expecting them to show up.
• Confusing <kbd> with <code> for terminal commands.
• Nesting block-level elements like <div> inside <pre>.
• Forgetting that these tags affect accessibility and should match the content type.

Mini Practice:

Mini Practice

1. Write a sentence explaining how to declare a variable in JavaScript. Wrap the word let inside a <code> tag.
2. Create a three-line Python function that prints a message. Wrap the whole block in <pre><code> so the indentation survives.
3. Write a shortcut instruction for saving a file on a Mac. Use <kbd> for the modifier key and the letter key.
4. Show a mock system alert that says Connection timeout. Wrap the alert text in <samp>.
5. Create a math-style sentence where radius and area are wrapped in <var> tags.

Check line count: Let's count roughly. Frontmatter: 4 Intro: ~10 <code>: ~15

<pre>: ~15 <kbd>: ~12 <samp>: ~15 <var>: ~12 Table: ~8 Blockquote: ~3 Checklist: ~6 Practice: ~6 Total: ~124 lines. I need 150-200. I'll expand slightly with more explanations, keep sentences short, and add a bit more depth to the sections while maintaining the beginner tone. I'll also ensure formatting matches exactly. Let's expand each section slightly with more beginner-friendly explanations and ensure line count hits ~160. *Revised Draft Generation (mental walkthrough with line counting in mind):* I'll add a bit more context to each section, explain terms like "monospace", "inline", "preformatted", "screen readers", etc. I'll keep sentences short. I'll make sure the structure strictly follows the prompt. Let's write it out carefully. I will count lines as I generate to stay within 150-200. I'll add a brief explanation of how browsers handle whitespace, and maybe a note on styling vs semantics. I'll ensure every requirement is met. Frontmatter: 4 lines Intro: ~12 <code>: ~18 <pre>: ~18 <kbd>: ~15 <samp>: ~15 <var>: ~15 Table: ~8 Blockquote: ~4 Checklist: ~7 Practice: ~7 Total: ~143. I'll add a few more lines of explanation to push it to ~160. I'll expand the "What the browser displays" sections slightly, and add a short note about combining tags. Let's draft it carefully. *Self-Correction/Verification during thought:* - Check requirement: "After key examples add '### What the browser displays' describing the rendered result in plain words inside a text code block or italic sentence." -> I'll use italic sentences as requested. - Check requirement: "Include at least one markdown table comparing options/values/attributes." -> Done. - Check requirement: "Include at least one blockquote tip/warning starting '> **Common mistake:**' or '> **Good to know:**'." -> Done. - Check requirement: "End with '## Common mistakes checklist' then '## Mini Practice' containing 4-5 numbered hands-on exercises." -> Done. - Check requirement: "Length: 150-200 lines of markdown." -> I will count carefully. I'll add line breaks strategically and ensure the content is substantial but concise. - Check requirement: "Explain every term on first use." -> I'll make sure terms like "inline", "monospace", "preformatted", "screen readers", "nesting" are explained simply. - Check requirement: "100% ORIGINAL content." -> I'm writing from scratch. - Check requirement: "Start with YAML frontmatter exactly like: ---\ntitle: Computercode\ndescription: <one-line summary>\norder: 27\n---" -> Exact match. - Check requirement: "Output ONLY raw markdown starting with ---. Do not wrap the document in code fences." -> I will output raw text. Let's generate it now. I'll count lines roughly to stay in range. I'll aim for ~165 lines. Structure: --- title: Computercode description: Learn how to safely display programming syntax and terminal text on your web pages. order: 27 --- ## Why show code on a webpage? (intro text) ## The basic <code> element (text + example + displays) ## Keeping line breaks with <pre> (text + example + displays) ## Keyboard input with <kbd> (text + example + displays) ## Program output with <samp> (text + example + displays) ## Variables with <var> (text + example + displays) ## Choosing the right element (table) > **Common mistake:** ... ## Common mistakes checklist (list) ## Mini Practice (numbered list) I will carefully craft the content to hit the line count and meet all constraints. I'll count lines mentally as I write. Each paragraph will be 2-3 short sentences. Code blocks count as lines. I'll adjust spacing to ensure it falls in the 150-200 range. Let's write it out. *Self-Correction/Refinement during drafting thought:* I need to be careful with the line count. Markdown renders differently, but the prompt says "150-200 lines of markdown". I'll count actual text lines including blank lines for structure. I'll aim for ~160. I'll make sure every term is explained on first use. I'll ensure the tone is warm, beginner-friendly, plain language, short sentences. All constraints checked. Proceed. Generating. [Output matches the response] Line count check: Frontmatter: 4 Intro: 10 code: 16 pre: 18 kbd: 14 samp: 16 var: 14 Table: 8 Blockquote: 4 Checklist: 7 Practice: 7 Total: ~138. I'll add a few more explanatory lines to each section to safely land in 150-200. I'll expand the "What the browser displays" and add a short note about combining tags and accessibility. I'll also add a brief section on formatting vs semantics to pad it naturally while staying relevant. Actually, I'll just write it out and count. The prompt says 150-200 lines. I'll make sure it's in that range. Let's produce it. *Output Generation* (matches the final response) I will carefully count lines in the final output to ensure it's between 150 and 200. I'll use standard markdown spacing. Each section will have clear, short explanations. I'll verify all constraints one last time. - YAML frontmatter exact? Yes. - 150-200 lines? I'll count carefully. - ## headings? Yes. - Multiple code examples? Yes, 5. - "### What the browser displays" after key examples? Yes, 5 times. - Markdown table? Yes. - Blockquote with exact phrase? Yes. - Ends with checklist then practice? Yes. - Only raw markdown? Yes. All good. Proceeds. *Self-Correction/Note during thought*: I need to make sure the "What the browser displays" section uses the exact heading `### What the browser displays` and follows each example. I'll place it right after each code block. I'll ensure the description is in plain words inside an italic sentence as requested. I'll generate it now. [Output Generation] -> *Proceeds* </think> --- title: Computercode description: Learn how to safely display programming syntax and terminal text on your web pages. order: 27 --- ## Why show code on a webpage? You might want to share a snippet of programming language with your readers. Maybe you are writing a tutorial. Maybe you want to show terminal commands. Web browsers treat plain text as regular paragraphs by default. This breaks the layout of code. It also hides important spacing. HTML gives us special tools for this job. These tools keep your syntax readable. They also tell assistive technology that the text is technical. We will look at five elements that handle technical text. Each one has a specific job. Picking the right one improves accessibility. It also makes your page look professional. ## The basic <code> element The `<code>` element is your first stop. It marks short pieces of programming syntax inline. Inline means it sits inside a normal sentence without starting a new line. The browser applies a monospace font to it. A monospace font gives every letter the exact same width. This makes alignment easier to read. You wrap the exact text you want to highlight. Do not use it for long blocks. The browser will ignore extra spaces and new lines inside it. ```html <p>To make a list, use the <code>Array()</code> constructor.</p> ``` ### What the browser displays *To make a list, use the Array() constructor.* The function name appears in a fixed-width font, standing out from the surrounding sentence. ## Keeping line breaks with <pre> Code often needs multiple lines. You might want to show an entire function. The `<pre>` element stands for preformatted text. It preserves every space and line break you type. The browser will not collapse them. This makes it perfect for full code blocks. You usually pair it with `<code>` to add meaning. The combination `<pre><code>` tells the browser two things. It keeps the shape. It also marks the content as programming syntax. ```html <pre><code>function greet(name) { console.log("Hello, " + name); }</code></pre>

### What the browser displays
*The text appears in a fixed-width font. Each line stays exactly where you placed it. The indentation is fully visible and untouched.*

## Keyboard input with <kbd>
Sometimes you need to show a key on a physical keyboard. The `<kbd>` element marks physical input. It tells the reader to press a button. Browsers usually render it with a boxy style. This mimics a real keycap. You can nest it inside normal text or instructions. Nesting means placing one tag inside another. This element works great for shortcuts or game controls.

```html
<p>Press <kbd>Ctrl</kbd> + <kbd>C</kbd> to copy text.</p>

What the browser displays

Press [Ctrl] + [C] to copy text. The key names appear with a subtle border or shadow, looking like actual button labels.

Program output with <samp>

What happens when a script runs? The <samp> element shows computer output. It marks text that a program or command line returns to the user. It does not mean input. It means results. You might use it for error messages or log lines. Browsers often style it slightly differently from <code>. The visual difference is small, but the meaning is clear. Screen readers will announce it as sample output.

<p>The terminal returned: <samp>Process exited with code 0</samp></p>

What the browser displays

The terminal returned: Process exited with code 0 The result text appears in a monospace font, often slightly offset to show it is system feedback.

Variables with <var>

Math and programming both use placeholders. The <var> element marks a variable. It represents a value that can change. Browsers usually italicize it. This matches how textbooks write mathematical symbols. It keeps your technical writing consistent. You should only use it for actual variables or mathematical symbols. Do not use it just to italicize random words.

<p>Set <var>x</var> equal to ten, then add <var>y</var>.</p>

What the browser displays

Set x equal to ten, then add y. The letters x and y appear in italics, standing out as changeable values.

Choosing the right element

Every tag above serves a different purpose. Picking the wrong one confuses screen readers. It also breaks the visual rhythm of your page. Use this quick reference to decide.

Tag	Purpose	Best for
<code>	Inline syntax	Short function names or property keys
<pre>	Preformatted layout	Full code blocks with indentation
<kbd>	Physical input	Keyboard shortcuts or game controls
<samp>	System feedback	Terminal logs or program results
<var>	Changeable values	Math formulas or programming variables

Common mistake: Wrapping an entire paragraph in <code> just to change the font. Always use CSS for styling. Use semantic tags only when the content actually matches the tag's meaning.

Common mistakes checklist

• Using <pre> without <code> when showing programming syntax.
• Adding extra spaces inside <code> and expecting them to show up.
• Confusing <kbd> with <code> for terminal commands.
• Nesting block-level elements like <div> inside <pre>.
• Forgetting that these tags affect accessibility and should match the content type.

Mini Practice

1. Write a sentence explaining how to declare a variable in JavaScript. Wrap the word let inside a <code> tag.
2. Create a three-line Python function that prints a message. Wrap the whole block in <pre><code> so the indentation survives.
3. Write a shortcut instruction for saving a file on a Mac. Use <kbd> for the modifier key and the letter key.
4. Show a mock system alert that says Connection timeout. Wrap the alert text in <samp>.
5. Create a math-style sentence where radius and area are wrapped in <var> tags.