Let the color prop work on snackbars - #845
Merged
Merged
Conversation
Every snackbar rendered on the app background instead of its own color. ``.v-snackbar__wrapper`` is a ``.v-overlay__content``, and app.vue painted all of those the theme background with ``!important`` from outside any cascade layer. Vuetify's ``bg-error`` / ``bg-warning`` classes live inside ``vuetify-utilities.theme-background``, so they never stood a chance: an unlayered declaration outranks a layered one whatever the specificity. Split the rule. The radius still applies to every overlay; the background now skips snackbar wrappers, so ``color`` reaches the element it is meant to paint. Menus, dialogs and tooltips keep the background they had. Give VSnackbar a default of ``color: "background"`` as well. Without it an uncolored snackbar would fall back to Vuetify's Material inverse surface, a light bar in this dark theme, and to unreadable dark-on-dark text. The default keeps today's look and explicit colors still win. The docker-hub snackbar no longer needs its local two-class override, so drop that and the marker class it existed for. Verified in the dev server: session-error paints rgb(220,20,60), filter-warning and docker-hub rgb(230,189,13), an uncolored snackbar rgb(18,18,18); menu, dialog and tooltip content boxes are unchanged at rgb(18,18,18) with the 5px radius and the tooltip's dimmed text. The production bundle keeps the layer order and leaves the app rules unlayered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
session-error-snackbar.vue(color="error") andfilter-warning-snackbar.vue(color="warning") both rendered on the app background instead of their color..v-snackbar__wrapperis a.v-overlay__content, andapp.vuepainted all of those the theme background with!importantfrom outside any cascade layer:Vuetify's
bg-error/bg-warningutilities live inside@layer vuetify-utilities.theme-background, so they never stood a chance. An unlayered declaration outranks a layered one regardless of specificity, so no amount of specificity from the snackbar's end could win.Worth noting: Vuetify's own
.v-snackbar--variant-elevatedrule is not part of the problem on 4.2.1. It sits in@layer vuetify-components, which thebg-*layer already beats. Deleting only theapp.vuerule in a live page turned the error snackbar crimson, so the global rule was the sole cause.The fix
Split the rule in
app.vue. The radius still applies to every overlay; the background now skips snackbar wrappers.VSnackbaralso gets a default ofcolor: "background"in the Vuetify plugin. Without one, an uncolored snackbar would now fall back to Vuetify's Material inverse surface, a light bar in this dark theme with unreadable dark-on-dark text. The default preserves today's look, and an explicitcolorprop still wins.docker-hub-deprecated-snackbar.vueno longer needs its local two-class!importantoverride, so that and the marker class it existed for are gone.Verification
Dev server, Vuetify 4.2.1, computed styles on the live elements:
error)rgb(220, 20, 60)rgb(255, 255, 255)warning)rgb(230, 189, 13)rgb(0, 0, 0)warning, no local override)rgb(230, 189, 13)rgb(0, 0, 0)colorrgb(18, 18, 18)rgb(255, 255, 255)Unchanged, matching the pre-change baseline:
rgb(18, 18, 18)5pxrgb(18, 18, 18)5pxrgb(18, 18, 18), textrgb(128, 128, 128)5pxThe production bundle was checked too: it keeps the layer order (
vuetify-core→vuetify-components→vuetify-overrides→vuetify-utilities→vuetify-final) and leaves the app rules unlayered, so the cascade behaves the same as in dev.make fixproduced no changes,make lintexits 0, andbunx vitest runpasses 53 files / 500 tests.🤖 Generated with Claude Code