/* ============================================================================ GimCore design tokens ---------------------------------------------------------------------------- Seven colour systems had accumulated in the product: two dead arrays in Enums, a live one, hand-written .bg-* classes in site.css, the Bootstrap 5 palette copied into two report views, an Atlassian palette in the app switcher, and Bootstrap's own utilities. This file is the single layer they collapse into. Three rules make it safe to adopt on a codebase this size: 1. Tokens are named by ROLE, not by hue. A list that mixes "success" with "pink" cannot be governed, because the first has a fixed meaning and the second has none. They are separated here. 2. Values point at Bootstrap's own variables. No new hex is invented, so nothing has to be designed or maintained, and dark mode via data-bs-theme keeps working. 3. Adoption never moves a selector. Existing rules keep their selector and their specificity and only change what their value resolves to. That is what makes this safe against company.Css — per-tenant CSS stored in the database and injected raw, which cannot be searched or counted. ============================================================================ */ :root { /* ── Brand ──────────────────────────────────────────────────────────────── One per tenant. Overridden from company.Css by redefining these two, rather than by hunting selectors. */ --gs-brand: var(--bs-primary, #0d6efd); /* The BUTTON's blue is pinned first-party, deliberately not inherited. White on --bs-primary #0d6efd measures exactly 4.50:1 -- the AA threshold to two decimals, with no margin at all. It passes today and a Bootstrap upgrade could move it below without anyone touching our CSS, silently. #0b5ed7 measures 5.84:1. Only the button uses this; --gs-brand keeps deriving from Bootstrap so links, borders and focus rings are unaffected. */ --gs-brand-btn: #0b5ed7; --gs-brand-fg: #fff; /* ── Semantic ───────────────────────────────────────────────────────────── Fixed meaning. Never offered as a choice in a colour picker: green here asserts "good", which is wrong for a department or a saved view. */ --gs-success: var(--bs-success, #198754); --gs-warning: var(--bs-warning, #ffc107); --gs-danger: var(--bs-danger, #dc3545); --gs-info: var(--bs-info, #0dcaf0); /* ── Chip surfaces ──────────────────────────────────────────────────────── Backgrounds that carry DARK text — var(--gs-ink) — and nothing else. That is the whole rule, and it is why these sit apart from the semantic values above: a semantic colour states a meaning, a chip surface makes a promise about legibility. Each is measured against --gs-ink rather than chosen to match a hue: warning #f59e0b 7.18 primary #60a5fa 6.07 danger #f87171 5.58 success #10b981 6.08 info #0ea5e9 5.57 Adding a sixth means measuring it. Chosen by Bill 2026-08-01 to replace #3b82f6 (4.19) and #ef4444 (4.10), both of which sat below AA even with dark text — see Design_Standard.md §4.3e. */ --gs-chip-primary: #60a5fa; --gs-chip-primary-rgb: 96, 165, 250; --gs-chip-danger: #f87171; --gs-chip-danger-rgb: 248, 113, 113; /* Danger as TEXT on a light surface — the inverse case, so a different value: dark enough to read on white. `.red` rendered #F6402C at 3.69:1. */ --gs-danger-ink: #dc2626; /* The accent as TEXT on a light surface — same inverse case as --gs-danger-ink. The active nav item paints #f0f9ff behind it, and sky-600 #0284c7 reached only 3.84:1 there. Sky-700 is one step darker, same hue, 5.57. Design_Standard §4.3j. */ --gs-accent-ink: #0369a1; /* Seven entries were in the dead zone — mid-range, so neither ink nor white reached 4.5:1 on them. Moved out of it by Bill 2026-08-01, direction chosen per colour by which one keeps the meaning (Design_Standard §4.3i). DARK now — these take WHITE text, not --gs-ink: red #ef4444 -> #b91c1c 6.47 a lighter red becomes pink pink #ec4899 -> #be185d 6.04 deep-orange #ea580c -> #9a3412 7.31 the name says deep success-dark #059669 -> #065f46 7.68 the name says dark info-dark #0284c7 -> #075985 7.56 the name says dark LIGHT now — these keep --gs-ink, following §4.3e's precedent for colours that carry no fixed meaning: blue #3b82f6 -> #60a5fa 6.07 same value bg-primary took, so the two stop disagreeing indigo #6366f1 -> #a5b4fc 7.74 */ --gs-chip-red: #b91c1c; --gs-chip-red-rgb: 185, 28, 28; --gs-chip-pink: #be185d; --gs-chip-pink-rgb: 190, 24, 93; --gs-chip-deep-orange: #9a3412; --gs-chip-deep-orange-rgb: 154, 52, 18; --gs-chip-success-dark: #065f46; --gs-chip-success-dark-rgb: 6, 95, 70; --gs-chip-info-dark: #075985; --gs-chip-info-dark-rgb: 7, 89, 133; --gs-chip-blue: #60a5fa; --gs-chip-blue-rgb: 96, 165, 250; --gs-chip-indigo: #a5b4fc; --gs-chip-indigo-rgb: 165, 180, 252; /* ── Which GimCore palette entries may be a chip background ─────────────── All 46 `--gc-color` surfaces in site.css:7338-7441 measured against var(--gs-ink) #212529 and against white, 2026-08-01. Design_Standard §4.3g. This exists so the question is answered once instead of rediscovered as a contrast bug per screen. 28 work with --gs-ink. The other 18 do not, and they split: NEEDS WHITE TEXT — too dark for ink (11) bg-gray-darker #1e293b · bg-black-light / bg-gray-dark #334155 bg-gray / bg-blue-grey #64748b · bg-primary-dark #2563eb bg-blue-dark #1d4ed8 · bg-pink-dark #db2777 · bg-brown #78350f bg-purple #9333ea · bg-deep-purple #7e22ce UNUSABLE AS A CHIP — no text colour reaches 4.5:1 on them (7) ink white bg-info-dark 3.77 4.10 bg-indigo 3.45 4.47 bg-blue 4.19 3.68 bg-success-dark 4.09 3.77 bg-red 4.10 3.76 bg-deep-orange 4.33 3.56 bg-pink 4.37 3.53 Those seven sit in the middle of the range: too dark for dark text, too light for white. They are exactly the trap bg-primary and bg-danger were in before Bill lightened them (§4.3e), and they are the tail of the 17 contrast failures measured across the 131 pilot screens. Using one as a chip background is a defect whichever text colour is chosen — pick another entry, or lighten the value the way §4.3e did. */ /* ── Categorical ────────────────────────────────────────────────────────── Qualitative. No inherent meaning, only distinguishability — app categories, report icons, kanban columns, gantt bars, chart series. Assign by a stable key, never by id % N. */ --gs-cat-1: var(--bs-blue, #0d6efd); --gs-cat-2: var(--bs-indigo, #6610f2); --gs-cat-3: var(--bs-purple, #6f42c1); --gs-cat-4: var(--bs-pink, #d63384); --gs-cat-5: var(--bs-red, #dc3545); --gs-cat-6: var(--bs-orange, #fd7e14); --gs-cat-7: var(--bs-yellow, #ffc107); --gs-cat-8: var(--bs-green, #198754); --gs-cat-9: var(--bs-teal, #20c997); --gs-cat-10: var(--bs-cyan, #0dcaf0); /* ── Neutral ────────────────────────────────────────────────────────────── Text, borders, surfaces. These are what break dark mode when hardcoded. */ --gs-ink: var(--bs-body-color, #212529); --gs-ink-2: #4a5568; --gs-ink-3: #656f7d; /* was #8792a5 -- 2.85 on --gs-surface-3. AA on all three light surfaces: 5.09 / 4.87 / 4.62 */ /* Text on a dark surface. The role was missing, so every chip that needed it wrote #fff inline. Design_Standard §4.3i. */ --gs-ink-inverse: #fff; /* ── Chip ink — DELIBERATELY ABSENT FROM THE DARK BLOCK BELOW ────────────── A chip surface is a fixed chromatic value: .gc-badge.bg-flat-yellow is #fef9c3 in both themes, because a yellow chip that turned dark would stop meaning what it means. Its ink must therefore be fixed too. .gc-badge used var(--gs-ink) and the dark chips used var(--gs-ink-inverse), and BOTH of those flip. So the day dark mode is switched on, every light chip renders #f8fafc on #fef9c3 -- 1.03:1 -- and every dark chip renders #0f172a on #2d313c at 1.37. That was the whole of contrast_ratchet's `chip/dark` baseline of 13, and it is one defect, not thirteen. The values are identical to what --gs-ink / --gs-ink-inverse resolve to in LIGHT today, so nothing changes on screen; what changes is that they no longer follow the theme. If you find yourself adding these to the dark block you are re-introducing the bug -- the surface underneath is still light. The literal, not var(--bs-body-color): that variable IS theme-dependent (#212529 light, #dee2e6 dark), which is exactly the property being removed here. Design_Standard §4.3d/§4.3i, Dark_Mode_Plan §4g. */ --gs-chip-ink: #212529; --gs-chip-ink-inverse: #fff; /* ── Elevation ──────────────────────────────────────────────────────────── One card shadow, so a "raised surface" is one decision rather than a value retyped per component. Added 2026-08-03 for .gc-chart-card; the values are the ones the report-builder prompt had already settled on for its chart card (the more considered of the two specs it carried). It lives here rather than in site.css for a second reason: ui_ratchet counts colour literals in first-party CSS and EXCLUDES this file, because this is where colour is supposed to be defined. A shadow written inline in site.css is two more literals outside the token layer; written here it is one token other components can adopt. */ --gs-shadow-card: 0 1px 3px rgba(0, 0, 0, .06), 0 4px 16px rgba(0, 0, 0, .04); --gs-line: var(--bs-border-color, #dee2e6); --gs-surface: var(--bs-body-bg, #fff); --gs-surface-2: #f8fafc; --gs-surface-3: #f1f4f8; } /* ── Spacing ────────────────────────────────────────────────────────────────── Added 2026-07-31. Same reasoning as colour, one scale instead of two. Two complete scales were running side by side in the views, at near-equal strength: Bootstrap 5's 4px family (4/8/16/24 — 556 uses) and Bootstrap 3's 5px family (5/10/15/20 — 537). Neither was winning, which is why the spacing reads as arbitrary rather than as one system with exceptions. A third scale invented here would have made it three. ⚠️ These state values instead of pointing, and that breaks rule 2 above. It is not an oversight: Bootstrap 5.3 does NOT expose its spacers as custom properties. `:root` carries colours, --bs-body-font-size, --bs-border-radius*, --bs-border-width and --bs-box-shadow* — and no spacer. The numbers below are read straight off .m-0 … .m-5 in bootstrap.css, so nothing is designed here; do not "fix" this to var(--bs-spacer-N), which does not exist. Prefer Bootstrap's own utilities (.p-3, .mb-2) in markup. These exist for CSS that cannot use a utility class. */ :root { --gs-space-0: 0; --gs-space-1: 0.25rem; /* 4px — .m-1 */ --gs-space-2: 0.5rem; /* 8px — .m-2 */ --gs-space-3: 1rem; /* 16px — .m-3 */ --gs-space-4: 1.5rem; /* 24px — .m-4 */ --gs-space-5: 3rem; /* 48px — .m-5 */ /* ── Shape and type ───────────────────────────────────────────────────────── These CAN point, because Bootstrap exposes them. Rule 2 holds here. */ --gs-radius: var(--bs-border-radius, 0.375rem); --gs-radius-sm: var(--bs-border-radius-sm, 0.25rem); --gs-radius-lg: var(--bs-border-radius-lg, 0.5rem); --gs-radius-pill: var(--bs-border-radius-pill, 50rem); --gs-border: var(--bs-border-width, 1px); --gs-shadow: var(--bs-box-shadow, 0 .5rem 1rem rgba(0,0,0,.15)); --gs-shadow-sm: var(--bs-box-shadow-sm, 0 .125rem .25rem rgba(0,0,0,.075)); --gs-text: var(--bs-body-font-size, 1rem); } /* Dark mode redefines the same tokens. Nothing downstream changes, because downstream never referred to a hex. */ /* A measured slate scale. Contrast computed on these exact values before adopting: ink on surface 17.06 on surface-2 13.98 ink-2 on surface 12.02 on surface-2 9.85 ink-3 on surface 6.96 on surface-2 5.71 <- weakest, still clears AA The light theme's weakest pair is 4.62, so dark has more headroom than light. The values match the arogantt plugin's dark mode, which is where they came from -- but they are NOT justified by that alone. Nothing in this repository loads arogantt (no view, bundle or controller references it), so whether the product actually shows that plugin is still an open question with Bill. If the answer is "legacy", these stay: they are a coherent scale that measures well. Only the *reason* changes, from "aligned to a plugin users see" to "a good dark palette". Previously this block was Bootstrap grey (#1a1d21, #adb5bd) while arogantt is slate -- two disagreeing dark scales in one product, written before anyone read the plugin. --gs-line at 1.72/1.41 against these surfaces is BELOW the 3:1 non-text floor, deliberately: a divider between two dark greys is not a control boundary. Any border carrying STATE -- focus, invalid, selected -- must not use --gs-line in dark. Separate check, not covered by this token. ⚠️ Declared, not observed: read from the plugin's stylesheet, never seen rendered, because nothing here can render it. See Docs/UI/Dark_Mode_Plan.md. */ [data-bs-theme="dark"], :root[data-theme="dark"] { --gs-surface: #0f172a; --gs-surface-2: #1e293b; /* NOT arogantt's #334155. That is the plugin's BORDER colour, and I proposed it as the third surface without checking ink-3 against it -- the guard caught 4.04, below AA. My own §3 table listed ink-3 on two surfaces and there are three. #273449 keeps the ordering (lighter than surface-2, darker than the line) and measures ink 11.99 / ink-2 8.45 / ink-3 4.89 -- margin rather than a threshold. */ --gs-surface-3: #273449; --gs-line: #334155; --gs-ink: #f8fafc; --gs-ink-2: #cbd5e1; --gs-ink-3: #94a3b8; --gs-ink-inverse: #0f172a; /* Without this the browser paints scrollbars, is the "- Select -" dropdown; the dropbox/dropdown-menu selectors cover the search-style relation pickers. */ .gc-form-readonly form.gc-readonly select, .gc-form-readonly form.gc-readonly .dropboxsearch, .gc-form-readonly form.gc-readonly [class*="dropbox"], .gc-form-readonly form.gc-readonly .dropdown-toggle, .gc-form-readonly form.gc-readonly .dropdown-menu, .gc-form-readonly form.gc-readonly .dropdown-menu * { pointer-events:auto; } .gc-form-readonly { border:1px solid var(--gs-line); border-radius:.5rem; padding:.75rem 1rem; background: var(--gs-surface-2); } .gc-form-readonly form.gc-readonly { background:transparent; } /* Tab name shown above each stacked tab in a readonly embed (the tab strip itself is dropped). */ .gc-form-readonly .gc-embed-tab { margin:.9rem 0 .4rem; padding-bottom:.25rem; font-size:.9375rem; font-weight:700; color: var(--gs-ink); border-bottom:1px solid var(--gs-line); } .gc-form-readonly .gc-embed-tab:first-child { margin-top:0; } /* App Guide dossier: the small label above a screen's workflow, and the modal-preview placeholder shown where the real form renders once the guide is published. */ .gc-scr-sublabel { margin:.6rem 0 .2rem; font-size:.8125rem; color: var(--gs-ink-3); } .gc-scr-desc, .gc-scr-auto { margin:.3rem 0 .5rem; } .gc-form-placeholder { border:1px dashed var(--gs-line); border-radius:.5rem; padding:.6rem .8rem; background: var(--gs-surface-2); color: var(--gs-ink-3); font-size:.8125rem; } /* Highlighted identifiers in guide prose: a SCREEN name (bold, brand tint) and a FIELD name (a light code chip). Applied by the guide builder so screen/field names stand out. */ .gc-sn { font-weight:700; color: var(--gs-brand); } /* Data-flow section: the small parent->lines pairs, and the standalone reference screens. */ .gc-flow-pairs { margin:.4rem 0 .6rem; } .gc-flow-alone { color: var(--gs-ink-3); font-size:.875rem; margin:.3rem 0 .6rem; } code.gc-fn { background: var(--gs-surface-2); border:1px solid var(--gs-line); border-radius:.25rem; padding:.02em .35em; color: var(--gs-ink); font-size:.92em; } /* Mermaid centres its svg by default, which leaves a guide diagram floating in the middle of the column while every heading and paragraph starts at the left. Pin it to the left edge and let a wide graph scroll rather than shrink. */ [data-macro-type="bsmermaid"], .mermaid { text-align: left; overflow-x: auto; } [data-macro-type="bsmermaid"] svg, .mermaid svg { display: block; margin-left: 0; margin-right: auto; } /* A macro whose stored source is damaged says so, rather than rendering as an odd empty block. Silent degradation is how seven destroyed diagrams reached a customer-facing page unnoticed. */ .gc-macro-damaged { border:1px solid var(--gs-line); border-left:4px solid var(--gs-warning); border-radius:.5rem; background: var(--gs-surface-3); color: var(--gs-ink); padding:.7rem .9rem; margin:.5rem 0; font-size:.875rem; } .gc-mermaid-fallback { border:1px solid var(--gs-line); border-radius:.5rem; padding:.6rem .8rem; background: var(--gs-surface-2); color: var(--gs-ink); overflow-x:auto; font-size:.8125rem; white-space:pre; } /* ── GimCore Pages Enterprise UI ── */ .gim-page-header { display: flex; align-items: center; justify-content: space-between; flex-wrap: wrap; gap: 12px; padding: 4px 0 20px; } .gim-page-header h5 { margin: 0; font-size: 1.05rem; font-weight: 700; color: #1e293b; letter-spacing: .01em; } .btn-new-page { display: inline-flex; align-items: center; gap: 7px; font-weight: 600; padding: 8px 18px; border-radius: 8px; font-size: .87rem; letter-spacing: .02em; } .gim-status-tabs { display: flex; align-items: center; flex-wrap: wrap; gap: 7px; margin-bottom: 16px; } .gim-status-tab { display: inline-flex; align-items: center; gap: 5px; padding: 5px 14px; border-radius: 20px; font-size: .77rem; font-weight: 700; text-decoration: none; letter-spacing: .04em; transition: opacity .15s, box-shadow .15s; box-shadow: 0 1px 5px rgba(0, 0, 0, .1); } .gim-status-tab:hover { opacity: .82; box-shadow: 0 3px 10px rgba(0, 0, 0, .15); text-decoration: none; } .gim-status-tab .cnt { background: rgba(255, 255, 255, .3); border-radius: 10px; padding: 0 7px; font-size: .72rem; font-weight: 800; } .gim-bulk-bar { display: flex; align-items: center; flex-wrap: wrap; gap: 8px; padding: 10px 16px; background: #f8f9fb; border: 1px solid #e4e8ef; border-radius: 10px; margin-bottom: 16px; } .gim-bulk-bar select.form-control { font-size: .84rem; height: 34px; border-radius: 7px; min-width: 160px; } .gim-bulk-bar .btn { font-size: .83rem; height: 34px; border-radius: 7px; padding: 0 15px; } .gim-search-box { margin-left: auto; } .gim-search-box .form-control { font-size: .85rem; border-right: none; } .gim-search-box .input-group { border-radius: 8px; border: 1px solid var(--gs-line); box-shadow: 0 1px 4px rgba(0, 0, 0, .06); } .gim-search-box .input-group .form-control { border: none; border-radius: 8px 0 0 8px; box-shadow: none; font-size: .87rem; } .gim-search-box .input-group .form-control:focus { box-shadow: none; } .gim-search-box .input-group .input-group-text { border: none; border-radius: 0 8px 8px 0; background: var(--gs-surface); border-left: 1px solid var(--gs-line); } /* Table */ .gim-pages-table { border-collapse: separate; border-spacing: 0; width: 100%; } .gim-pages-table thead tr { background: #f1f4f9; } .gim-pages-table thead th { font-size: .71rem; font-weight: 700; text-transform: uppercase; letter-spacing: .08em; color: var(--gs-ink-3); padding: 10px 13px; border-bottom: 2px solid #dde3ee; white-space: nowrap; } .gim-pages-table tbody tr { border-bottom: 1px solid #edf0f7; transition: background .12s; } .gim-pages-table tbody tr:last-child { border-bottom: none; } .gim-pages-table tbody tr:hover { background: #f5f7fc; } .gim-pages-table td { padding: 9px 13px; vertical-align: middle; font-size: .87rem; } /* Title cell */ .gim-page-row-title { display: flex; align-items: center; gap: 9px; } .gim-page-icon { width: 30px; height: 30px; border-radius: 8px; background: #e8f0fe; display: flex; align-items: center; justify-content: center; flex-shrink: 0; font-size: .8rem; color: #1a56db; } .gim-page-name { font-weight: 600; color: #1a56db; font-size: .9rem; text-decoration: none; } .gim-page-name:hover { color: #1140a8; text-decoration: underline; } .gim-page-name.trashed { text-decoration: line-through; color: #9ca3af; } .gim-page-name.archived { color: #7c3aed; } /* Space vs Page color distinction */ .gim-page-name.is-space { color: #0e7490; font-style: italic; } /* teal-ish for spaces */ .gim-page-icon.is-space { background: #cffafe; color: #0e7490; } .space-label { font-size: .68rem; font-weight: 700; letter-spacing: .06em; padding: 1px 6px; border-radius: 4px; background: #cffafe; color: #0e7490; vertical-align: middle; margin-left: 5px; } /* Row action dropdown */ .gim-action-btn { width: 30px; height: 30px; border-radius: 7px; border: 1px solid #e2e6ed; background: var(--gs-surface); display: inline-flex; align-items: center; justify-content: center; color: var(--gs-ink-3); cursor: pointer; transition: background .12s, color .12s; font-size: 1rem; } .gim-action-btn:hover { background: #f1f5f9; color: #1a56db; border-color: #c7d2e0; } .gim-action-menu { min-width: 180px; border: 1px solid #e2e8f0; border-radius: 10px; box-shadow: 0 8px 24px rgba(0, 0, 0, .12); padding: 5px 0; } .gim-action-menu .dropdown-item { display: flex; align-items: center; gap: 9px; font-size: .82rem; padding: 7px 14px; color: #374151; transition: background .1s; } .gim-action-menu .dropdown-item:hover { background: #f1f5f9; color: #1a56db; } .gim-action-menu .dropdown-item .di-icon { width: 18px; text-align: center; } .gim-action-menu .dropdown-item.item-danger { color: #dc2626; } .gim-action-menu .dropdown-item.item-danger:hover { background: #fef2f2; color: #b91c1c; } .gim-action-menu .dropdown-divider { margin: 4px 0; } /* Inputs */ .order-input { width: 54px; text-align: center; font-size: .84rem; border: 1px solid var(--gs-line); border-radius: 6px; padding: 3px 6px; color: #374151; transition: border-color .15s; background: var(--gs-surface); } .order-input:focus { outline: none; border-color: #60a5fa; box-shadow: 0 0 0 2px rgba(96, 165, 250, .2); } /* Badges */ .gpill { display: inline-flex; align-items: center; gap: 4px; font-size: .71rem; font-weight: 700; letter-spacing: .05em; padding: 3px 10px; border-radius: 20px; } .gpill-pub { background: #d1fae5; color: #065f46; } .gpill-draft { background: #fef3c7; color: #92400e; } .gpill-arch { background: #ede9fe; color: #4c1d95; } .gpill-trash { background: #fee2e2; color: #991b1b; } .gpill-page { background: #f1f5f9; color: #475569; } .gim-pager { margin-top: 18px; display: flex; justify-content: flex-end; } @media (max-width: 768px) { .gim-bulk-bar { flex-direction: column; align-items: flex-start; } .gim-search-box { margin-left: 0; width: 100%; } } /*===== Vertical Timeline =====*/ /*@import url("https://fonts.googleapis.com/css?family=Oswald|Roboto:400,700");*/ /*@import url(https://fonts.googleapis.com/css?family=Open+Sans:400,700); /* Global Custom Scrollbar system-wide */ /*::-webkit-scrollbar { width: 8px; height: 8px; } ::-webkit-scrollbar-track { background: transparent; border-radius: 4px; } ::-webkit-scrollbar-thumb { background-color: #cbd5e1; border-radius: 4px; } ::-webkit-scrollbar-thumb:hover { background-color: #94a3b8; }*/ /** { font-family: 'Open Sans', sans-serif, Arial, Helvetica; }*/ .dropdown-item { padding: .25rem .5rem !important; } .dropdown-menu>li>a { padding: 5px 20px 5px 10px !important; } .note-toolbar .dropdown-style { line-height: 0.5 !important; padding-left: 10px !important; } .note-toolbar .dropdown-style>li { padding: 5px !important; min-width: 200px !important; } .note-toolbar .dropdown-style>li>a { padding: 5px !important; } .page-tree-view .fa-angle-right, .fa-angle-down { margin-right: 5px; cursor: pointer; } .has-feedback { position: relative; } .form-control-feedback { position: absolute; top: 0; right: 0; z-index: 2; display: block; width: 34px; height: 34px; line-height: 34px; text-align: center; pointer-events: none; } .timeline-item { padding: 3em 2em 2em; position: relative; color: rgba(0, 0, 0, 0.7); border-left: 2px solid rgba(0, 0, 0, 0.3); } .timeline-item p { font-size: 1em; } .timeline-item::before { content: attr(date-is); position: absolute; left: 2em; font-weight: bold; top: 10px; display: block; } .timeline-item::after { width: 10px; height: 10px; display: block; top: 1em; position: absolute; left: -6px; border-radius: 10px; content: ''; border: 2px solid rgba(0, 0, 0, 0.3); background: white; } .timeline-item:first-child { -o-border-image: linear-gradient(to top, rgba(0, 0, 0, 0.3) 60%, transparent) 1 100%; border-image: -webkit-linear-gradient(top, rgba(0, 0, 0, 0.3) 60%, transparent) 1 100%; border-image: linear-gradient(to top, rgba(0, 0, 0, 0.3) 60%, transparent) 1 100%; } .timeline-item:last-child { -o-border-image: linear-gradient(to bottom, rgba(0, 0, 0, 0.3) 60%, transparent) 1 100%; border-image: -webkit-linear-gradient(top, rgba(0, 0, 0, 0.3) 60%, transparent) 1 100%; border-image: linear-gradient(to bottom, rgba(0, 0, 0, 0.3) 60%, transparent) 1 100%; } /*===== // Resonsive Vertical Timeline =====*/ /*===== // SQL Condition Rules*/ .rule-container::after { content: 'AND'; position: absolute; left: 2em; font-weight: bold; top: 10px; display: block; } .typeahead-w-100p .twitter-typeahead { width: 100% !important; } .twitter-typeahead .tt-menu { min-width: 200px; margin-top: 2px; padding: 8px 0; background-color: var(--gs-surface); border: 1px solid var(--gs-line); border: 1px solid rgba(0, 0, 0, 0.2); -webkit-border-radius: 8px; -moz-border-radius: 8px; border-radius: 8px; -webkit-box-shadow: 0 5px 10px rgba(0, 0, 0, .2); -moz-box-shadow: 0 5px 10px rgba(0, 0, 0, .2); box-shadow: 0 5px 10px rgba(0, 0, 0, .2); } .twitter-typeahead .tt-suggestion { padding: 3px 10px; } /*typeahead markup*/ .twitter-typeahead .tt-query, .twitter-typeahead .tt-hint { margin-bottom: 0; } .twitter-typeahead .tt-hint { display: none; } .tt-menu { position: absolute; top: 100%; left: 0; z-index: 10000; display: none; float: left; min-width: 160px; padding: 5px 0; margin: 2px 0 0; list-style: none; font-size: 14px; background-color: var(--gs-surface); border: 1px solid var(--gs-line); border: 1px solid rgba(0, 0, 0, 0.15); border-radius: 4px; -webkit-box-shadow: 0 6px 12px rgba(0, 0, 0, 0.175); box-shadow: 0 6px 12px rgba(0, 0, 0, 0.175); background-clip: padding-box; cursor: pointer; } .tt-open { z-index: 10000; } .tt-suggestion { /*display: block;*/ padding: 3px 20px; clear: both; font-weight: normal; line-height: 1.428571429; color: #333333; white-space: normal; } .tt-suggestion:hover, .tt-suggestion:focus { color: #ffffff; text-decoration: none; outline: 0; background-color: #007bff; } /*End type ahead*/ /*table responsive*/ /*.table-responsive tr:nth-child(even) { background: #FFF } .table-responsive tr:nth-child(odd) { background: #F9F9F9; }*/ .table-responsive { border: solid 0px #e5ecf9; border-collapse: collapse; } .table-responsive td { border: solid 1px #e5ecf9; color: #016783; padding: 7px; } /*@media(max-width:800px) {*/ /* Force table to not be like tables anymore */ /*.table-responsive table, .table-responsive thead, .table-responsive tbody, .table-responsive th, .table-responsive td, .table-responsive tr { display: block; }*/ /* Hide table headers (but not display: none;, for accessibility) */ /*.table-responsive tr.thead { position: absolute; top: -9999px; left: -9999px; } .table-responsive tr { border-bottom: 1px solid #ccc; margin-top:10px; } .table-responsive td {*/ /* Behave like a "row" */ /*border: none; border-bottom: 1px solid #eee; position: relative; padding-top:5px; padding-left: 50%; white-space: normal; text-align: left; vertical-align: middle; min-height: 35px; width:100%; } .table-responsive td:before {*/ /* Now like a table header */ /*position: absolute;*/ /* Top/left values mimic padding */ /*top: 6px; left: 6px; width: 45%; padding-right: 10px; white-space: nowrap; text-align: left; font-weight: bold; }*/ /*Label the data*/ /*.table-responsive td:before { content: attr(data-label); } }*/ .page-tree-view>ul { padding-left: 0; padding-right: 10px; list-style: none; margin: 0; } .page-tree-view ul:not(:first-child) { padding-left: 15px; } .page-tree-view .glyphicon { position: relative; top: -1px; font-size: 10px; padding-right: 7px; color: #9f9a9a; cursor: pointer; } .page-tree-view .single { position: relative; top: -2px; font-size: 10px; padding-left: 2px; padding-right: 10px; color: #9f9a9a; } .page-tree-view .single:before { content: 'o' } .page-tree-view li { padding: 2px 0; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } .page-tree-view li.actived>a { font-weight: bold; } /*Assignee dropdown image*/ .img-30 { max-width: 30px !important; } .img-25 { max-width: 25px !important; } .hover-scroll { overflow: hidden; } .hover-scroll:hover { overflow: auto; } .hover-scroll-x { overflow: hidden; } .hover-scroll-x:hover { overflow-y: auto; } .hover-scroll-y { overflow: hidden; } .hover-scroll-y:hover { overflow-y: auto; } .alert { margin-top: 10px; } /*hide select arrow*/ .select-hide-arrow { overflow: hidden; } .select-hide-arrow select { -moz-appearance: none; -webkit-appearance: none; appearance: none; background: var(--gs-surface); } /* Screen tabs --------------------------------------------------------------------------------------------- Was two hardcoded Bootstrap 3 blues -- #5bc0de filled chips with #007bff for the active one -- so every tab read as a button and the selected one was just a darker button. Bill, 2026-08-16, on the first screen ever to carry tabs: "cần làm lại tab cho pro hơn". Underline tabs instead: the label carries the meaning, the rule under it carries the state. Only the active tab spends any colour, which is what makes a 5-tab bar look calm and a 13-tab bar survivable -- and 13 is real, `Project` declares that many Childlists. Every value is a token, so this follows the theme into dark mode instead of staying light-blue there. The old #5bc0de did not. */ .screen-tabs { display: flex; flex-wrap: nowrap; gap: var(--gs-space-3, .75rem); margin: 0 0 var(--gs-space-4, 1rem); padding: 0; list-style: none; border-bottom: 1px solid var(--gs-line); /* 13 tabs do not fit. Scroll the bar rather than wrapping it into a second row that pushes the form down and makes the tab strip look like content. */ overflow-x: auto; overflow-y: hidden; scrollbar-width: thin; } .screen-tabs li { margin: 0; flex: 0 0 auto; } /* The strip is not only tabs — it also carries ACTIONS, and they were being styled as tabs. --------------------------------------------------------------------------------------------- Bill, 2026-08-23: "nút add tab, add fields không đẹp, chuẩn enterprise và các tab groups, ... mất top border". Everything lives inside one `ul.screen-tabs`: the tabs, the `+` that adds a tab, an `Add Field` link, and a `btn-group` of view modes (Form View / Table View / Groups / Pathline). Three separate faults followed from treating that whole list as tabs: 1. THE TOP BORDER WAS BEING CUT OFF, and that one is mine. The view had `style="margin-top: -5px"` on the button group, and the strip carries `overflow-y: hidden` — added when it was made to scroll horizontally, to stop a vertical scrollbar appearing. A negative margin plus a clipping container removes exactly the 5px the buttons' top border sits in. The inline margin is gone from the view and the strip centres its items instead, which is what that margin was approximating by hand. 2. `Add Field` is an `` WITH NO CLASS, and `.field-add` has no stylesheet entry anywhere. So it inherited the underline-tab rule and read as a tab you could select. It is a command. 3. `float-end` on the button group does nothing — `float` is ignored on a flex item, and this list became `display:flex` when it was made scrollable. `margin-left: auto` is the flex way to push it to the trailing edge, and it is what kept the group from drifting into the tabs. */ .screen-tabs { align-items: center; /* Bill, 2026-08-23: "khoãng cách 2 buttons hơi xa nhìn rời rạc". One `gap` serves both kinds of item, and 16px is right for tabs and far too much for two adjacent buttons. Measured: `+` to `Add Field` and `Add Field` to the view-mode group were both 16px, the same as tab to tab. Halving the gap and giving the tab links back the 4px in padding keeps the TABS looking exactly as they did -- label to label was 4 + 16 + 4 = 24px and is now 8 + 8 + 8 = 24px -- while the buttons, which have their own padding inside a border, close from 16px to 8px. Changing `gap` alone would have tightened the tabs too. */ gap: var(--gs-space-2, .5rem); } /* The tabs answer "which part am I looking at". These answer "do something". A vertical rule separates the two groups, so the actions stop reading as more tabs. */ .screen-tabs li:has(> a[data-id="0"]), .screen-tabs li:has(.field-add) { align-self: center; } .screen-tabs li > a[data-id="0"], .screen-tabs a:has(.field-add) { display: inline-flex; align-items: center; gap: var(--gs-space-1, .25rem); padding: var(--gs-space-1, .25rem) var(--gs-space-2, .5rem); border: 1px solid var(--gs-line); border-radius: var(--gs-radius, .25rem); color: var(--gs-ink-2); font-weight: 500; line-height: 1.4; background: var(--gs-surface); } /* The underline belongs to tabs. An action must never look selected. */ .screen-tabs li > a[data-id="0"], .screen-tabs li > a[data-id="0"]:hover, .screen-tabs a:has(.field-add), .screen-tabs a:has(.field-add):hover { border-bottom-color: var(--gs-line); } .screen-tabs li > a[data-id="0"]:hover, .screen-tabs a:has(.field-add):hover { color: var(--gs-ink); background: var(--gs-surface-2, var(--gs-surface)); border-color: var(--gs-ink-3); } /* The view-mode group had a spacing scheme of its own, and it disagreed with the strip's. --------------------------------------------------------------------------------------------- Bill, 2026-08-23, pointing at the Form View / Table View join: "khoãng cách nên bằng khoãng cách giữa các tab". Measured, everything in the strip sat at 8px -- tab to tab, `+` to `Add Field`, `Add Field` to this group -- while INSIDE the group it was: Form View -> Table View 3px Bootstrap's `.btn-group > .btn + .btn { margin-left: -1px }` everything after that 4px an inline `margin-left: 4px` on seven elements Two different mechanisms producing two values, neither of them the strip's. The inline margins are gone from the view -- inline styles cannot be beaten from a stylesheet without `!important`, and adding seven of those to win an argument with markup is the wrong trade -- and the group now simply uses `gap`, which it can, being `inline-flex`. Bootstrap's -1px has to be cancelled too, or every pair sits at 7px instead of 8. ⚠️ Written first as `.screen-tabs li.float-end .btn-group > *`, which LOST and produced exactly that 7px. `*` contributes nothing to specificity, so that selector is (0,3,1), while Bootstrap's `.btn-group > :not(.btn-check:first-child) + .btn` is (0,4,0) — `:not()` takes the specificity of its argument, and `.btn-check:first-child` is worth two classes on its own. Naming the class instead of matching anything makes it (0,4,1) and it wins without `!important`. */ .screen-tabs .btn-group { gap: var(--gs-space-2, .5rem); } .screen-tabs li.float-end .btn-group > .btn, .screen-tabs li.float-end .btn-group > .form-select, .screen-tabs li.float-end .btn-group > .btn-group { margin-left: 0; } /* The view-mode group stays IN the strip and scrolls with it, which is where the markup puts it. `margin-left: auto` pushes it to the trailing edge whenever the strip has room to spare, and is simply inert when it does not -- an auto margin distributes free space and an overflowing strip has none. That is why the markup's `float-end` never did anything: float is ignored on a flex item, and this list became flex when it was made scrollable. */ .screen-tabs li.float-end { margin-left: auto; align-self: center; } .screen-tabs li.float-end .btn-group { margin-top: 0; } .screen-tabs a, .screen-tabs li.active a { display: block; /* The horizontal padding was `--gs-space-1` and moved here to `--gs-space-2` when the strip's `gap` halved. Label to label stays 24px -- 8 + 8 + 8 where it used to be 4 + 16 + 4 -- so the tabs look unchanged while the ACTION buttons, which have their own border, close from 16px to 8px. Changing the gap alone would have tightened the tabs too. ⚠️ Written first as a separate `.screen-tabs a { padding-left/right }` block placed ABOVE this one. Equal specificity, so this rule won and the override did nothing: the gap halved, the padding did not, and the tabs came out at 16px instead of 24. Same-specificity CSS is decided by ORDER, and an override sitting earlier in the file is not an override at all. */ padding: var(--gs-space-2, .5rem) var(--gs-space-2, .5rem); background: none; border: 0; border-bottom: 2px solid transparent; border-radius: 0; color: var(--gs-ink-3); font-weight: 500; white-space: nowrap; text-decoration: none; /* The active tab goes from 500 to 600. Without this the whole bar shifts by a pixel or two when you change tab, because bolder text is wider. */ transition: color .12s ease, border-color .12s ease; } .screen-tabs a:hover, .screen-tabs a:focus-visible { color: var(--gs-ink); border-bottom-color: var(--gs-line); } .screen-tabs a:focus-visible { outline: 2px solid var(--gs-brand); outline-offset: 2px; } .screen-tabs li.active a { color: var(--gs-ink); font-weight: 600; border-bottom-color: var(--gs-brand); } /* Child-count badges: "Task(7)" on a tab whose content is a childlist. --------------------------------------------------------------------------------------------- The number is computed and kept current by screen-tabs.js -- this only styles the span it appends inside `a.screen-tab`. Muted and un-bolded on purpose: the tab NAME is what a user scans for, the count is a secondary fact next to it, not a second label competing for attention. `font-variant-numeric: tabular-nums` keeps the tab from twitching sideways as a count goes from a single digit to two while a childlist is being edited. */ .screen-tab .tab-child-badge { margin-left: var(--gs-space-1, .25rem); color: var(--gs-ink-3); font-weight: 400; font-variant-numeric: tabular-nums; } .screen-tabs li.active .tab-child-badge { color: var(--gs-ink-2); } @media (prefers-reduced-motion: reduce) { .screen-tabs a { transition: none; } } .issue-screen-tabs { border-bottom: 1px solid var(--gs-line); } /* Screen tabs, part 2: a strip that overflows must SAY it overflows. --------------------------------------------------------------------------------------------- The rule above chose scrolling over wrapping, and that was right -- a second row pushes the form down and makes the tab strip read as content. What it did not do is tell you there is anything to scroll to. Measured on `gimcore_dev_test` @ DESKTOP-P84FJR0, 2026-08-23, viewport 1440: runtime /apps/project-management/project/new 14 tabs, strip 1200px, content 1538px -> 3 of 14 tabs INVISIBLE, no affordance editor /projectscreen/index/34808 17 tabs, strip 1200px, content 3238px -> 9 of 17 tabs INVISIBLE -> 634px -- a FIFTH of the strip -- is the pencil+trash icons, 30 of them, all at rest Silent truncation is the defect, not the scrolling. A user who cannot see `Project Phases` has no reason to believe it exists, and the native scrollbar (11px, sitting under the labels) reads as damage rather than as an invitation. 43 screens carry a tab strip, 17 of them have 6+ tabs and 7 have 10+, so this is the normal case for a real app rather than an edge one. `Project` declares 14 and AI Governance 12. PROGRESSIVE ENHANCEMENT, DELIBERATELY. Everything here hangs off `.screen-tabs-scroller`, a wrapper that only exists once screen-tabs.js has run. If the script is absent the strip keeps its native scrollbar and behaves exactly as before -- which matters, because hiding the scrollbar without providing arrows would leave a strip that is truncated AND has no way out. */ .screen-tabs-scroller { position: relative; display: flex; align-items: stretch; /* The border moves here from the