#Documentation

Everything the web part does, and how to configure it.

#Install

Download markstrata.sppkg from the latest release.

1. Upload it to your tenant App Catalog (/sites/appcatalog, the Apps for SharePoint library).
2. When prompted, choose Enable this app and add it to all sites, or leave it unticked and add it per site from Site contents → New → App.
3. Edit a page, add a web part, and pick Markstrata from the Content group.

To build the package yourself you need Node.js 22:

npm installnpm run package          # writes sharepoint/solution/markstrata.sppkg

#Where the content comes from

The Content page of the property pane offers three sources.

A library file is usually the right answer: the markdown stays in SharePoint where it can be versioned, permissioned and edited by people who never touch the page.

#Appearance

Theme: GitHub, Obsidian or VS Code.

Colour mode: light, dark, or follow the page, which takes its cue from the SharePoint site theme so a dark intranet gets a dark web part.

Let readers switch theme: adds a control to the rendered page. A reader’s choice is remembered per web part in their own browser and never changes what anyone else sees.

Content width, spacing and text size: independent of theme, so you can run GitHub’s look at a narrower measure or a larger size without editing anything.

#Code blocks

```typescript title="ThemeManager.ts"export function resolveMode(mode: ColorMode): ResolvedMode {  return mode === 'light' || mode === 'dark' ? mode : 'light';}```

• Syntax highlighting for around forty languages, including PowerShell, Dockerfile, batch and HTTP on top of the common set.
• An optional header showing the language and, with title="app.ts", a filename.
• A copy button that copies the source and never the line numbers.
• Optional line numbers in a gutter that stays put while a long line scrolls under it, and that wrapped lines indent past rather than run under.
• Diff blocks tint whole lines, so + and - read at a glance.

Any block can override the page setting on its fence:

#Callouts

Three syntaxes, one rendering, so markdown written for GitHub, for Obsidian or for an older SharePoint web part all render correctly without editing.

> [!NOTE]> GitHub alert syntax: NOTE, TIP, IMPORTANT, WARNING, CAUTION.> [!tip] Obsidian callout with a title of your own> Types: note, abstract, info, todo, tip, important, success, question,> warning, caution, failure, danger, bug, example, quote, and their aliases.> [!warning]- Foldable, collapsed by default> `-` starts collapsed, `+` starts open.> Wiki.js classes still render.{.is-info}

Foldable callouts are a <details> element, so they need no JavaScript, work with a keyboard, and print expanded.

#Also rendered

Tables (including colspan, rowspan and alignment), task lists, footnotes, definition lists, abbreviations, emoji, sub/sup, ==highlighted== text, heading anchors, Mermaid diagrams themed to match the page, and KaTeX maths.

flowchart LR
  A[Markdown in a library] --> B[Markstrata]
  B --> C[GitHub]
  B --> D[Obsidian]
  B --> E[VS Code]

#Images

![Alt text](path/to/image.png "Optional title") works the way it does on GitHub. A relative path is resolved against the folder holding the markdown file, not the page the web part sits on, so a document library laid out like this renders as written:

Shared Documents/runbooks/  deploy.md          <- ![Flow](images/flow.png)  images/flow.png

Absolute URLs, protocol-relative URLs, data URIs and paths that already start with / are left untouched. Content typed into the web part has no folder of its own, so its relative paths resolve against the site root.

Images are given loading="lazy" and decoding="async", so a long document fetches them as the reader reaches them rather than all at once.

#Table of contents

Built from the headings, or placed inline with [[toc]]. It can sit in a left or right column, above the content, or be switched off, and its depth is configurable.

It is a column of the layout or a block above the text, never an overlay, so it cannot cover the content or the page’s own editing controls. In a narrow column it collapses to a single line you can expand, and while the page is being edited it stops sticking to the top of the screen. The entry for the heading you are reading is highlighted as you scroll.

#Editing in the page

Put the page in edit mode and the web part becomes a split editor: markdown on the left, live preview on the right, with Edit / Split / Preview layouts. If the content came from a library file, Save to SharePoint writes it back, warning you first if someone else has saved it since you opened it. Ctrl+S saves.

It is a plain textarea rather than Monaco, deliberately: it always loads, and a large editor bundle is hard to justify for the short edits that happen on a SharePoint page.

#Defaults

A web part you have just added starts on the VS Code theme in light mode, comfortable width, compact spacing, contents above the content, and line numbers on. Raw HTML is off. Every one of those is a setting.

#Security

npm audit --omit=dev reports no advisories: nothing that ships to the browser has a known vulnerability.

#Going further