Style guide
The live type scale, color tokens, and spacing system pulled from globals.css — how the site looks. The editorial guide at the end documents how it reads. This page is the system's self-documentation and a visual-regression reference.
Headings
Display emphasis
One family ships: IBM Plex Sans for display, standfirst, labels, and body. Inside .h1–.h3 the one emphasis available is strong (bold). A headline gets at most one bold emphasis.
Subheads
Body copy
Body copy is IBM Plex Sans at a fluid size. Inline strong, emphasis, and links inherit the running color with an underline-color shift on hover.
Small print — captions, footnotes, secondary detail.
Spacing scale
All spacing derives from --base: clamp(4px, 0.5vw, 16px). Multiply by a fixed factor. At 1440px viewport, base ≈ 7.2px.
Class naming: .padding--80 = base×10, .margin-top--24 = base×3. The number reflects an 8px reference unit. Actual spacing scales with the viewport.
Color tokens
Every value below is read out of the :root block in globals.css when the page builds, so this table cannot drift from the stylesheet it documents. Click any swatch to copy the variable. Contrast ratios are measured against --white (#fefefe).
Palette — what the value is
Five base colors supply the role tokens used by components.
Functional
Already role-named, and outside both tiers. Accent and selection colors can change on :root at runtime per case study.
Role — what the value is for
The tokens components use. A plain alias points at a palette value; an -rgb orphan is an off-palette ink that only ever appears at partial alpha, so it's stored as a channel triple and used as rgb(var(--token) / N%). Orphans are named, never snapped onto the nearest palette value — merging them would change pixels.
Interaction states
Global transition timing: --transition: 0.15s. All interactive elements carry cursor: pointer and a color/opacity shift on hover.
Default link — resting underline uses --light; hover and focus deepen it to --gray. Text color stays inherited; only the underline shifts.
Editorial guide
The writing aims to make my experience easy to understand: specific work, accurate attribution, and clear descriptions of my contribution.
Lead with the work. Describe what I contributed, the tools I used, and the context a reader needs. Keep claims tied to experience I can support.
Make the page easy to read. Use descriptive headings, short paragraphs, and natural technical language. Keep employment, education, and creative credits consistent across the site.
- No wall paragraphs. Target two to four sentences, one idea each. Five or more is a wall — split it at its natural beat.
- Section on real turns. A header marks a shift in phase, question, or time — not decoration. A short essay wants three to six, not ten.
- One emphasis per section. A single bold line on the thesis stays scannable; bolding everything makes nothing stand out.
- Assets earn their place. A figure goes in when it shows what prose can't. Two or three strong visuals beat six decorative ones.
- Lists over inline runs. Three or more parallel items become a list, not a buried sentence.
The test: skim at reading speed. If your eye slides off a gray block, split it; if a header or image hits every screen, pull some back.
I develop full-stack features for an internal technology governance platform, and my work also includes Java services and SQL data workflows, along with tracing data issues across the application and helping validate production releases, so the role spans both feature development and the support work that follows a release.
I develop full-stack features, Java services, and SQL data workflows for an internal technology governance platform.
I also trace data issues across the application and help validate production releases. My role spans feature development and production support.