Markdown-syntaksguide — En komplett referanse

Dette er Markdown-syntaksreferansen du kan bokmerke og komme tilbake til. Hvert element dekket med et reelt eksempel — overskrifter, betoning, lenker, bilder, lister, kodeblokker, tabeller, blokkitater og mer. Der en funksjon er en del av standard CommonMark, er den merket som det; utvidelser fra GitHub Flavored Markdown (GFM) er eksplisitt nevnt slik at du vet hva som er universelt støttet og hva som avhenger av rendereren.

Overskrifter

Markdown har to overskriftsstiler. ATX-stilen bruker hash-tegn — ett # for h1 til seks ###### for h6. Setext-stilen bruker understrekninger av =- eller --tegn og når bare h1 og h2. ATX er stilen du bør bruke overalt — den er eksplisitt, skalerer til alle seks nivåer, og er den hvert verktøy støtter. En vanlig feil: å glemme mellomrommet etter #. Strengt tatt er #Overskrift ikke en overskrift i CommonMark — mellomrommet er påkrevd.

# Page Title (h1)
## Section Heading (h2)
### Subsection (h3)
#### Detail Level (h4)
##### Minor Heading (h5)
###### Smallest Heading (h6)

---

<!-- Setext style — only h1 and h2, rarely used -->
Page Title
==========

Section Heading
---------------

I et reelt dokument bruker du typisk ett h1 øverst (dokumenttittelen), h2 for større seksjoner og h3 for underavsnitt innenfor disse. Å gå dypere enn h3 er et signal om at dokumentet kanskje trenger omstrukturering snarere enn et nytt nivå av nesting.

Tekstformatering

Fet bruker doble asterisker eller doble understrekninger. Kursiv bruker enkle asterisker eller enkle understrekninger. Fet-kursiv kombinerer tre av enten. Gjennomstrekning er en GFM-utvidelse og bruker doble tilde. Inline kode bruker backticks.

**Bold text** or __Bold text__
*Italic text* or _Italic text_
***Bold and italic*** or ___Bold and italic___
~~Strikethrough~~ (GFM only)
`inline code`

*- og _-variantene er for det meste utskiftbare, men de skiller seg i ett kanttilfelle: betoning midt i ord. Asterisker fungerer midt i ord (un*believe*able renderes som unbelieveable), men understrekninger gjør det ikke — un_believe_able renderes bokstavelig i CommonMark fordi understrekninger inne i ord behandles som ordtegn, ikke betoningsmarkører. Dette betyr noe i teknisk skriving der understrekninger forekommer i identifikatorer. Som en tommelfingerregel: bruk * for betoning og reserver _ bare hvis du har en sterk stilpreferanse. Ikke bland * og _ innenfor samme betoningsspenn — *tekst_ lukkes ikke korrekt.

Lenker og bilder

Det er tre lenkestiler: inline-lenker, referanselenker og autolenker. Bilder følger samme syntaks som inline-lenker, men med et !-prefiks.

