---
title: Phase 1 Markdown Style Showcase
description: Visual review of the Markdown typography, content blocks, tables, feature cards, and Mermaid styling implemented in Phase 1A.
created: 2026-10-29
updated: 2026-10-29
authors: Thinking Cap
topics: [Research Development]
status: published
canonical: https://console.thinkingcap.com/guest/Research-Development/UX/Storybook/Style-sampler
type: article
abstract: A practical test page for reviewing the shared Markdown styles in light and dark modes, including responsive layouts and graceful fallback behaviour.
# hero.variant: auto (default)
icon: palette
category: Design System
publishedat: 2026-10-28
updatedat: 2026-10-28
sharing: true
bookmarking: true
order: 3
---

# Phase 1 Markdown Style Showcase

This page demonstrates the **Phase 1A Markdown content styling**. Review it in both **light and dark modes**, and at desktop, tablet, and mobile widths. It is a *content-style showcase*, not a demonstration of the separately held Console shell redesign or Phase 2 operational components.

## 1. Headings and paragraph rhythm

Headings should establish a clear hierarchy without overwhelming the page. Paragraphs should be comfortable to read, with consistent line height and spacing between blocks.

### H3 — Section within a topic

This paragraph follows an H3. It contains enough text to reveal line wrapping and the vertical rhythm of the article. The purpose is to check that long-form reading feels natural rather than crowded or excessively spaced.

#### H4 — Supporting detail

A supporting paragraph with **strong emphasis**, *italic emphasis*, and ***combined emphasis***.

##### H5 — Smaller subheading

Supporting details can be nested without introducing decorative boxes.

###### H6 — Smallest heading

Even the smallest heading should remain legible and visually distinct from body text.

## 2. Inline text, links, and calls to action

