/* Portal-wide (guest/customer-facing www pages) theme, including /login. Applies to Frappe's website chrome (navbar, sidebar, footer, tables, forms, dropdowns) plus this app's own components, not just one page's content -- portal visitors have no other way to control theme (portal_theme_toggle.js). Both states are "glass": a gradient backdrop with soft blurred color blobs, and content sitting in frosted translucent cards rather than flat panels. "Dark Glass" (navy/teal, the portal's default) and "Light Glass" (soft cool white, its toggled-off counterpart) share the same structure below -- only the palette variables and blob/card opacity differ between the two [data-theme] blocks. */ :root { --santek-bg: #eef2f7; } :root[data-theme="glass-dark"] { --santek-navy: #1c1c38; --santek-navy-2: #0b0a1c; --santek-teal: #0f4457; --santek-teal-2: #082b36; --santek-accent: #3f8ae0; --santek-bg: radial-gradient(circle at 15% 15%, #16324f 0%, var(--santek-navy-2) 55%, #050509 100%); --santek-card-bg: rgba(255, 255, 255, 0.08); --santek-card-border: rgba(255, 255, 255, 0.16); --santek-card-shadow: rgba(0, 0, 0, 0.35); --santek-card-highlight: rgba(255, 255, 255, 0.14); --santek-input-bg: rgba(255, 255, 255, 0.06); --santek-blur: blur(34px) saturate(160%); --santek-blob-1: var(--santek-teal); --santek-blob-1-opacity: 0.4; --santek-blob-2: var(--santek-accent); --santek-blob-2-opacity: 0.28; --santek-blob-3: #7a5cff; --santek-blob-3-opacity: 0.16; /* This app's other CSS (timeline.css, theme_switch.css) already reads these exact token names via var(name, ) -- redefining them here re-themes every .santek-* component and the toggle for free, with no per-component dark rule needed. */ --fg-color: rgba(255, 255, 255, 0.08); --text-color: #f4f6fb; --text-muted: #a9b4c6; --border-color: rgba(255, 255, 255, 0.16); /* Added migrating to the multi-theme engine (feat/portal-multi-theme-engine) -- these five were previously hardcoded literals duplicated across separate dark/light rule blocks (native -- Bootstrap's own `.form-control:disabled` rule (a near-white, opaque background) wins over the general rule above, since that one doesn't account for the disabled state at all. Confirmed live: light themed text on that near-white background was effectively unreadable, the same low-contrast class of bug already fixed once on the order detail page's item rows (portal_theme.css's own .page-header-actions-block note above). Text goes to --text-muted rather than the full --text-color the enabled rule above uses -- still legible, but reads as "not editable right now" the way a disabled field should, rather than looking identical to a live one. */ html[data-theme$="-dark"] input:disabled, html[data-theme$="-dark"] select:disabled, html[data-theme$="-dark"] textarea:disabled, html[data-theme$="-dark"] .form-control:disabled, html[data-theme$="-dark"] input[readonly], html[data-theme$="-dark"] textarea[readonly], html[data-theme$="-dark"] .control-value.like-disabled-input, html[data-theme$="-light"] input:disabled, html[data-theme$="-light"] select:disabled, html[data-theme$="-light"] textarea:disabled, html[data-theme$="-light"] .form-control:disabled, html[data-theme$="-light"] input[readonly], html[data-theme$="-light"] textarea[readonly], html[data-theme$="-light"] .control-value.like-disabled-input { background-color: var(--santek-input-bg) !important; backdrop-filter: blur(6px); -webkit-backdrop-filter: blur(6px); color: var(--text-muted) !important; border-color: var(--border-color) !important; opacity: 1; } /* .control-value.like-disabled-input is a *different* core control shape from everything above -- a plain
Frappe uses to show a field's value read-only when the user can't edit it at all (e.g. New Issue's Status/Customer, locked to their default), not a disabled . Found live on /issues/new: same near-white-box-on-dark-card problem, different element entirely, so it needed its own selector rather than being covered by the input-focused rules above. Web Form's rich text editor (Description, Quill-based) is a third shape again -- .ql-editor is a contenteditable
, matched by none of the input selectors above. Also found live at rgb(243,243,243), the exact same core "form control" near-white default every other shape on this page turned out to use. .ql-blank is Quill's own "show the placeholder" state; themed the same as filled since the placeholder text itself already goes through --text-muted via a separate rule below. .ql-toolbar is already dark by default here (confirmed live, rgb(23,23,23)) -- only the editable body needed fixing. */ /* .ql-container is Quill's own outer wrapper, a *separate* element sitting behind .ql-editor (not a parent-of-parent, the direct next box out) -- it carries this same core rgb(243,243,243) near-white on its own, confirmed live bleeding through .ql-editor's translucent 0.06-alpha overlay since that alone was never meant to be opaque by itself. Transparent rather than the same --santek-input-bg token -- .ql-editor already paints that tint on top; stacking the same translucent layer on both would double the alpha and read visibly lighter than every other input. */ html[data-theme$="-dark"] .ql-container, html[data-theme$="-light"] .ql-container { background-color: transparent !important; } html[data-theme$="-dark"] .ql-editor, html[data-theme$="-light"] .ql-editor { background-color: var(--santek-input-bg) !important; color: var(--text-color) !important; } html[data-theme$="-dark"] .ql-editor.ql-blank::before, html[data-theme$="-light"] .ql-editor.ql-blank::before { color: var(--text-muted) !important; } /* A native exists in .web-list-filters (Address's own Web Form has none, confirmed live via an empty .web-list-filters innerHTML) and a search box unconditionally either way. Classic CSS table-to-card reflow: tr becomes the flex row that gets the actual glass-card treatment (background/border/blur/hover), matching every other per-row card elsewhere in this app almost exactly; td/th drop their table display so they lay out as flex children instead of table cells. thead is hidden outright rather than restyled -- "Sr. / Subject / Status / Raised By (Email) / Priority" as a second header row read as visual noise once each row is already a self-labeled card, the same call already made for Address's own row shape. */ .web-list-table table { display: block; width: 100%; border-collapse: collapse; } .web-list-table thead { display: none; } .web-list-table tbody { display: block; width: 100%; } html[data-theme$="-dark"] .web-list-table tbody tr, html[data-theme$="-light"] .web-list-table tbody tr { display: flex; align-items: center; gap: 12px; background: var(--santek-card-bg); backdrop-filter: var(--santek-blur); -webkit-backdrop-filter: var(--santek-blur); border: 1px solid var(--santek-card-border); border-radius: 14px; padding: 14px 18px; margin-bottom: 12px; box-shadow: inset 0 1px 0 var(--santek-card-highlight), 0 6px 14px -4px var(--santek-card-shadow); transition: transform 0.15s ease; } html[data-theme$="-dark"] .web-list-table tbody tr:hover, html[data-theme$="-light"] .web-list-table tbody tr:hover { transform: translateY(-2px); } .web-list-table tbody td { display: block; border: none !important; padding: 0 !important; } /* Checkbox and Sr. columns are short, fixed-content -- flex:1 like every other column would leave a wide empty gap next to a single digit. Every remaining column (Subject, Status, Raised By, Priority, ...) shares the space evenly, whatever fields this Web Form happens to be configured to list. */ .web-list-table tbody td.list-col-checkbox { flex: 0 0 auto; } .web-list-table tbody td.list-col-serial { flex: 0 0 32px; color: var(--text-muted); } .web-list-table tbody td:not(.list-col-checkbox):not(.list-col-serial) { flex: 1 1 0; min-width: 0; } .web-list-table tbody td p.ellipsis { margin: 0; } /* The Status filter select + "New" button sit right above the cards now that the header row is gone -- lines them up on one row instead of the default stacked layout, matching the search-bar-then-list rhythm every other list page in this app already uses. */ .web-list-header { display: flex; align-items: center; justify-content: space-between; margin-bottom: 12px; } .web-list-filters { margin-bottom: 20px; } /* Reduced-motion pass, 2026-08-22 audit -- neutralizes only `transform` on the three hover-lift rules above (.web-list-item.transaction-list-item/.mb-3, .order-items:has(.order-item-name), .web-list-table tbody tr), not a blanket `transition-duration: 0.01ms` kill on every animation site-wide -- that pattern destroys real feedback (e.g. it would also gut portal_page_transitions.js's opacity-based entrance, whose cleanup depends on a real transitionend firing; see that script's own reveal() for why a synchronous zero-duration transition there would leave stale classes behind instead of cleaning up). Hover-lift carries no information a user needs -- the row is still fully identifiable and clickable without the 2px rise -- so simply dropping the transform is a safe, complete "intentional alternative" here, not a partial fix. */ @media (prefers-reduced-motion: reduce) { html[data-theme$="-dark"] .web-list-item.transaction-list-item:hover, html[data-theme$="-light"] .web-list-item.transaction-list-item:hover, html[data-theme$="-dark"] .web-list-item.mb-3:hover, html[data-theme$="-light"] .web-list-item.mb-3:hover, html[data-theme$="-dark"] .order-items:has(.order-item-name):hover, html[data-theme$="-light"] .order-items:has(.order-item-name):hover, html[data-theme$="-dark"] .web-list-table tbody tr:hover, html[data-theme$="-light"] .web-list-table tbody tr:hover { transform: none !important; } } /* /me -- core Frappe's own "My Account" settings page. Reported live, dark theme only (light theme confirmed live to already look correct as-is, a plain white card on a light background reads fine there -- deliberately left untouched): two real, separate bugs, not one. 1. main.container itself was rendering at the *exact* full viewport size here (confirmed live via getBoundingClientRect: 1513.6x1641.6, matching window.innerWidth/innerHeight exactly), not sized/centered to wrap the settings content the way this app's other single-card pages are. Its own default big-glass-card look (rgba(255,255,255,.08) + blur) was therefore painting across the *entire* page as a "fullscreen card" sitting behind the real content -- reported directly by the user pointing at the page's own raw HTML source. Stripped the same way list pages already strip it. 2. Core's own real card here, .portal-container (confirmed live: solid opaque white background, core CSS, unaware this app has a dark theme at all -- this app's own text-color override already correctly applies rgb(244,246,251) to "Settings"/"Administrator", so the two together read as near-invisible white-on-white). Asked directly whether to restyle it as this app's own glass card or remove it outright -- removed: matches how a settings-style page with no meaningful visual grouping needs reads better as plain content on the page's own background than as a second nested card, once the fullscreen one behind it is already gone. */ html[data-theme$="-dark"] body[data-path="me"] main.container { background: transparent !important; border: none !important; box-shadow: none !important; backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } html[data-theme$="-dark"] .portal-container { background: transparent !important; border: none !important; box-shadow: none !important; backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* /new-return -- this app's own hand-rolled "File a New Return" form (not a Web Form, unlike address/new or issues/new -- there is no Frappe-native inner card here to preserve). Reported directly, 2026-08-28: this page still carried the same big frosted card already removed from /me, /cart, address/new, issues/new and the error/login pages, plus the same list-page sidebar mismatch already fixed for address/new and issues/new. Confirmed live before writing this: no element under main.container here carries its own translucent background (the form fields' own subtle input backgrounds are normal control styling, not a second card) -- so this matches /me's own treatment above (fully cardless, padding left alone), not address/issues' "strip the outer, keep the inner Web Form card" shape, since there is no inner card on this page to keep. */ html[data-theme$="-dark"] body[data-path="new-return"] main.container, html[data-theme$="-light"] body[data-path="new-return"] main.container { background: transparent !important; border: none !important; box-shadow: none !important; backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* /new-return is reached from /returns (sidebar at 220.8px, the real list-page position) via "File a New Return" -- same list <-> new-entry sidebar mismatch already fixed for /address/new and /issues/new (172px margin-top lands here at the identical 220.8px, confirmed live). */ body[data-path="new-return"] .web-sidebar { margin-top: 172px !important; } /* /repair-status -- the guest-facing "Check Repair Status" lookup form (magic-link deep link or the manual two-factor form), same hand-rolled shape as /new-return above: no Web Form, no inner card of its own, no .web-sidebar at all (guest pages don't render one -- confirmed live, no sidebar rule needed here unlike /new-return). Reported directly, same session as /new-return's fix: still carried the same big frosted main.container card. Confirmed live no element under main.container here carries a second translucent background either (the form fields and .santek-timeline-dot's own colors are normal control/status styling, not a card) -- same /me-style fully-cardless treatment, padding left alone. */ html[data-theme$="-dark"] body[data-path="repair-status"] main.container, html[data-theme$="-light"] body[data-path="repair-status"] main.container { background: transparent !important; border: none !important; box-shadow: none !important; backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* /me's own Contact Info section -- reported directly: phone/email/address were all squeezed into a narrow column. Root cause: it reused core's .portal-section, which is `display: flex; justify-content: space-between; align-items: center` -- built for a one-line "Title ... one control" row (Theme: [switch]), not a real multi-field form. Given its own class (.santek-contact-section) instead of sharing .portal-section, so this section gets normal block layout with no fight over that flex behavior. (Address fields themselves were removed the same day -- core's own "/addresses" Web Form already covers that, more completely -- so this only ever needs to fit two fields side by side, not four.) */ .santek-contact-section { display: block; padding: 10px 0; } .santek-contact-form { display: grid; grid-template-columns: 1fr 1fr; gap: 14px 16px; max-width: 480px; margin-top: 10px; } .santek-contact-form .form-group { display: flex; flex-direction: column; gap: 4px; margin: 0; } .santek-contact-form-actions { grid-column: 1 / -1; display: flex; align-items: center; gap: 10px; margin-top: 4px; } .santek-contact-form-status { font-size: 0.85rem; color: var(--text-muted, #8d99a6); } .santek-contact-address-link { margin-top: 12px; } @media (max-width: 480px) { .santek-contact-form { grid-template-columns: 1fr; } } /* --------------------------------------------------------------------------- /warehouse runs full-bleed: no page panel, no header, no breadcrumbs. Every other portal page is a document you read, so the glass panel frames it correctly. This one is an instrument held in one hand mid-aisle, and the frame was costing about 70px of a 430px screen once its 32px padding and its own inset were counted -- enough to drop the mode grid from four buttons per row to three and push the primary action below the fold. Measured on a phone-sized viewport against the real page, not estimated. The breadcrumb trail and page title go with it. /warehouse is opened directly by someone starting a task and never navigated to from elsewhere in the portal, so a trail back to Home is height spent on a journey nobody makes. Scoped on body[data-path] like the other page-specific container overrides in this file, and prefixed with html[data-theme] so it outranks the theme's own main.container rules on specificity rather than relying on source order -- the two are otherwise equal, and a later edit reordering this file would silently undo it. --------------------------------------------------------------------------- */ html[data-theme] body[data-path="warehouse"] main.container { background: transparent; border: 0; border-radius: 0; box-shadow: none; padding: 8px; max-width: 100%; } html[data-theme] body[data-path="warehouse"] .page-breadcrumbs, html[data-theme] body[data-path="warehouse"] .page-header-wrapper, html[data-theme] body[data-path="warehouse"] .page-header { display: none; }