Style Guide

I started this from Tom Sachs’s COLOR Hex Codes, then widened it into a portable reference for my sites, tools, documents, and generated artifacts.

This is not meant to describe every mechanic of this site. It is meant to describe the taste I want to carry between projects: readable text, practical interfaces, notebook-like references, strong links, and bright colors used with restraint.

For a demonstration of these styles in action, see the test post/page.

Principles

Readable first. Body text should sit in a comfortable measure, usually around 65-75 characters per line. A reader should not need to move their head across the page to read a paragraph.

Native by default. Use standard browser elements before inventing custom controls. Links should look like links. Buttons should be buttons. Details should disclose details. The browser has already done a lot of accessibility and usability work.

Notebook-like, not app-like. Prefer references, timestamps, labels, symbols, and plain links over glossy chrome. The interface should feel archival and useful, like a working notebook that can be cited later.

Dense but breathable. I like pages that carry a lot of information, but not pages that feel cramped. Use whitespace, borders, and rhythm before adding cards, shadows, or panels.

Light and dark are both required. A new site or tool should work in both modes from the beginning. Dark mode is not an optional inversion pass at the end.

Text is the interface. Most navigation and explanation should happen through headings, links, lists, labels, and metadata. Icons and colors can help, but they should not carry the whole meaning.

Colors

This is the default palette. I use these colors as a starting point, then adjust them to fit the requirements of the interface.

Color	Reference	Hex	Image
Red	ANSI Safety Red	#bd2024
Orange	ANSI safety orange	#FF7900
Yellow	Kodak yellow (Golden Acrylic Diarylide yellow, #1147-6, series 6)	#FFCC00
Green	ISO 3864 safety green	#237F52
Dark Green	Olive Drab #7	#3C341F
Blue	International Klein blue	#002FA7
Purple	HTML standard mediumpurple	#9370d8
Josh Purple	Brand purple	#903465
Black	Near Black	#0D0D0D
White	White	#FFFFFF

Use the named colors semantically when possible:

• Red for danger, destructive actions, errors, and warnings that require attention.
• Orange for caution, pending states, and temporary alerts.
• Yellow for highlights, attention, and annotation.
• Green for success, safety, growth, and positive status.
• Blue for links, references, and navigable paths.
• Purple for identity, emphasis, and connective tissue.
• Black and white for the main reading surface.

Do not rely on color alone. Pair color with text, shape, position, or another cue.

Color Modes

Every interface should define both light and dark modes. Start with tokens instead of hard-coded colors:

--c-bg
--c-bg-alt
--c-text
--c-text-alt
--c-link
--c-link-visited
--c-border
--c-button
--c-red
--c-orange
--c-yellow
--c-green
--c-blue
--c-purple

Light mode should be bright, plain, and readable. Dark mode should be intentionally tuned, not generated by simply inverting colors.

Check both modes for:

• Body text contrast.
• Link and visited-link contrast.
• Border visibility.
• Code block readability.
• Table row distinction.
• Chart legibility.
• Focus states.
• Disabled and secondary text.

Screenshots, charts, diagrams, and generated artifacts should also be usable in both modes when they are part of an interface.

Typography

Fonts were originally explained here, but to repeat:

• Use IBM Plex Sans for body text.
• Use IBM Plex Sans Condensed for title text, labels, and compact headings.
• Use Berkeley Mono for monospace and source-code text.
  • Fallback: IBM Plex Mono, when Berkeley Mono is not readily available.

Use type contrast through family, casing, spacing, and placement more than through large size jumps. Headings often work better as labels and section dividers than as oversized billboards.

Good defaults:

• Body text: regular weight, generous line height, constrained measure.
• Headings: condensed, often uppercase, slightly tracked.
• Captions and metadata: smaller, quieter, still readable.
• Code: monospace, visibly distinct, never fake-small.

Layout

Constrain prose. A good default is max-width: 70ch for paragraphs and ordinary text. This keeps reading comfortable across devices.

Allow useful exceptions. Tables, code blocks, charts, images, maps, and media may need more width. Let those objects break out when the extra space improves comprehension.

Use whitespace as structure. Prefer spacing, rhythm, and simple borders before adding cards or heavy containers.

Use durable units. ch, rem, and line-height-derived spacing often make better layout units than arbitrary pixels because they respond to text.

Links

Links are the main interface. They should be visible, generous, and useful.

• Use links for navigation and references.
• Use buttons for actions.
• Preserve visited-link styling where possible. The web should remember where a reader has been.
• Make hover and focus states obvious.
• Prefer text links over icon-only controls.
• Link generously to sources, documentation, related work, and definitions.

A dense page of links can be good when the labels are clear. Hiding links behind icons or vague buttons usually makes the page worse.

Editorial Voice

Use the tone of a knowledgeable peer sharing practical notes. Be direct, personal, accessible, and useful.

• Write in first person when appropriate.
• Lead with the question, anomaly, result, or useful thing. Do not start with background unless the background is the hook.
• Prefer concrete examples over abstract claims.
• Keep paragraphs short and focused.
• Use clear titles and headings.
• Explain uncommon terms or link to definitions.
• Avoid hype.
• Avoid complaining without offering a path forward.
• Use AI to make things clearer, not longer.
• Do not use em dashes. Use hyphens or semicolons.

For longer prose guidance, use the tone prompt.

Notebook Symbols

Small symbols can make an interface feel like a notebook or archive. Use them as stable reference marks, not decoration.

Pair symbols with text when the action matters. Symbols should reward repeat readers, not confuse first-time readers.

Content Components

Use ordinary web primitives well.

Headings should create clear sections. They can be compact and label-like rather than large and promotional.

Lists should make scanning easier. Use bullets for related items and numbers for ordered steps.

Blockquotes should feel citation-friendly. Keep them plain, bordered, and clearly separate from the surrounding prose.

Code should use monospace text, language labels when useful, and copy controls when practical. Inline code should be visibly distinct without disrupting the sentence.

Tables should be dense, bordered, and readable. Use them when exact lookup matters. Make them responsive before they become unreadable.

Figures should include captions when the image needs context. Captions should be quieter than body text.

Details and summary elements are good for optional context, filters, settings, and advanced controls. Keep the summary label clear.

Footnotes are useful for side context and archival notes. Do not hide essential information in them.

Charts should use the palette, plain typography, and direct labels where possible. Use a chart when shape matters. Use a table when exact values matter.

Buttons and Forms

Whenever possible, use the basic browser implementation of buttons, inputs, links, details, selects, and textareas. If you customize these elements, do so with caution and with testing.

Good defaults:

• Inputs should have visible labels.
• Buttons should describe the action.
• Error messages should be plain language and recoverable.
• Required fields should be obvious.
• Focus states should be visible.
• Settings can often live inside details instead of a custom panel.

Keep forms boring unless the task itself requires something special.

Small Tools

For personal tools and prototypes, start with a small, durable interface:

• One main task per page.
• One readable column by default.
• Plain inputs and buttons.
• Clear source, timestamp, and permalink when output may be reused.
• Settings hidden behind disclosure until needed.
• Static HTML or progressive enhancement when possible.
• No dashboard unless there are multiple live signals to compare.

A tool should feel like a useful page first and an application second.

Accessibility

Accessibility is part of the style, not an afterthought.

• Support keyboard navigation.
• Use visible focus states.
• Maintain sufficient contrast in light and dark modes.
• Let text zoom without breaking the page.
• Keep links visually identifiable.
• Use useful alt text for informative images and empty alt text for decorative images.
• Prefer native controls.
• Respect reduced-motion preferences.
• Do not encode meaning only in color, icon, or position.