/* ═══════════════════════════════════════════════════════════════════════════
* BAS Dashboard — SHARED COMPONENT LAYER
*
* 🔴 THIS IS THE ONLY PLACE A FORM CONTROL, BUTTON, CARD, TABLE OR PILL IS
* DEFINED. Feature pages use these classes. They do not redeclare them.
*
* Why this exists
* ───────────────
* Amy, 2026-09-11: "we can't keep having these new features make up their own
* design decisions… so we aren't generating style sheets millions of miles long."
*
* She is right, and the old rule caused it. Feature pages were told to take a
* 2-3 letter prefix and re-declare the same rules inline, on the grounds that
* LiteSpeed defers enqueued assets on standalone dashboard pages. By the time
* that rule was written the shell had ALREADY solved the timing problem:
* BAS_VM_Dashboard_Shell::render_head_css() enqueues dashboard-shell.css and
* calls wp_print_styles() itself at wp_head priority 99, so the lands in
* with a version cache-buster and none of LiteSpeed's deferral applies.
* Nobody propagated that to feature pages, so we grew seven identical copies of
* one input rule across .bas-pe .bas-pl .bas-st .bas-ol .bas-pp .bas-ms .bas-pc.
*
* This file is printed by the same mechanism, immediately after the shell sheet,
* on every dashboard page. A feature page's own stylesheet should now contain
* ONLY layout that is genuinely unique to it.
*
* Rules for anyone adding to this file
* ────────────────────────────────────
* 0. 🔴 IF A SHARED SCRIPT EMITS A CLASS, IT IS DEFINED HERE — never in the
* template of whichever page was built first. scripts/bas-pricing.js draws
* the recipe card for two pages; its CSS sat inline in the Pricing
* Calculator's template, so the other page rendered grey blocks for six
* weeks while the page that owned the CSS looked fine. And no colour,
* border, radius or padding inside a JS template string: a hex baked into
* a template literal cannot be reached from here and will not follow dark
* mode. Width is layout and may stay inline. (See BAS-DESIGN-SYSTEM.md,
* "The two gaps this rule keeps falling through".)
* 1. If two feature pages would both want it, it belongs here.
* 2. Values come from styles/product-editor.css — the agreed visual contract.
* Do not introduce a new radius, shadow or border width without changing it
* here for everyone.
* 3. No icons, no emoji. Typographic glyphs only (− + ✓ ×).
* 4. Every component gets its dark-mode rule in the same block, not bolted on
* later by whoever notices.
* 5. Prefer a PHP helper in BAS_VM_DS over hand-written markup, so the classes
* and the element structure stay in step.
*
* @package BAS_Vendor_Map
* @since 6.147.0
* ═══════════════════════════════════════════════════════════════════════════ */
/* ── Tokens the components need ──────────────────────────────────────────────
* The shell already defines --bs-green-*, --bs-tomato, --bs-ink*, --bs-line*,
* --bs-cream*, --font-*. These are the extra surface values that every feature
* page had been hard-coding as raw hex. */
:root {
--bs-field: #ddd2b0; /* input border */
--bs-field-bg: #fffdf6; /* input fill */
--bs-card-line: #eee3c8; /* card hairline */
--bs-rule: #f0e8cd; /* table row rule */
--bs-muted: #8a8a7a; /* hint text */
--bs-card-bg: #ffffff;
--bs-focus: rgba(48,178,180,.15);
--bs-counter-over: #b4541c; /* over-budget counter — a warning, not an error */
/* v7.51.0 — the Market Planner's surfaces, which were raw hex with no dark
value (so the wrap-up panel stayed cream under light text). Each tint
pairs with its own ink so the two always flip together. */
--bs-surface-2: #f9f7f2; /* soft panel, form well */
--bs-tint-butter: #fffdf0; /* "needs you" panel — the wrap-up */
--bs-tag-butter: #fff2d6; /* small yellow tag — ESTIMATE, Weak */
--bs-butter-ink: #7a5c00; /* text on either butter tint */
--bs-tint-green: #f3fbf3; /* done / selected */
--bs-green-ink: #1d741b; /* green text — on white or the green tint */
--bs-line-green: #e0f0d0; /* hairline inside a green area */
--bs-tint-tomato: #fff4f1; /* error surface */
--bs-r-field: 10px; /* radius: inputs, tips */
--bs-r-card: 14px; /* radius: cards */
--bs-r-pill: 999px;
--bs-pad-card: 22px;
--bs-shadow-btn: 0 4px 0 rgba(29,116,27,.35);
--bs-shadow-btn-teal: 0 4px 0 rgba(24,110,112,.30);
--bs-shadow-drop: 0 8px 24px rgba(0,0,0,.12);
--bs-shadow-modal: 0 20px 60px rgba(0,0,0,.30);
}
html[data-bas-theme="dark"] {
--bs-counter-over: #e8a35e;
--bs-field: #3a3a3d;
--bs-field-bg: #161618;
--bs-card-line: #323234;
--bs-rule: #2a2a2c;
--bs-muted: #8f8f92;
--bs-card-bg: #1e1e20;
--bs-surface-2: #19191b;
--bs-tint-butter: #22201a;
--bs-tag-butter: #3a3319;
--bs-butter-ink: #ffda3d;
--bs-tint-green: #1b2419;
--bs-green-ink: #c2e86b;
--bs-line-green: #2c3a28;
--bs-tint-tomato: #2c1b17;
}
/* ── Page root ───────────────────────────────────────────────────────────────
* Put .bas-ds on a feature page's outermost element. It sets the type stack and
* opens a container-query context so layouts respond to the CONTENT width, which
* is what changes when the sidebar collapses — not the viewport. */
.bas-ds {
font-family: var(--font-body);
font-size: 15px;
line-height: 1.5;
color: var(--bs-ink);
container-type: inline-size;
container-name: basds;
}
/* ── Page header ─────────────────────────────────────────────────────────── */
.bas-ds-top { margin: 0 0 20px; }
.bas-ds-eyebrow {
font-size: 11px; font-weight: 900; letter-spacing: .14em;
text-transform: uppercase; color: var(--bs-green-700); margin-bottom: 6px;
}
.bas-ds-title {
font-family: var(--font-display); font-size: 32px; line-height: 1.15;
margin: 0 0 6px; color: var(--bs-ink);
}
.bas-ds-sub { font-size: 14px; color: var(--bs-muted); margin: 0; max-width: 62ch; }
/* Eyebrow with the plan pill beside it — "MY KITCHEN [Maker]". Lived on
Ingredients & Recipes as .bas-ks-eyebrow-row; the Studio home wanted the
same line, so it is a component now rather than a second private copy. */
.bas-ds-eyebrow-row { display: flex; align-items: center; flex-wrap: wrap; gap: 10px; margin-bottom: 6px; }
.bas-ds-eyebrow-row > .bas-ds-eyebrow { margin-bottom: 0; }
/* ── Card ────────────────────────────────────────────────────────────────── */
.bas-ds-card {
background: var(--bs-card-bg);
border: 1px solid var(--bs-card-line);
border-radius: var(--bs-r-card);
padding: var(--bs-pad-card);
margin-bottom: 20px;
scroll-margin-top: 90px; /* .bas-ds-content is the scrollport, not the window */
}
.bas-ds-card > h2 {
font-family: var(--font-display); font-size: 21px; margin: 0 0 4px; color: var(--bs-ink);
}
.bas-ds-card > h3 {
font-size: 15px; font-weight: 900; margin: 20px 0 4px; color: var(--bs-green-700);
}
.bas-ds-card-sub { font-size: 13px; color: var(--bs-muted); margin: 0 0 16px; max-width: 62ch; }
/* ── Form controls ───────────────────────────────────────────────────────────
* 🔴 The rule Amy was talking about. Seven pages had their own copy of this.
* Anything that takes typed input in the vendor dashboard looks like this. */
.bas-ds-label,
.bas-ds label {
display: block; font-weight: 700; margin: 14px 0 5px;
font-size: 14px; color: var(--bs-ink);
}
.bas-ds input[type="text"],
.bas-ds input[type="number"],
.bas-ds input[type="search"],
.bas-ds input[type="email"],
.bas-ds input[type="url"],
.bas-ds input[type="tel"],
.bas-ds input[type="date"],
.bas-ds input[type="time"],
.bas-ds input[type="password"],
.bas-ds textarea,
.bas-ds select,
/* 🔴 Doubled on purpose — see the block below. Not a typo, do not "tidy" it. */
.bas-ds-input.bas-ds-input {
width: 100%;
box-sizing: border-box;
font-family: inherit;
font-size: 15px;
/* 🔴 6.168.0 — THE HEIGHT IS PART OF THE COMPONENT. See the block below. */
min-height: 46px;
line-height: 1.35;
padding: 10px 12px;
border: 1.5px solid var(--bs-field);
border-radius: var(--bs-r-field);
background: var(--bs-field-bg);
color: var(--bs-ink);
}
/* ── Why .bas-ds-input is written twice ──────────────────────────────────────
🔴 6.168.0. A single class is specificity (0,1,0). A theme's
`input[type="text"]` is (0,1,1) — one type selector plus one attribute
selector — which is MORE specific, and Divi ships that rule inline in
, so it also comes later. Measured in the live DOM on My Store:
#bas-ssh-f-eyebrow → padding 2px, border 1px solid #bbb, background #fff
That is Divi's rule, whole, on one of our fields. Every value we wrote lost
except border-radius, which Divi happens not to set. It only bit fields that
are NOT inside a .bas-ds root — which, until this version, meant every field
in every modal, because BAS_VM_DS::modal_open() built the box without the
class. Both halves are fixed: the class is on the modal box now, AND the
component no longer depends on an ancestor to win. Repeating the class is
the cheapest way to (0,2,0) and it beats a theme type+attribute rule with no
!important anywhere, which matters because !important is unarguable and the
next person needs to be able to override this for a real reason.
── Why min-height and line-height are on that rule ─────────────────────────
🔴 Amy, 2026-09-13: "still having these annoying issues with inputs coming
out too short to be usable on a mobile. We should have had a shared class on
these a long time ago instead of me having to gripe about them every time we
add an input… You got the sizing on the Buttons input just fine."
She had it exactly: the Buttons inputs were fine because SOMEBODY WROTE
`min-height: 44px` on them by hand, in styles/bas-shop-sections-admin.css,
on that one page, for that one row. Every other field on the platform got
whatever padding plus line-height happened to compute to — and line-height
is INHERITED. Inside .bas-ds it is 1.5 and a field lands near 46px; inside a
modal appended to , or on a Dokan page whose theme sets line-height 1,
the same class lands at 38px or less. That is the bug, it is not a phone
bug, and it produced a different answer on every screen we built.
So the height moves into the component, for every pointer, and the
line-height is declared rather than inherited so the answer does not depend
on where the field is mounted.
46px is not a phone number either — it is one number that clears the 44px
Apple/Google touch floor everywhere, so there is no second set of sizes to
keep in step. @media (pointer: coarse) further down now only raises the FONT
to 16px, which is the thing that actually has to change on a phone (below
16px, iOS Safari zooms the page on focus).
🔴 DO NOT write min-height on an input on a feature page again. If a field
somewhere needs to be a different size, it needs a variant here. */
/* The exception that proves it: a field inside a tight control cluster — a
number spinner in a toolbar — where 46px would break the row it sits in. */
.bas-ds-input--tight.bas-ds-input--tight { min-height: 38px; padding: 7px 10px; }
/* 7.59.0 — a