Where your page stands
Right now your draft has a name, an intro with some bold and italic, three hobbies and one link - a talking business card. Text-only pages read fine but scroll past fast. Session 2 adds the things eyes stop for: a picture, a pull-quote, code that looks like code, and your first table. Half of today is also your first taste of GitHub Flavored Markdown - the dialect your page will actually live in.
Pictures and quotes 5 min live
Two elements, one shared idea: both borrow syntax you already know. An image is a link with a ! in front; a quote is a paragraph with a > in front.
LiveImages: a link that shows instead of takes you2.5 min▶
your actual photo, rendered on the page
- Same shape as a link, plus a bang: . The ! is the whole difference - forget it and you get a clickable link instead of a picture.
- Alt text is not decoration - it's accessibility. Screen readers speak it, and it displays whenever the image fails to load. Describe the picture: "Phoebe hiking at sunrise", not "image1".
- The URL must point at an actual image file (.png, .jpg, .gif...), not at a page that contains one. Your GitHub avatar has a permanent one: https://github.com/USERNAME.png.
Why pros sweat the alt text: on a slow connection, GitHub shows the alt text while the image loads - and if the link ever rots, the alt text is all anyone sees. A README full of  with empty alts degrades into mystery gaps; one with real alts still reads like a page. Accessibility and durability, one habit.
LiveBlockquotes: give words a stage2.5 min▶
Ship early, ship often.
Two lines, one quote - every line carries the >.
- One character: start the line with > and it renders as an indented, styled quote block. Anything can live inside - bold, links, even lists.
- The gotcha that gets everyone: a blank line INSIDE a quote must also carry the >, alone on its line. A truly empty line ends the quote, and the second half falls out as a normal paragraph. This is quiz question one - and Demo 3 breaks it live.
- Nesting: >> quotes a quote - the reply-to-a-reply look you know from email.
Self-studyLinked images + an escaping recap2 min read▶
- A clickable image is an image wrapped in a link: [](target-url). Read it inside-out: the image renders, the outer brackets make it a link. Badges in Session 3 use exactly this.
- Escaping recap from Session 1: to show a literal !, > or bracket, backslash it: \> not a quote. The full escapable set is on your Session 1 cheat sheet.
- Image sizing: pure markdown has none. Where you need it (and GitHub allows it), drop to HTML: <img src="..." width="300">. More HTML workarounds in Part 3.
Code that looks like code 4 min live
Even a non-programmer's page mentions technical things - keyboard shortcuts, file names, commands. Markdown gives them a monospace costume so they read as "type this exactly", two ways: inline and block.
LiveInline code: backticks around the words1.5 min▶
Press Ctrl+S to save, then run git status to check.
- The backtick ` is the key next to 1 (not an apostrophe!). Wrap file names, shortcuts, commands, anything meant literally: `README.md`.
- Bonus power: inside backticks, markdown is OFF. `**not bold**` shows the stars - handy for writing ABOUT markdown.
LiveFenced code blocks: three backticks build a wall2.5 min▶
a shaded block, colored by language
- Open with ``` on its own line, close with ``` on its own line. Everything between renders exactly as typed - spacing, stars, hashes, all literal.
- Name the language after the opening fence - ```python, ```sql, ```html - and renderers that support highlighting color it. The info string is standard CommonMark; whether colors actually appear is up to the renderer. GitHub: yes.
- An unclosed fence swallows the rest of your page. If everything below a code block suddenly turns monospace, you forgot the closing ```. Demo 3 does this on purpose.
The most-typed markdown at work: pasting an error into a chat or GitHub issue inside a ``` fence. Unfenced, the error's underscores and brackets get mangled into italics and links; fenced, it arrives character-perfect and the person helping you can actually read it. People notice who fences.
Self-studyThe old way, and backticks inside backticks2 min read▶
- Indented code blocks: before fences existed, indenting a line 4 spaces made it code - which is exactly why Session 1 warned you never to indent paragraphs. You'll meet this in older documents; write fences yourself, they're clearer and they take a language name.
- A literal backtick inside inline code: wrap with DOUBLE backticks: `` a ` inside ``. Rare, but unforgettable once you've needed it.
- Code inside a list item: a fence works, or indent the code 8 spaces (4 for the list nesting + 4 for code).
Tables and checklists - your first GFM 5 min live
Milestone moment: everything until now was core markdown that works everywhere. Tables and task lists are extended syntax - GitHub Flavored Markdown (GFM). Not every app renders them, but GitHub does, and GitHub is exactly where your page lives. Welcome to the dialect of your new home.
LiveTables: pipes for columns, dashes for the header line2.5 min▶
| Skill | Level |
|---|---|
| Excel | strong |
| Python | learning |
- Three rules: pipes | separate columns, row one is the header, and row two MUST be dashes (---, at least three per column). No dash row, no table - just a paragraph full of pipes. The #1 table bug.
- Columns don't need to line up in the source. Ragged pipes render as a perfect grid - the renderer does the alignment, not you. (Lining them up anyway is a kindness to whoever reads the raw file.)
- A literal pipe in a cell needs escaping: \|.
LiveColumn alignment: colons steer the dashes1 min▶
Add colons to the dash row to control each column: :--- left, :---: center, ---: right. Memory hook: the colon is a magnet - the text sticks to its side.
| :--- left | :---: center | ---: right |
|---|---|---|
| words | levels | 1,240 |
Right-align number columns and they read like a spreadsheet; center short status words. Small touch, instantly more professional.
LiveTask lists: checkboxes that render for real1.5 min▶
- Markdown basics
- Tables and checklists
- Go live on GitHub
- A regular list item plus brackets: - [ ] unchecked, - [x] checked. The space inside the empty brackets matters.
- On GitHub these are real checkboxes - in issues you can click them; on your profile they render as a live progress list. A "currently learning" checklist with one box already ticked says more about you than a paragraph could.
Self-studyTable limits, strikethrough, and two small traps3 min read▶
- What table cells CANNOT hold: headings, lists, blockquotes, code blocks, horizontal rules - block elements don't fit in cells. Bold, italic, links, inline code are fine.
- The HTML workaround: need a line break inside a cell? <br>. Need a list-ish cell? item one<br>item two. Beyond that, consider whether it should be a table at all.
- Strikethrough: ~~like this~~ renders
like this- also GFM. Fun on a learning list: ~~fear of markdown~~. - Task-list trap: a task starting with an open parenthesis needs an escape: - [ ] \(Optional) stretch goal.
Milestone 2 of 4 1 min live
Same file, second growth spurt. After today's demos your page has a face, a voice, and data - halfway to shipping.
Add your photo and a quote you live by ★ 7 min · everyone builds
Open stackedit.io/app and bring back your Session 1 draft (paste it in if you saved it elsewhere - it's just text).
Right under your # Name heading, add your photo: . Easiest URL: your GitHub avatar at https://github.com/USERNAME.png - or any image address you like. Watch it appear in the right pane.
Write REAL alt text - describe the picture as you'd describe it to someone on the phone. This is the accessibility habit, formed on day one.
Add a new section: ## Words I live by (blank lines around it!), then your favorite quote as a blockquote: > the quote. Add an attribution line below it, also starting with >, and keep the > on the blank line between them.
Read the right pane. A page with a face and a voice already feels like a profile, not a form.
Build your skills table and learning checklist ★ 10 min · everyone builds
New section: ## Skills. Take the 4-6 skills you collected for homework and give the table its skeleton first - header row, then the dash row: | Skill | Level | Notes | over | --- | --- | --- |. Watch the right pane: no table yet? Check the dash row.
Add one row per skill: | Excel | strong | my home turf |. Don't fuss over lining up the pipes - the renderer aligns everything for you.
Steer the columns: make Level centered with :---: in its dash cell. If you had a numbers column, ---: would right-align it.
New section: ## Currently learning. Three task-list items: - [x] Markdown basics (earned it!), then two - [ ] boxes for what's next.
Discernment lap: does the Notes column earn its place? Would a shorter table read better? Tables are for scanning - trim until they scan.
Skim the READMEs of people you admire on GitHub: the ones that stick use a small table or checklist near the top - skills, current projects, "now learning". Recruiters and collaborators scan those in seconds. Your table today is that exact asset, and Friday-you will thank Wednesday-you for the checked first box.
Break it on purpose, round two ★ 5 min · follow along
In your quote, delete the > from the blank line between quote and attribution. Watch the quote split - attribution falls out as a plain paragraph. Put the > back, watch it rejoin.
Delete your table's dash row. The whole table collapses into one sad paragraph of pipes. Restore the dashes - at least three per column - and the grid snaps back.
Delete the closing ``` of a code block and watch it swallow everything below it into monospace. Close the fence, page restored.
Say each diagnosis out loud: quote split = blank line lost its > · pipes showing = dash row missing · page went monospace = unclosed fence. That's the whole Session 2 debugging kit.
This week ◐ 30 min total
- Finish the new sections if the session ran short: photo with real alt text, quote block, skills table, learning checklist. Your draft should now scroll like a real profile.
- Run CommonMark tutorial lessons 8-10 at commonmark.org/help/tutorial - images, code, and nested lists, interactive, about 5 minutes.
- Go window-shopping: browse three real GitHub profile READMEs at awesome-github-profile-readme. You can now READ their source - notice how much is just today's and last week's elements.
- Bring a steal list to Session 3: note 2-3 things you saw and want - badges? emoji? a stats card? a diagram? Session 3 is exactly that shopping trip.
Three questions before you go 🎯 ◐ 90 seconds
1 · Your two-line blockquote keeps splitting in half. What's the classic cause?
A truly empty line ends a blockquote. Keep multi-part quotes together by putting a lone > on the blank line - the gotcha from Demo 3.
2 · You paste your beautiful skills table into another app and see raw pipes. Why?
Core markdown works everywhere; tables and task lists are GitHub Flavored Markdown extras. Your page lives on GitHub, so you're safe at home - but check before assuming elsewhere.
3 · What is the alt text in  actually for?
Alt text is accessibility plus a safety net: it's what blind and low-vision readers hear, and what everyone sees if the image link ever breaks. Write it like a description, not a label.
Official sources covered
This session teaches the working content of the canonical materials: the interactive tutorial at commonmark.org, the basic and extended syntax references at markdownguide.org, and GitHub's own writing and formatting docs.