From phone to table.One menu.
Two surfaces.

01 / FIELD NOTESThe menu is the destination

The menu items and the business information live in data.ts. React renders that data into the page; the original application uses TypeScript, Vite, Tailwind CSS v4, and a static deployment on a Cloudflare Worker.

The original design pairs a cream background and maple-amber accents with a Playfair Display wordmark. The menu remains the reason for opening the page. The surrounding diner identity gives it context rather than replacing it.

The project page has a small interactive menu example. Its sample dishes and search control are new explanatory material, not evidence of the original menu data or a new feature shipped to the diner demo.

02 / FIELD NOTESThe table card is another presentation

In the original build, the table card is a route on the site with a print stylesheet. The write-up describes opening that page and printing a 4×6-inch card, instead of maintaining a second design file for the same destination.

The composer below is a new authored print example. Change the heading, switch between the screen and card views, and open or save a printable HTML version. It contains a real QR code pointing to the published fictional demo, not to the offline page you are reading.

No scan tracking is added. The controls operate locally; the only external destination is the address encoded in the QR, which someone would have to scan or open deliberately.

03 / FIELD NOTESWhat the original stylesheet tells us—and what it does not

The supplied excerpt shows an @media print rule, an @page block, a .no-print selector, and the .print-card layout. However, it is missing numeric values for the paper size, card dimensions, padding, and border. Those omissions are still present in the retrieved public article.

The surrounding prose specifies 4×6 inches. That does not establish every other missing value. The original excerpt is therefore kept unchanged below, not silently turned into runnable replacement CSS.

@media print {
  @page {
    size: in in;
    margin: 0;
  }
  .no-print {
    display: none !important;
  }
  .print-card {
    width: in !important;
    height: in !important;
    margin: 0 auto !important;
    padding: 0.in !important;
    border: px double #000000 !important;
    page-break-inside: avoid;
    display: flex !important;
    flex-direction: column !important;
    justify-content: space-between !important;
    /* … */
  }
}

The printable example above has its own explicit dimensions and spacing. They are new choices for demonstrating the idea, not recovered values from src/index.css.

As a general implementation note, MDN documents using @media print to change printed styles and @page to set page dimensions and margins. That supports the technique, not a guarantee about a particular printer. The sample still asks you to check paper size, scaling, margins, and QR readability before actual use. Read MDN's printing guide.

04 / FIELD NOTESThe next improvement is the editing workflow

A typed content file keeps the data together, but a diner owner still needs a developer or a code-editing workflow to change it. The original next step was a small CMS or a sheet-backed content source.

The original article also names per-table QR codes and scan analytics as possible future work. The documented card points at the deployed demo; it does not establish that those tracking features exist. The reference deliberately uses one fixed destination and no tracking parameters.

05 / FIELD NOTESKeep the handoff in view

The phone menu and table card are useful because one leads to the other. A polished card with a poor destination is only half a design, and a good menu is less useful when its printed link is wrong.

This build explores that handoff. Before using it for a real business, the remaining work is concrete: approved content, an editing process, a verified destination, and a physical print-and-scan check.