tanghoong design

tanghoong.com — visual identity

This is what tanghoong looks like.

One green. One typeface. One set of rules — and every property carrying the name inherits all three. The mark, the colour, the spacing, the way a thing moves when you touch it: decided once, written down here, and reused until it is unmistakable.

  • 9 CSS files
  • 1 token set
  • 2 themes
  • 0 webfonts
  • No build step

Building with an agent?

Give it /llms.txt and skip these pages entirely.

It is the whole system as one plain-text file — every token with its real value, the full class vocabulary, the layout rules, and the traps that have already cost a day to find. One fetch, no crawling, and it is maintained alongside the CSS rather than written about it. The pages you are looking at are the human documentation; that file is the machine one.

Starting a whole sub-domain rather than a page? The template has the header, footer, nav sheet, theme toggle and meta block already wired — the details that go wrong when rebuilt by hand are the ones you cannot see.

Four rules the whole system rests on

Break these and a page stops looking like it belongs.

  1. Every value comes from a token

    No literal hex, px, radius or duration outside tokens.css. If a value you need does not exist, add it to the token file — do not inline it.

  2. Four surfaces, three inks, one accent

    Page, sunken, elevated, glass. Text, text-2, text-3. One accent, used sparingly enough that it still means something.

  3. Spacing belongs to the container

    Sections own vertical rhythm; grids own gaps. Components should not carry outer margins.

  4. Native elements first

    <dialog>, <details>, real <label>s. You inherit focus management, keyboard handling and assistive-tech support for free.

Reference

Each page is a live specimen with the markup beside it. Copy from the page, not from memory.

Where the rules came from They were read back out of cv.tanghoong.com, which was simply the most finished surface at the time — the identity existed there before it existed anywhere else. That direction is now reversed: this is the source, and the CV follows it like everything else.

Using it in a new project

Copy assets/css/ into the new repo and link the files in this order. Order matters: tokens must resolve before anything references them, and utilities must come last so they can win.

Link order
<link rel="stylesheet" href="/assets/css/tokens.css">
<link rel="stylesheet" href="/assets/css/base.css">
<link rel="stylesheet" href="/assets/css/layout.css">
<link rel="stylesheet" href="/assets/css/components.css">
<link rel="stylesheet" href="/assets/css/forms.css">
<link rel="stylesheet" href="/assets/css/overlays.css">
<link rel="stylesheet" href="/assets/css/content.css">
<link rel="stylesheet" href="/assets/css/utilities.css">

Drop any layer the project does not use. docs.css is for this site only — never ship it.

Theme init — inline in <head>, before the stylesheet
<script>try{var t=localStorage.getItem('th');
if(t==='light'||t==='dark')document.documentElement.dataset.theme=t;}catch(e){}</script>

This must stay inline and must run before the CSS loads, or the page paints the wrong theme for a frame. It is the one script that cannot be deferred.