/* * Ported from the vendor parent theme: * wp-content/themes/photome/css/reset.css (ThemeGoods "Photome" v5.7.2). * Loaded unconditionally on every front-end page load via * wp_enqueue_style("reset-css", .../css/reset.css", ...) (functions.php, * pp_enqueue_front_page_scripts()), first among the theme's own stylesheets * (before wordpress.css, animation.css, screen.css, grid.css). * * None of the original reset rules use any left/right-style property (no * margin-left/right, padding-left/right, border-left/right, text-align, or * bare left/right position offsets appear anywhere in this file) - there is * nothing here that a CSS logical property would apply to. * * Because this file loads first, it's also the natural home for this ported * design system's shared CSS custom properties ("design tokens") - not * present in the original vendor file. These alias the small set of colors * that recur dozens of times across screen.css and wordpress.css, so a * future maintainer (or a future Kirki-driven customizer field) has one * place to see/change them. This is a pure aliasing operation: each token * is set to the exact literal value already used at every one of its call * sites, so substituting var(--token) for the literal changes nothing about * how anything renders - see screen.css's and wordpress.css's own header * comments for exactly which literals were replaced with which token and * how many times. * * Per this project's own established pattern for Kirki-sourced values * (wp-content/themes/photome-child/header.php sets `style="--logo-src: url(...)"` * inline per-request from a theme_mod, consumed via var(--logo-src) in * css/site-logo.css) - these :root tokens are the natural next place a * future functions.php could plug live Kirki customizer values into, by * overriding one of these custom properties via an inline style on * or instead of duplicating Kirki's current pattern of writing whole * ad hoc override rules into templates/custom-css.php. Not wired up to * Kirki that way yet (a separate, larger change) - this just prepares the * CSS side of that pattern. */ :root { /* Design tokens ported out of repeated literals in screen.css / wordpress.css. */ --color-white: #fff; /* screen.css: 119x "#fff" + 5x "#ffffff"; also this file's own ::selection color in wordpress.css */ --color-border: #e1e1e1; /* screen.css: 52x - the theme's near-universal hairline border/divider gray. Matches tg_hr_color's code-declared default exactly (customizer.lib.php) - not live-checked against production's actual saved value the way --color-body-text is below, since a matching default isn't proof Kedyn hasn't changed it; worth a quick wp.customize('tg_hr_color').get() check the next time the Customizer is open. */ /* * ACCENT DECISION 2026-08-23 (Kedyn, via the Ballot artifact): the stock * template gold #efc337 is retired in favor of a MUTED wordmark sienna - * the orange family already in his hand-lettered logo, desaturated to * "option 3 quietness" per his exact instruction: "we dont want these * colors to be shouting." * * Three-value family, all chosen against real contrast math: * --color-accent #92573b core; white/cream text on it = 5.4:1 (AA) * --color-accent-deep #77452e hover/active darkening of the core * --color-accent-dark #c48f6a the SAME sienna lifted for dark grounds * (pswp lightbox, darkroom surfaces) where * the core would read muddy * Cutover pairs with a Customizer flip (link color #030044 -> sienna, * nav hover slate -> neutral) - tokens alone don't move Kirki-driven * colors; see the token docblock above. */ --color-accent: #92573b; --color-accent-deep: #77452e; --color-accent-dark: #c48f6a; /* The warm limestone loading tone, promoted from 4 scattered literals (portfolio-grid.css x2, blocks.css, ten-years-later-galleries.css) to the site's designed paper surface - Field Plan Phase 1. */ --surface-warm: #edebe7; /* * One reading measure, Field Plan Phase 1 (2026-08-23): replaces three * independent prose max-widths (contact intro 520px, homepage statement * 640px, content-bg-image teaser copy 720px) that agreed with nothing. * 640px sits close to the Lato/Work Sans body-font ~75-character-per- * line ideal at the site's 16-17px body sizes. The contact FORM's own * 680px wrapper is a layout width, not a prose measure - deliberately * left alone. */ --measure-reading: 640px; --shadow-soft: rgba(0, 0, 0, 0.1); /* screen.css: 29x - the theme's most common drop-shadow/overlay tint */ --shadow-strong: rgba(0, 0, 0, 0.6); /* screen.css: 16x - the theme's second most common drop-shadow/overlay tint */ /* * Semantic type tokens (font-family-body/-heading, font-size-body, * color-body-text/-heading-text, heading-letter-spacing, button-*): part * of PARENT-THEME-FORK-PLAN.md §8.9's design-modernization phase - see * docs/specs/DESIGN.md for the real-value extraction these come from. * Same pure-aliasing rule as the color tokens above: each value here is * the exact literal already rendering today, so substituting var(--token) * changes nothing about how anything renders. Intentionally NOT deriving * a spacing-scale token set here - DESIGN.md explicitly found no such * system exists yet ("don't infer one from the button padding... that's * one component, not a system") - only the one real, existing * button-padding value is tokenized below. * * A general trap worth flagging for anyone touching Kirki fields in * customizer.lib.php: grepping theme PHP for a kirki_get_option()/ * get_theme_mod() call is not sufficient to prove a field's value is * still the CSS stock default. Any Kirki field configured with a * top-level 'output' array (tg_body_font_size and tg_header_font both * are) has its live value generated and printed by Kirki itself, straight * from the field config, entirely independent of whether the theme's own * PHP ever reads it back out. Concretely: --font-size-body's real, * currently-live value is 16px (a Kirki override, confirmed via * getComputedStyle() on a real page and Kirki's own generated