<!-- Inline link: [text](url) or [text](url "title") -->
Read the [CommonMark spec](https://spec.commonmark.org/current/ "CommonMark Specification")
Format Markdown with the [Markdown Formatter](/markdown-formatter)

<!-- Reference link: define the URL separately — cleaner in long documents -->
Check the [GFM spec][gfm] for GitHub-specific extensions.

[gfm]: https://github.github.com/gfm/

<!-- Autolink: angle brackets make a URL or email clickable -->
<https://commonmark.org>
<[email protected]>

<!-- Image: same as inline link but with ! prefix -->
![Project screenshot](./docs/screenshot.png "Dashboard view")
![Alt text for accessibility](https://example.com/logo.png)

Lister

Uordnede lister bruker -, * eller + som punktmarkører. Ordnede lister bruker tall etterfulgt av et punktum. Nest lister ved å rykke inn to eller fire mellomrom. Oppgavelister (GFM) bruker [ ] for uavkrysset og [x] for avkrysset elementer.

<!-- Unordered list -->
- Install dependencies
- Configure environment variables
- Run the dev server

<!-- Ordered list -->
1. Clone the repository
2. Run `npm install`
3. Copy `.env.example` to `.env` and fill in values
4. Run `npm run dev`

<!-- Nested list (indent 2 or 4 spaces) -->
- Backend
  - Set up PostgreSQL
  - Configure connection string
- Frontend
  - Install Tailwind
  - Configure PostCSS

<!-- Task list (GFM) — great for README checklists -->
## Release Checklist

- [x] Unit tests passing
- [x] End-to-end tests passing
- [ ] Changelog updated
- [ ] Docker image tagged
- [ ] Deployment approved

Kode — inline og avgrenset

Inline kode bruker en enkelt backtick på hver side. For blokker bruker du triple backticks (avgrensede kodeblokker) og spesifiserer eventuelt språkidentifikatoren rett etter åpningsbegrenseren — dette aktiverer syntaksmarkering på GitHub, VS Code-forhåndsvisninger og de fleste statiske nettstedsgeneratorer. Du kan også bruke innrykkede kodeblokker (4 mellomroms innrykk), men foretrekk avgrensede blokker: de støtter språkantydninger, de er eksplisitte og de fungerer selv når det omliggende innholdet også har innrykk.

<!-- Inline code -->
Use the `fetch()` API to make HTTP requests.
Set the `Content-Type` header to `application/json`.

<!-- Fenced code block with language hint -->
```python
import json

with open("config.json") as f:
    config = json.load(f)

print(config["database"]["host"])
```

```typescript
interface ApiResponse<T> {
  data: T;
  status: number;
  message: string;
}

async function fetchUser(id: string): Promise<ApiResponse<User>> {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
}
```

```bash
# Install dependencies and start the dev server
npm install
npm run dev
```

```json
{
  "name": "my-project",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build"
  }
}
```

```yaml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
```

Vanlige språkidentifikatorer: python, js eller javascript, ts eller typescript, bash eller sh, json, yaml, html, css, sql, go, rust, java. Forhåndsvis hvordan Markdown-en din renderes med Markdown-forhåndsvisning-verktøyet.

Tabeller (GFM)

Tabeller er en GitHub Flavored Markdown-utvidelse — de er ikke en del av CommonMark-standarden. De fungerer på GitHub, GitLab, de fleste statiske nettstedsgeneratorer og VS Code, men ikke i alle Markdown-prosessorer. Syntaksen bruker pipe-tegn for å skille kolonner og en separatorrow med bindestreker for å markere overskriften. Kolon i separatorraden kontrollerer kolonnejustering.

| Feature              | CommonMark | GFM       |
| -------------------- | :--------: | :-------: |
| Headings             | ✅         | ✅        |
| Bold / Italic        | ✅         | ✅        |
| Fenced code blocks   | ✅         | ✅        |
| Tables               | ❌         | ✅        |
| Task lists           | ❌         | ✅        |
| Strikethrough        | ❌         | ✅        |
| Autolinks            | ✅         | ✅ (ext.) |

Kolonnejustering settes i separatorraden. :--- justerer venstre (standard). ---: justerer høyre. :---: sentrerer. Du trenger ikke å polstre kolonner med mellomrom for å gjøre dem visuelt justerte i kilden — det er kosmetisk og har ingen effekt på den renderte utgangen. Pipe-tegnene i starten og slutten av hver rad er teknisk sett valgfrie i GFM, men å inkludere dem er den klarere stilen.

Blokkitater

Blokkitater prefikser hver linje med >. Nestede blokkitater bruker >>. Du kan inkludere andre Markdown-elementer — overskrifter, lister, kodeblokker — inne i et blokksitat, noe som gjør dem nyttige for callout-bokser i dokumentasjon.

> **Note:** As of Node.js 18, the `fetch` API is available globally
> without importing anything. No more `node-fetch` dependency.

> This is a quote that spans
> multiple lines.
>
> And has a second paragraph.

> Outer quote.
>
> > Nested quote — useful for "quoting a quote" in changelogs
> > or spec discussions.

<!-- Blockquote containing a code block — useful for quoting error messages -->
> The migration failed with:
>
> ```
> ERROR: relation "users" already exists
> ```

Horisontale linjer, linjeskift og escaping

Disse tre funksjonene snubler folk over fordi oppførselen ser ut som en feil inntil du kjenner reglene. Horisontale linjer, hårde linjeskift og backslash-escaping har alle spesifikk syntaks som ikke er åpenbar.

<!-- Horizontal rules: three or more of ---, ***, or ___ on their own line -->
---
***
___

<!-- All three render as <hr>. Most common style is --- -->

<!-- Hard line breaks: end a line with two trailing spaces, or use backslash -->
First line with two trailing spaces
Second line (rendered as a new line, not a new paragraph)

First line with backslash\
Second line (same result)

<!-- A single newline in Markdown source is NOT a line break — it's a space.
     Two newlines = a paragraph break. -->

<!-- Backslash escaping: put  before any Markdown character to render it literally -->
*This is not italic*
# This is not a heading
[Not a link](not-a-url)
`Not inline code`

<!-- Characters that can be escaped -->
\ ` * _ { } [ ] ( ) # + - . !

HTML i Markdown

De fleste Markdown-prosessorer lar rå HTML passere uendret, noe som låser opp en håndfull nyttige mønstre som ren Markdown-syntaks ikke kan uttrykke. Den vanligste bruken i GitHub README-filer er det sammenleggbare <details>/<summary>-avsnittet. Andre nyttige: <kbd> for tastaturgenveler og egendefinerte id-attributter på overskrifter for presise anker-lenker.

<!-- Collapsible section — very common in GitHub READMEs -->
<details>
<summary>Click to expand: Advanced configuration options</summary>

You can override the defaults by creating a `config.local.json` file
in the project root. Supported keys:

| Key        | Default | Description             |
| ---------- | ------- | ----------------------- |
| `port`     | 3000    | Dev server port         |
| `logLevel` | `info`  | One of debug/info/warn  |

</details>

<!-- Keyboard shortcuts -->
Press <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> to open the command palette.

<!-- Custom heading ID for anchor links -->
<h2 id="configuration-reference">Configuration Reference</h2>

<!-- Link to that heading from anywhere -->
See the [Configuration Reference](#configuration-reference).

En viktig advarsel: <details>-blokken krever en tom linje mellom det avsluttende </summary>-tagget og brødtekstinnholdet hvis det innholdet inneholder Markdown. Uten den tomme linjen vil ikke Markdown inne i blokken bli parset — det renderes som rå tekst. Du kan rydde opp i og formatere Markdown-filene dine med Markdown-formateringsverktøyet.

Oppsummering

Det dekker den fullstendige syntaksen — standard CommonMark og GFM-utvidelsene utviklere bruker daglig. For det autoritative ordet om kanttilfeller er CommonMark-spesifikasjonen og GFM-spesifikasjonen begge lesbare dokumenter, ikke bare referansedumper. CommonMark-hurtigreferansen er et hendig enkeltsidessammendrag. Markdown Guide grunnleggende syntaks og utvidet syntaks-sidene er også velorganiserte hvis du vil ha mer prosaforklaring ved siden av eksempler. Når du trenger å se nøyaktig hvordan Markdown-en din vil se ut før du committer, renderes den live i nettleseren din med Markdown-forhåndsvisning-verktøyet. For å rydde opp i inkonsekvent formatering på tvers av et dokument, normaliserer Markdown-formateringsverktøyet overskriftsstiler, listemarkører og avstand. Og for å produsere ren HTML fra Markdown-utdata, forskjønnerer HTML-formateringsverktøyet det Markdown-prosessoren sender ut.