/* Studiomate's own adjustments on top of the Sneat theme. --------------------------------------------------------------------------------------------- This file exists so wwwroot/sneat/ can stay a pristine vendor drop: when the theme is updated, that folder is replaced wholesale and nothing here is lost. Never fix a theme problem by editing wwwroot/sneat/css/*.css — restate the rule here instead. Loaded from App.razor AFTER core.css/theme-default.css/page-auth.css, so these win on equal specificity, and BEFORE app.css + the scoped-CSS bundle, which stay the last word. ============================================================================================= */ /* 1. Contrast corrections (WCAG AA, 4.5:1 for normal text) --------------------------------------------------------------------------------------------- The theme's palette fails AA in most of its status colours. Every replacement below was derived by scaling the theme's own colour toward black until it cleared 4.5:1 against the background it actually renders on (white for text, the alert's own tinted background for alerts) — so the hue is the theme's, only the lightness moved. Measured before -> after: IMPORTANT — the reference background. An earlier pass calibrated these against #ffffff and was wrong for half the app: Sneat's page background is #f5f5f9, and headings, trails and other text outside a card sit directly on it. Against that surface the "fixed" values measured 4.18, i.e. still failing. Everything below is now calibrated against #f5f5f9, the worse of the two surfaces, so it clears on the page background and on white cards alike. Any future colour added here must be checked the same way. .text-muted #a1acb8 2.31 on white -> #697078, 4.61 on #f5f5f9 / 5.01 on white --bs-body-color #697a8d 4.40 on white -> #627183, 4.59 on #f5f5f9 / 4.99 on white .alert-success #71dd37 on #e8fadf 1.58 -> 4.54 .alert-info #03c3ec on #d7f5fc 1.83 -> 4.54 .alert-warning #ffab00 on #fff2d6 1.71 -> 4.55 .alert-danger #ff3e1d on #ffe0db 2.84 -> 4.56 .alert-secondary #8592a3 on #e9eaec 2.63 -> 4.62 .alert-primary #696cff on #e7e7ff 3.33 -> 4.52 All eight are fixed at once rather than only the two with wide coverage today (.text-muted, and alert-danger at ~13 uses across 7 pages) — a variant fixed one at a time is a variant that gets forgotten. Backgrounds and borders are deliberately left alone: only the foreground moves, so the theme still looks like itself. .alert-dark already passes and is untouched. */ :root { --bs-body-color: #627183; --bs-body-color-rgb: 98, 113, 131; } .text-muted { color: #697078 !important; } /* Form help text ("Mínimo 8 caracteres…", "Deixa em branco para usar a predefinição…"). Sneat sets #b4bdc6 here, which measures 1.90 on white — the second-worst figure found anywhere, and it is precisely the text that explains a field's rules to someone filling it in. Same value as .text-muted, since it plays the same role. */ .form-text { color: #697078; } /* The variable alone doesn't do it. Sneat hardcodes the literal #697a8d in 74 places rather than reading --bs-body-color, so several surfaces kept the old value even after the variable moved — table cells and the navbar were both still rendering it at 4.40. Overriding all 74 selectors would be absurd; these are the ones that actually carry body text in this app, and the whole-page audit below is what confirms nothing else was missed. */ .table { color: #627183; } .layout-navbar, .layout-navbar .nav-link { color: #627183; } /* Sidebar text. Both of these were missed on a first automated sweep because the sidebar happened to be collapsed, and collapsed labels have opacity 0 — which the sweep skips as invisible. They were found by checking the menu by hand afterwards, and the section headers were the worst offender anywhere in the app at 2.31, which matters because they are our own markup, added when the Sneat shell landed, not something inherited from the theme's demo pages. Both sit on the menu's white background. */ .bg-menu-theme .menu-link { color: #627183; } .bg-menu-theme .menu-header { color: #697078; } .alert-success, .alert-success .alert-link { color: #407e1f; } .alert-info, .alert-info .alert-link { color: #027790; } .alert-warning, .alert-warning .alert-link { color: #966500; } .alert-danger, .alert-danger .alert-link { color: #c22f16; } .alert-secondary, .alert-secondary .alert-link { color: #606975; } .alert-primary, .alert-primary .alert-link { color: #575ad4; } /* Sneat's soft badge variants reuse the very same foreground/background pairs as the alerts above, so they fail identically — found when the bookings table adopted them for its status chips. Measured before -> after, against each variant's own tinted background: .bg-label-success 1.58 -> 4.54 .bg-label-info 1.83 -> 4.54 .bg-label-warning 1.71 -> 4.55 .bg-label-danger 2.84 -> 4.56 .bg-label-secondary 2.71 -> 4.57 .bg-label-primary 3.33 -> 4.52 `!important` is needed here (and only here) because the theme's own declarations carry it. Badge text is small text for WCAG purposes — the 3:1 large-text allowance does not apply. */ .bg-label-primary { color: #575ad4 !important; } .bg-label-secondary { color: #626c79 !important; } .bg-label-success { color: #407e1f !important; } .bg-label-info { color: #027790 !important; } .bg-label-warning { color: #966500 !important; } .bg-label-danger { color: #c22f16 !important; } /* 1b. Brand colours where they carry text --------------------------------------------------------------------------------------------- The theme's own brand hues are too light to carry white text, and too light to be text on white. Measured on rendered controls, every one of these is below the 4.5:1 required for normal text: btn-primary white on #696cff 4.05 btn-danger white on #ff3e1d 3.52 btn-outline-primary #696cff on white 4.05 btn-outline-secondary #8592a3 on white 3.16 btn-outline-danger #ff3e1d on white 3.52 a (links) #696cff on white 4.05 badge bg-primary white on #696cff 4.05 badge bg-danger white on #ff3e1d 3.52 Three replacement hues cover all of it — and, usefully, one value serves every role each hue plays, because "dark enough to carry white text" and "dark enough to be text on a background" bottom out at the same luminance. All three are calibrated against #f5f5f9 per the note above, which is what makes them pass on the page background as well as inside white cards: primary #696cff -> #5d60e3 (4.05 -> 4.55 on #f5f5f9, 4.94 on white) secondary #8592a3 -> #66707e (3.16 -> 4.62 on #f5f5f9, 5.02 on white) danger #ff3e1d -> #d43318 (3.52 -> 4.51 on #f5f5f9, 4.90 on white) These are a second iteration. The first attempt used #6264ed / #6c7684 / #de3619, calibrated against white only, and the notifications screen — whose list sits directly on the page background — measured them at 4.23, 4.23 and 4.16. Same mistake as the body colours above, made twice; the reference background is the thing to get right first. Scoped deliberately to controls that carry text. Decorative uses of the same hues — per-sala calendar bars, the dashboard's occupancy fills, the active-menu edge bar — are left untouched, so the app still looks like Sneat; only the places where a reader has to make out characters on top of the colour move. Hover and active need their own values, since an outline button *fills* with its colour on hover and a solid one shifts shade. Sneat's own darker shades can't simply be kept: its primary hover (#5f61e6) and active (#595cd9), and its danger hover (#e6381a), are all *lighter* than the corrected bases, so hovering would have brightened the button instead of darkening it. Each hue now steps down from its own new base, restoring the direction as well as the ratio: primary hover #5658d1 (5.66) active #4e51bf (6.46) secondary hover #5c6571 (5.91) danger hover #bf2e16 (5.80) */ .btn-primary { background-color: #5d60e3; border-color: #5d60e3; } .btn-danger { background-color: #d43318; border-color: #d43318; } .btn-outline-primary { color: #5d60e3; } .btn-outline-secondary { color: #66707e; } .btn-outline-danger { color: #d43318; } .btn-primary:hover, .btn-outline-primary:hover { background-color: #5658d1; border-color: #5658d1; } .btn-primary:active, .btn-primary.active, .btn-check:checked + .btn-primary { background-color: #4e51bf; border-color: #4e51bf; } .btn-danger:hover, .btn-outline-danger:hover { background-color: #bf2e16; border-color: #bf2e16; } .btn-outline-secondary:hover { background-color: #5c6571; border-color: #5c6571; } a { color: #5d60e3; } /* The notification list and any other bare .list-group sit straight on the page background, not inside a card, and Sneat hardcodes #697a8d here too — that combination is what put this screen at 4.05 when every other page passed. */ .list-group-item { color: #627183; } /* Only the badge use of these two backgrounds — the bare .bg-primary/.bg-danger utilities stay as the theme defines them, since they also paint surfaces that carry no text. */ .badge.bg-primary { background-color: #5d60e3 !important; } .badge.bg-danger { background-color: #d43318 !important; } /* 2. Active-menu bridge: Sneat's
  • vs Blazor's --------------------------------------------------------------------------------------------- Sneat styles the current page from `.menu-item.active` — the
  • — but Blazor's can only put `active` on the it renders. Rather than reimplement route matching in JS just to move a class up one element, the theme's three active-state rules are restated here against `:has(> .menu-link.active)`, which is the same condition expressed from the other direction. Sources, so a theme update can be diffed against them: core.css:15099 .menu-vertical .menu-item.active:not(.open) > .menu-link theme-default.css:43 .bg-menu-theme .menu-inner > .menu-item.active:before (right-edge bar) theme-default.css:678 .bg-menu-theme .menu-item.active > .menu-link (colour + white pill) */ .menu-vertical .menu-item:has(> .menu-link.active) > .menu-link { font-weight: 600; } .bg-menu-theme .menu-item > .menu-link.active { color: #566a7f; } .bg-menu-theme .menu-item > .menu-link.active:not(.menu-toggle) { background-color: #fff; } .layout-wrapper:not(.layout-horizontal) .bg-menu-theme .menu-inner > .menu-item:has(> .menu-link.active)::before { content: ""; position: absolute; right: 0; width: 0.25rem; height: 2.5rem; border-radius: 0.375rem 0 0 0.375rem; background: #696cff; } /* 3. Desktop sidebar collapse --------------------------------------------------------------------------------------------- Desktop collapse is a Pro-edition feature in Sneat, and the free build withholds MORE than just the JS. The whole `.menu-collapsed:not(:hover)` rule set — the 5.25rem width, the narrowed menu items, the faded labels, the centred icons — sits inside `@media (max-width: 1199.98px)` (core.css:15127-15206), i.e. mobile only. Above 1200px the free build's `layout-menu-collapsed` rules style the app-brand and nothing else (core.css:15713+), so setting the class on its own leaves the sidebar full width with a shrunken brand. So the block below is that rule set restated under `@media (min-width: 1200px)`. Values are copied unchanged so a future theme update can be diffed against core.css:15151-15206 directly. Two deliberate differences: * The rules key off `.layout-menu-collapsed` on rather than the theme's `.menu-collapsed` on the