Markdown Rendering Lab

Markdown is easy until you assume every piece of punctuation means what you think it means.

Today you test it instead of guessing.

Build a source specimen

Create markdown-lab.md with examples of:

# Heading 1
## Heading 2

A paragraph with **bold**, *emphasis*, and `inline code`.

- item one
- item two

1. first
2. second

[Visit Jekyll](https://jekyllrb.com)

> A block quote.

```text
A fenced code block.

Build the site.

Inspect generated HTML.

## Map syntax to output

Create a table:

| Markdown | Generated HTML family |
| --- | --- |
| `#` heading | `<h1>` |
| `**text**` | emphasis/strong element |
| list marker | list elements |
| link syntax | anchor element |

Fill the rest from **your generated output**, not memory.

## Controlled ambiguity

Try a malformed or unusual Markdown case in a disposable copy.

Examples:

- missing blank line around a list;
- unmatched emphasis markers;
- code fence not closed.

Record whether:

1. Jekyll fails the build;
2. Markdown renders unexpected HTML; or
3. the browser displays something surprising even though the build succeeded.

Those are different failure classes.

## Why generated HTML matters

If Markdown looks wrong in the browser, inspect `_site` before changing CSS.

If the generated HTML itself is wrong, the issue is likely in source/rendering.

If the generated HTML is structurally correct but the screen looks wrong, presentation CSS becomes a stronger suspect.

## Portfolio action

Use Markdown for at least one content-heavy portfolio page.

Do not convert every page just to say you used Markdown.

Choose it where the authoring format actually helps.

## Evidence checkpoint

Keep:

- the Markdown specimen;
- the generated HTML specimen;
- one malformed example;
- the observed failure class; and
- one sentence explaining why visual browser output alone was insufficient evidence.