Use **bold** for importance, *italics* for emphasis, and `inline code` for technical identifiers such as `buildTheme` or `theme.semantic`. A normal [Thinking Cap website link](https://thinkingcap.com/) should be recognizable, keyboard-focusable, and readable in both themes.

You can also review an automatic link: https://thinkingcap.com/

> **Review tip:** Use the Tab key to check visible focus indicators on links and interactive controls.

## 3. Standard blockquote

> Good interface design makes the next action obvious without making every element compete for attention.
>
> — Thinking Cap Design Principles

A standard blockquote is distinct from the larger editorial pull quote below.

## 4. Editorial pull quote

```pullquote
The best design system makes consistency feel effortless, without flattening the personality of the experience.

— Thinking Cap Experience Team
```

## 5. Notices and semantic alerts

```note
**Note:** This is a neutral informational message. It can contain **formatted text**, links, and multiple sentences.
```

```notice
**Notice alias:** This should render with the same visual treatment as `note`.
```

```tip
**Tip:** Keep instructional content short, specific, and actionable.
```

```warning
**Warning:** Review changes to shared styles in both light and dark mode before release.
```

```important
**Important:** A shared theme change may affect more than one work surface.
```

```caution
**Caution:** Confirm existing behaviour before modifying operational components.
```

## 6. Code: inline and fenced

Use inline code for names like `MDXContent.tsx`, `remarkFeatureGroups`, and `surface.subtle`.

```ts
interface ThemeReview {
  mode: 'light' | 'dark';
  component: string;
  approved: boolean;
}

const review: ThemeReview = {
  mode: 'dark',
  component: 'markdown-table',
  approved: false,
};
```

```bash
npm run typecheck
npm run build
```

The code frames should show their language labels and **Copy** controls.

## 7. Lists and task lists

An unordered list:

- Clear typography and spacing
- Accessible links and focus indicators
- Responsive layouts without horizontal page overflow
  - Nested item one
  - Nested item two

An ordered list:

1. Review the page in light mode.
2. Review the page in dark mode.
3. Narrow the viewport and verify wrapping.

A task list:

- [x] Review typography
- [x] Review alerts
- [ ] Check the smallest viewport
- [ ] Approve the production presentation

## 8. Compact, banded tables

Both editorial Markdown tables and operational tables use a **compact visual density**. This is an ordinary Markdown table, so it is not expected to provide operational sorting or filtering.

| Component | Phase 1 treatment | Review status |
|:---|:---|---:|
| Headings | Clear hierarchy and rhythm | Ready |
| Links | Underline and visible focus | Ready |
| Alerts | Semantic colours and icons | Ready |
| Tables | Compact cells and subtle banding | Ready |
| Feature cards | Responsive grouping | Ready |
| Mermaid | Theme-aware diagrams | Ready |

A wider table tests responsive horizontal scrolling rather than forcing the whole page wider:

| Content type | Primary presentation | Keyboard expectation | Mobile expectation | Dark-mode expectation | Notes |
|:---|:---|:---|:---|:---|:---|
| Markdown table | Compact banded rows | Readable content | Horizontal scroll if necessary | Clear row contrast | No sorting controls |
| Feature group | Equal-height cards | Links focusable | One column at narrow widths | Legible card surface | Preserve source order |
| Code block | Framed code | Copy button accessible | Code scrolls within frame | Legible syntax | Show language label |

## 9. Images and captions

The image below is an external test asset. If the site's image policy blocks external assets, use an approved local image path instead; that is an asset-policy issue rather than a Markdown styling failure.

![Abstract geometric shapes used to test image sizing and alt text](https://placehold.co/960x400/png?text=Markdown+Image+Preview)

*Figure 1. Example image caption: verify image scaling, caption spacing, and contrast.*

## 10. Standalone feature card

```feature
title: Accessible by default
description: Design decisions should support **readability**, visible focus, and predictable interaction.
icon: universal-access
link: https://thinkingcap.com/
linkText: Explore Thinking Cap
```

## 11. Automatic feature groups and responsive layout

The three adjacent feature fences below should automatically form **one group**. At narrower widths, the cards should rearrange without changing their source order.

```feature
title: Consistent
icon: layer-group
description: Shared content patterns provide a recognizable visual language.
```

```feature
title: Responsive
icon: mobile-screen-button
description: Cards adapt to the available space without awkward overflow.
```

```feature
title: Accessible
icon: eye
description: Contrast, focus, and readable typography remain priorities.
```

A separate group of **five** cards tests the 3+2 layout at wider widths:

```feature
title: One
icon: 1
description: First card in source order.
```

```feature
title: Two
icon: 2
description: Second card in source order.
```

```feature
title: Three
icon: 3
description: Third card in source order.
```

```feature
title: Four
icon: 4
description: Fourth card in source order.
```

```feature
title: Five
icon: 5
description: Fifth card in source order.
```

## 12. Mermaid diagrams

This diagram should render as a theme-aware diagram in the **published Console**. CapCom's authoring preview may display the Mermaid source code, as it did before Phase 1.

```mermaid
flowchart LR
    A[Author Markdown] --> B{Valid content?}
    B -->|Yes| C[Render styled content]
    B -->|No| D[Show safe code fallback]
    C --> E[Review light and dark modes]
    D --> E
```

## 13. Dividers and footnotes

The horizontal rule below should separate sections without creating an unnecessary visual container.

---

This is a short paragraph after the divider. Footnote syntax can be tested here.[^review]

[^review]: Footnote presentation depends on the enabled Markdown parser and renderer configuration; confirm the behaviour in the actual Console.

## 14. Authoring validation and fallback

The following intentionally invalid feature block should **remain visible as code**, rather than produce a broken or partially rendered card:

```feature
title: Missing required description
icon: circle-info
unsupportedKey: this-should-fail-validation
```

Likewise, an unrecognized fenced language should fall back to an ordinary code block:

```unrecognized-example
This block has no registered custom renderer.
```

## 15. Final review checklist

- [ ] Light mode: text, links, alerts, tables, and diagrams have sufficient contrast
- [ ] Dark mode: surfaces and semantic colours remain readable
- [ ] Tables: compact spacing, subtle banding, no page-level overflow
- [ ] Feature groups: one, three, and five-card layouts work at different widths
- [ ] Code: language labels, Copy control, and long-line overflow work
- [ ] Keyboard: focus rings appear on links and controls
- [ ] Invalid custom fences: fail safely to readable code
- [ ] Existing Admin/Guest shell and operational work surfaces remain unchanged