/* ═══════════════════════════════════════════════════════════════════════════ hub-consistency.css — ONE definition of the left sidebar, loaded by all three trackers. Tyler, 2026-09-14: "the designs still aren't exactly the same, though. For every left sidebar, grant management is bigger than the grants, where event views is centered and not the same size. Marketing is perfect." He is right and the measurements say so. Taken at 1820px before this file: Grants Events MARKETING (the target) label size 9.92px 10px 9px label padding 10px 6px 4px 8px 6px 4px 12px 10px 4px item size 12.16px 12px 12px item weight 600 600 700 item padding 8/10/8/7 7px 10px 7px 10px item height 32px 27px 32px Three pages, three sets of numbers, because each inherited from whichever stylesheet its own app happens to load — work.css for Grants and Events, crm.css for Marketing. Matching them by hand in three places is how they drifted in the first place, so this file states them ONCE and every page loads it last. 🚨 EVERYTHING HERE IS !important ON PURPOSE. It has to beat work.css (854 KB) and crm.css, both of which style .ph-sidebar and .ph-sb-item at equal specificity and load earlier. This is load-bearing, not clutter — the same lesson as reference_topnav_runtime_css_beats_your_stylesheet. ═══════════════════════════════════════════════════════════════════════════ */ /* ── the card ───────────────────────────────────────────────────────────── */ .ph-sidebar, #wkeRoot > .wke-views { background: #fff !important; border: 1px solid #e2e8f0 !important; border-radius: 14px !important; padding: 8px !important; box-sizing: border-box !important; /* 🚨 "It should be all the way up, though." work.css pins the sidebar with position:sticky; top:60px — a figure sized for the Work Hub, where a 60px page header sits above it. Inside a frame there is no such header (the shell's is outside the document), so that 60 was pure dead space: every sidebar sat 40-44px BELOW the top of its own content. 12px matches the gutter the content starts on. */ top: 12px !important; align-self: start !important; } /* ── the label above the items ──────────────────────────────────────────── */ .ph-sb-label, #wkeRoot > .wke-views .ph-nav::before { display: block !important; font-size: 9px !important; font-weight: 700 !important; line-height: 1.4 !important; color: #94a3b8 !important; text-transform: uppercase !important; letter-spacing: .06em !important; text-align: left !important; padding: 12px 10px 4px !important; margin: 0 !important; } /* ── the items ──────────────────────────────────────────────────────────── */ .ph-sidebar .ph-sb-item, #wkeRoot > .wke-views .ph-nav-btn { display: flex !important; align-items: center !important; justify-content: flex-start !important; gap: 10px !important; width: 100% !important; min-height: 32px !important; box-sizing: border-box !important; padding: 7px 10px !important; border: 0 !important; border-radius: 10px !important; background: none !important; box-shadow: none !important; font-size: 12px !important; font-weight: 700 !important; line-height: 1.2 !important; text-align: left !important; color: #0f172a !important; cursor: pointer; transition: background .15s ease, color .15s ease; } .ph-sidebar .ph-sb-item:hover, #wkeRoot > .wke-views .ph-nav-btn:hover { background: rgba(15, 23, 42, .05) !important; transform: none !important; } .ph-sidebar .ph-sb-item.is-active, #wkeRoot > .wke-views .ph-nav-btn.is-active { background: #eef4fb !important; color: #0f4b91 !important; box-shadow: none !important; } /* The count / badge each item can carry, on all three. */ .ph-sidebar .ph-sb-badge, #wkeRoot > .wke-views .wke-n { margin-left: auto !important; font-size: 10.5px !important; font-weight: 700 !important; background: #eef2f7 !important; color: #5b6b82 !important; border-radius: 20px !important; padding: 1px 7px !important; min-width: 20px !important; text-align: center !important; opacity: 1 !important; } .ph-sidebar .ph-sb-item.is-active .ph-sb-badge, #wkeRoot > .wke-views .ph-nav-btn.is-active .wke-n { background: #dbe8f7 !important; color: #0f4b91 !important; } /* ═══════════════════════════════════════════════════════════════════════════ A TEXT IS NOT AN EMAIL, AND IT SHOULD NEVER LOOK LIKE ONE. Tyler: "I feel like I need to have a difference between texts and emails, especially texts, and that's for all of them… Maybe you don't make it a separate area, but texts and emails need to be separated by tag and whatever." So: NOT a separate surface — the same board, the same queue, the same approval path. What changes is that a text is unmistakable at a glance. Teal is the text colour everywhere already (the piece kind, the inbox chip, the Text Replies tile); this extends it to the card itself so the board reads without anybody having to squint at a subtitle. ═══════════════════════════════════════════════════════════════════════════ */ /* 🚨 SELECTORS READ OFF THE RENDERED CARD, NOT GUESSED. The first draft of this block used .mh-kind-chip and [data-piece-kind] — neither exists. The real markup is:
Ready to send SMS · 1d ago So a text piece is marked ONLY by the words "SMS ·" in 11px grey inside the subtitle. That is the whole complaint: on a wall of cards it does not read. (--rp-card-c is already teal — the kind patch in tools/port-marketing.cjs feeds it — but a card tint alone is not a label.) */ /* A teal edge down the card. The one mark that reads from across the room. */ [data-mh-kind="text"] { box-shadow: inset 4px 0 0 #0d9488 !important; } /* An actual TEXT tag, in front of the subtitle, on every surface that draws a piece card. ::before rather than new markup so no vendored file is forked. */ [data-mh-kind="text"] .tmc-sub::before { content: 'TEXT'; display: inline-block; margin-right: 7px; padding: 2px 7px; border-radius: 20px; background: #0d9488; color: #fff; font-size: 9.5px; font-weight: 800; letter-spacing: .06em; vertical-align: 1px; } /* The email side stated too, quietly — a tag that only ever appears on one kind reads as a warning rather than as a classification. Lighter weight, so texts still carry the emphasis he asked for. */ [data-mh-kind="email"] .tmc-sub::before { content: 'EMAIL'; display: inline-block; margin-right: 7px; padding: 2px 7px; border-radius: 20px; background: #eef2ff; color: #4f46e5; font-size: 9.5px; font-weight: 700; letter-spacing: .06em; vertical-align: 1px; } /* The list/row view of the same board. */ [data-mh-kind="text"] .tmr-sub::before, [data-mh-kind="text"] .mh-row-sub::before { content: 'TEXT'; display: inline-block; margin-right: 7px; padding: 2px 7px; border-radius: 20px; background: #0d9488; color: #fff; font-size: 9.5px; font-weight: 800; letter-spacing: .06em; } /* 🚨 THIS FILE UN-HID THE NEW GRANT BUTTON, AND THE SUITE CAUGHT IT. The rule above is .ph-sidebar .ph-sb-item (two classes) with display:flex !important; the page CSS hides the create button with .ph-sb-add (one class). Both !important, so the more specific one — this file — won, and a button that cannot do anything on a read-only hub came back. Re-stated here at matching specificity. The hub still cannot save, so the create controls stay gone until there is a backend. */ .ph-sidebar .ph-sb-item.ph-sb-add, .ph-sidebar .ph-sb-item[data-wk-quickadd], .ph-sidebar .ph-sb-item[data-cmd="new-grant"] { display: none !important; }