\n\n\namber: not applied\n\u003Cimg width=\"435\" height=\"134\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/b9cffe65-9d2a-41f2-8e9d-b0dcb17ac4f4\" />\n\n### Description\n\n### Describe the bug\n\nWhen using `UInput`, the `color` prop sometimes fails to apply to the icon (`leading-icon` or `trailing-icon`). Specifically, if the color value is lexicographically *before* `\"gray\"` (e.g., `\"blue\"`), the icon appears with the `gray` color instead. If the color value is after `\"gray\"` (e.g., `\"red\"`, `\"teal\"`), it works correctly.\n\n### Expected behavior\n\nThe icon color should follow the specified `color` prop regardless of its string value.\n\n### Actual behavior\n\nFor certain colors (like `\"blue\"`), the icon appears with `gray` color instead of the specified color.\n\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\n\n```",[3137,3140],{"name":3138,"color":3139},"bug","d73a4a",{"name":3141,"color":3142},"triage","ffffff",4525,"nuxt","ui","open","color prop on UInput does not apply to icon in some cases","2025-07-14T10:36:41Z","https://github.com/nuxt/ui/issues/4525",0.6997831,{"description":3152,"labels":3153,"number":3157,"owner":3144,"repository":3144,"state":3146,"title":3158,"updated_at":3159,"url":3160,"score":3161},"### Environment\n\n------------------------------\r\n- Operating System: Linux\r\n- Node Version: v20.11.0\r\n- Nuxt Version: 3.11.2\r\n- CLI Version: 3.11.1\r\n- Nitro Version: 2.9.6\r\n- Package Manager: pnpm@9.1.4\r\n- Builder: -\r\n- User Config: modules, experimental, ssr, css, colorMode, nitro, app, pwa, devtools, eslintConfig, i18n, vite, runtimeConfig\r\n- Runtime Modules: @vueuse/nuxt@10.10.0, @unocss/nuxt@0.58.9, @pinia/nuxt@0.5.1, @pinia-plugin-persistedstate/nuxt@1.2.0, @nuxtjs/color-mode@3.4.1, @vite-pwa/nuxt@0.4.0, @bg-dev/nuxt-naiveui@1.10.1, @nuxtjs/i18n@8.3.1, unplugin-icons/nuxt, nuxt-module-eslint-config@0.1.1\r\n- Build Modules: -\r\n------------------------------\r\n\n\n### Reproduction\n\nNuxt Config:\r\n```ts\r\nexport default defineNuxtConfig({\r\n // ...\r\n runtimeConfig: {\r\n public: {\r\n test: 'prerendered \"test value\" (default)',\r\n onlyRuntime: 'prerendered \"only runtime value\" (default)'\r\n },\r\n },\r\n nitro: {\r\n esbuild: {\r\n options: {\r\n target: 'esnext',\r\n },\r\n },\r\n prerender: {\r\n crawlLinks: false,\r\n routes: ['/'],\r\n },\r\n },\r\n // ...\r\n})\r\n```\r\n\r\n`pages/index.vue`\r\n\r\n```vue\r\n\u003Ctemplate>\r\n \u003Cdiv>\r\n \u003Ch1>This Page is prerendered\u003C/h1>\r\n {{config.public.test}} \u003Cbr>\r\n \u003CNuxtLink to=\"/test\">SSR page\u003C/NuxtLink>\r\n \u003C/div>\r\n\u003C/template>\r\n\r\n\u003Cscript setup lang=\"ts\">\r\nconst config = useRuntimeConfig()\r\n\u003C/script>\r\n```\r\n\r\n`pages/test.vue`\r\n\r\n```vue\r\n\u003Ctemplate>\r\n \u003Cdiv>\r\n \u003Ch1>This Page is not prerendered\u003C/h1>\r\n {{config.public.test}}\u003Cbr>\r\n {{config.public.onlyRuntime}}\u003Cbr>\r\n \u003CNuxtLink to=\"/\">prerendered Page\u003C/NuxtLink>\r\n \u003C/div>\r\n\u003C/template>\r\n\r\n\u003Cscript setup lang=\"ts\">\r\nconst config = useRuntimeConfig()\r\n\u003C/script>\r\n```\r\n\r\nenv for `node .output/server/index.mjs`\r\n\r\n```yaml\r\n environment:\r\n - NUXT_PUBLIC_TEST=runtime \"test value\"\r\n - NUXT_PUBLIC_ONLY_RUNTIME=runtime \"only runtime value\"\r\n```\r\n\r\nlink to deployed version: https://app.runtime-config-example.v2.singular-it-test.de/\n\n### Describe the bug\n\nSteps:\r\n1. open https://app.runtime-config-example.v2.singular-it-test.de/\r\n2. see varaibles\r\n3. navigate to SSR page\r\n4. variables are still from builttime\r\n5. refresh page\r\n6. variables are now from runtime\r\n7. navigate back to prerendered\r\n8. variables are still runtime\n\n### Additional context\n\ni think it will be intended that way, but i find the behavior of the runtimeConfig sometimes a bit inconsistent, especially if you prerender parts of the app and others not. (and thus also with regard to the caching of pwa). Depending on the entry point in the app (i.e. whether generated or dynamic), this can lead to different configs, which then persist between the dynamic and static pages. \r\n\r\ni don't expect prerendered parts of the app to pick up the runtime config, but i would assume that when i switch from a static to a non-static page, the runtime variables also play a role. Otherwise, as soon as prerender is active, everything should be set at build time (so that there can no longer be a runtime config) and everything is/needs to be set in the build step to avoid differences depending on the entry point.\r\n\r\nI know that it is not necessarily common to have a different config for generation than for runtime, but especially in my case it is not necessary to set all variables in the build (prerender). and generally the runtime config is also there to set the variables when running the app.\n\n### Logs\n\n_No response_",[3154],{"name":3155,"color":3156},"pending triage","E99695",28847,"strange runtimeConfig behaviour when prerendering parts of the app","2024-09-06T11:27:57Z","https://github.com/nuxt/nuxt/issues/28847",0.7180863,{"description":3163,"labels":3164,"number":3167,"owner":3144,"repository":3145,"state":3146,"title":3168,"updated_at":3169,"url":3170,"score":3171},"### Environment\n\n- Operating System: Linux\n- Node Version: v18.20.6\n- Nuxt Version: 3.17.4\n- CLI Version: 3.26.2\n- Nitro Version: 2.12.0\n- Package Manager: bun@1.2.18\n- Builder: -\n- User Config: ssr, compatibilityDate, devtools, css, modules, gtag, nitro, vite, app, icon, ui, uiPro, i18n, runtimeConfig, plugins, dayjs, hooks, sentry, sourcemap\n- Runtime Modules: @nuxtjs/i18n@9.5.6, @nuxt/eslint@1.3.0, @nuxt/ui-pro@3.3.3, @nuxtjs/mdc@0.17.1, dayjs-nuxt@2.1.11, nuxt-gtag@3.0.3, @sentry/nuxt/module@9.41.0\n- Build Modules: -\n\n### Is this bug related to Nuxt or Vue?\n\nNuxt\n\n### Package\n\nv3.x\n\n### Version\n\n3.17.4\n\n### Reproduction\n\n```\n \u003CUAvatarGroup\n v-if=\"sharedUsers.length\"\n :max=\"3\"\n size=\"sm\"\n @click=\"isShareProjectModalOpen = true\"\n >\n \u003CUTooltip\n v-for=\"user in sharedUsers\"\n :key=\"user.emailAddress\"\n :text=\"user.fullName ?? user.emailAddress\"\n :delay-duration=\"0\"\n >\n \u003CUAvatar\n :src=\"user.avatar ?? undefined\"\n :alt=\"user.fullName ?? user.emailAddress\"\n />\n \u003C/UTooltip>\n \u003C/UAvatarGroup>\n```\n\n---\n```\n \u003CShareProjectModal\n v-if=\"project\"\n v-model:open=\"isShareProjectModalOpen\"\n :project=\"project\"\n :template-name=\"project.template.name\"\n :primary-document-references=\"project.template.primary_document_reference?.map(d => d.name) || []\"\n />\n```\n\nSharedModal\n\n```\n \u003CUModal\n v-model:open=\"isOpen\"\n :ui=\"{\n content: 'max-w-124',\n footer: 'justify-between',\n body: 'flex flex-col gap-4 px-0 sm:px-0',\n }\"\n >\n\n\u003C/UModal>\n```\n\n\n### Description\n\n\nHi, we are using v4 with an avatarGroup tooltip\n```\n \u003CUAvatarGroup\n v-if=\"sharedUsers.length\"\n :max=\"3\"\n size=\"sm\"\n @click=\"isShareProjectModalOpen = true\"\n >\n \u003CUTooltip\n v-for=\"user in sharedUsers\"\n :key=\"user.emailAddress\"\n :text=\"user.fullName ?? user.emailAddress\"\n :delay-duration=\"0\"\n >\n \u003CUAvatar\n :src=\"user.avatar ?? undefined\"\n :alt=\"user.fullName ?? user.emailAddress\"\n />\n \u003C/UTooltip>\n \u003C/UAvatarGroup>\n```\n\nWe have few modal opening on the same page however we have inconsistency with the tooltip when playing around opening UModal on the page the tooltip would stop working. has anyone encounter such issue?\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\n\n```",[3165,3166],{"name":3138,"color":3139},{"name":3141,"color":3142},4903,"AvatarGroup & Tooltip","2025-09-08T01:56:54Z","https://github.com/nuxt/ui/issues/4903",0.7279865,{"description":3173,"labels":3174,"number":3186,"owner":3144,"repository":3145,"state":3187,"title":3188,"updated_at":3189,"url":3190,"score":3191},"### Environment\n\n- Operating System: Linux\n- Node Version: v22.4.0\n- Nuxt Version: 3.14.1592\n- CLI Version: 3.16.0\n- Nitro Version: 2.10.4\n- Package Manager: pnpm@9.14.4\n- Builder: -\n- User Config: default\n- Runtime Modules: @nuxt/ui@3.0.0-alpha.9, nuxt-auth-sanctum@0.5.2, @vueuse/nuxt@11.3.0, nuxt-file-storage@0.2.9\n- Build Modules: -\n\n### Is this bug related to Nuxt or Vue?\n\nNuxt\n\n### Version\n\n3.14.1592\n\n### Reproduction\n\n```vue\n\u003Cscript setup lang=\"ts\">\nconst bill = defineModel()\nconst calcStep = (value: int): int => value \u003C 1000 ? 100 : 500\n\u003C/script>\n\n\u003Ctemplate>\n \u003Cdiv class=\"flex gap-4 items-center\">\n от \u003CUInputNumber v-model=\"bill.from\" :min=\"0\" :max=\"bill.to || 10000\" :step=\"calcStep(bill.from)\" variant=\"soft\" class=\"max-w-32\" />\n до \u003CUInputNumber v-model=\"bill.to\" :min=\"bill.from\" :max=\"10000\" :step=\"calcStep(bill.to)\" variant=\"soft\" class=\"max-w-32\" />\n \u003C/div>\n\u003C/template>\n```\n\n### Description\n\nhttps://skr.sh/vT5m5gCX1Bk\n\nThe value changes when clicking outside the field, regardless of the `step` and `modelValue` state. The `step` parameter is also calculated incorrectly at the threshold of 1000.",[3175,3176,3179,3182,3183],{"name":3138,"color":3139},{"name":3177,"color":3178},"needs reproduction","CB47CF",{"name":3180,"color":3181},"v3","49DCB8",{"name":3141,"color":3142},{"name":3184,"color":3185},"closed-by-bot","ededed",2859,"closed","UInputNumber changes value on blur when not asked for","2025-06-19T02:15:22Z","https://github.com/nuxt/ui/issues/2859",0.6813311,{"description":3193,"labels":3194,"number":3198,"owner":3144,"repository":3145,"state":3187,"title":3199,"updated_at":3200,"url":3201,"score":3202},"### Environment\n\n```\n Operating System: Linux\n Node Version: v18.19.1\n Nuxt Version: 3.16.0\n CLI Version: 3.23.0\n Nitro Version: 2.11.6\n Package Manager: npm@10.2.4\n Builder: -\n User Config: compatibilityDate, devtools, colorMode, modules, css, i18n, runtimeConfig\n Runtime Modules: @nuxt/eslint@1.2.0, @nuxt/ui@3.1.3, @nuxt/test-utils@3.17.2, @nuxt/icon@1.13.0, @nuxtjs/i18n@9.3.1 @pinia/nuxt@0.10.1, @nuxt/image@1.10.0\n Build Modules: -\n```\n\n### Is this bug related to Nuxt or Vue?\n\nNuxt\n\n### Version\n\n3.16.0\n\n### Reproduction\n\nhttps://codesandbox.io/p/devbox/goofy-yalow-xftq2n\n\n### Description\n\nI've set value of `--ui-text-dimmed` to red. If I use `text-dimmed` on paragraph its text color is red. However input's placeholder color is not affected (even though it has placeholder:text-dimmed class by default)\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\n\n```",[3195,3196,3197],{"name":3138,"color":3139},{"name":3180,"color":3181},{"name":3141,"color":3142},4301,"Input's placeholder doesn't respect value of `--ui-text-dimmed`","2025-08-07T13:34:03Z","https://github.com/nuxt/ui/issues/4301",0.7037976,{"description":3204,"labels":3205,"number":3212,"owner":3144,"repository":3145,"state":3187,"title":3213,"updated_at":3214,"url":3215,"score":3216},"### Environment\r\n\r\n- Operating System: Windows_NT\r\n- Node Version: v18.19.1\r\n- Nuxt Version: 3.11.2\r\n- CLI Version: 3.11.1\r\n- Nitro Version: 2.9.6\r\n- Package Manager: pnpm@8.11.0\r\n- Builder: -\r\n- User Config: devtools, modules, tailwindcss, i18n, runtimeConfig\r\n- Runtime Modules: @pinia/nuxt@0.5.1, @nuxt/ui@2.15.2-28557281.8d9d973, @nuxtjs/i18n@8.3.0, @vueuse/nuxt@10.9.0\r\n- Build Modules: -\r\n\r\n### Version\r\n\r\nnpm:@nuxt/ui-edge@latest\r\n\r\n### Reproduction\r\n\r\n const coverInfoStore = useCoverInfoStore()\r\n\r\n\u003CUTextarea v-model=\"coverInfoStore.coverTitle\" />\r\n \u003CUInput v-model=\"coverInfoStore.coverTitle\" />\r\n\r\n### Description\r\n\r\nProblem:\r\nWhen using UTextarea component in conjunction with pinia and v-model, there is an inconsistency in behavior compared to using UInput.\r\n\r\nExpected Behavior:\r\nBoth UInput and UTextarea should behave consistently when used with pinia and v-model. Updates to the bound data should reflect immediately in both components.\r\n\r\nActual Behavior:\r\n\r\nWhen updating the data bound to UInput using v-model, the changes are reflected immediately in the UI.\r\nHowever, when updating the data bound to UTextarea using v-model, the changes are not reflected immediately. \r\n\r\n### Additional context\r\n\r\n\r\n\r\n\r\n### Logs\r\n\r\n_No response_",[3206,3209,3210],{"name":3207,"color":3208},"question","d876e3",{"name":3184,"color":3185},{"name":3211,"color":3185},"stale",1701,"Inconsistent behavior with UTextarea, pinia, and v-model compared to UInput","2025-06-19T02:12:43Z","https://github.com/nuxt/ui/issues/1701",0.71137553,{"description":3218,"labels":3219,"number":3224,"owner":3144,"repository":3144,"state":3187,"title":3225,"updated_at":3226,"url":3227,"score":3228},"### Environment\n\n- Operating System: `Darwin`\n- Node Version: `v22.17.0`\n- Nuxt Version: `4.0.3`\n- CLI Version: `3.27.0`\n- Nitro Version: `2.12.4`\n- Package Manager: `pnpm@10.14.0`\n- Builder: `-`\n- User Config: `modules`, `pages`, `dir`, `vite`, `typescript`\n- Runtime Modules: `()`, `()`\n- Build Modules: `-`\n\n\n### Reproduction\n\nhttps://stackblitz.com/edit/github-wzqq2xfw?file=app/app.vue\n\n### Describe the bug\n\nI noticed that after building Nuxt, the `%` unit in CSS gets stripped from all values that are `0`, which causes the `linear()` timing function to break, because it always expects a percentage on the right side.\n\n```css\n.example {\n transition-timing-function: linear(0 0%, 1 100%);\n}\n```\n\n\u003Cimg width=\"341\" height=\"46\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/4c4773e8-25c4-4c88-ab33-9697c9d685a5\" />\n\n### Steps to reproduce\n1. run `pnpm build`\n2. run `pnpm preview`\n3. inspect the CSS of the `Example` div\n\n### Additional context\n\nMight not be a Nuxt bug, but I wasn't able to reproduce it in plain Vue: https://stackblitz.com/edit/vitejs-vite-u8bwhrqx?file=src/App.vue&terminal=dev\n\n### Logs\n\n```shell-script\n\n```",[3220,3221],{"name":3155,"color":3156},{"name":3222,"color":3223},"upstream","E8A36D",33014,"CSS unit stripped after build in the `linear()` timing function causes it to break","2025-08-20T11:04:16Z","https://github.com/nuxt/nuxt/issues/33014",0.7129909,{"description":3230,"labels":3231,"number":3234,"owner":3144,"repository":3145,"state":3187,"title":3235,"updated_at":3236,"url":3237,"score":3238},"### Environment\n\n- Operating System: Darwin\n- Node Version: v22.13.1\n- Nuxt Version: 3.16.2\n- CLI Version: 3.24.1\n- Nitro Version: 2.11.8\n- Package Manager: pnpm@10.8.1\n- Builder: -\n- User Config: app, compatibilityDate, css, devtools, devServer, eslint, imports, modules, runtimeConfig, sourcemap, ssr, icon, ui, colorMode\n- Runtime Modules: @nuxt/eslint@1.3.0, @nuxt/ui@3.0.2, @vueuse/nuxt@13.0.0\n- Build Modules: -\n\n### Is this bug related to Nuxt or Vue?\n\nNuxt\n\n### Version\n\nv3.0.2\n\n### Reproduction\n\nhttps://codesandbox.io/p/devbox/condescending-mcnulty-k5jgtf\n\n### Description\n\nHi 👋,\n\nI’ve noticed an issue with the `ColorPicker` component related to color precision.\n\n🐛 Bug Description\n\nWhen I manually input the hex value `#123456` into the `ColorPicker`, it gets changed to `#123354` immediately.\n\nAfter digging into the source code, I found that the component uses `colortranslator` and internally converts colors via HSL using HSLObject. It appears that during the RGB → HSL → RGB round-trip, there’s a slight loss of precision, which results in the hex value being altered.\n\nIt seems that the issue might be caused by the `decimals` option being set to `2`, while the default value in `colortranslator` is `6`. \n\nhttps://github.com/nuxt/ui/blob/2b315fd855666b02d32373769c8617dd713a8d0a/src/runtime/components/ColorPicker.vue#L104-L109\n\nOr `Math.round` here:\n\nhttps://github.com/nuxt/ui/blob/2b315fd855666b02d32373769c8617dd713a8d0a/src/runtime/components/ColorPicker.vue#L28-L36\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\n\n```",[3232,3233],{"name":3138,"color":3139},{"name":3180,"color":3181},3948,"[ColorPicker] ColorPicker alters manually entered hex value due to precision loss in colortranslator","2025-07-19T17:49:20Z","https://github.com/nuxt/ui/issues/3948",0.71791935,{"description":3240,"labels":3241,"number":3245,"owner":3144,"repository":3145,"state":3187,"title":3246,"updated_at":3247,"url":3248,"score":3249},"### Environment\r\n\r\n- Operating System: Windows_NT\r\n- Node Version: v20.12.2\r\n- Nuxt Version: 3.10.3\r\n- CLI Version: 3.10.1\r\n- Nitro Version: 2.9.1\r\n- Package Manager: pnpm@8.3.1\r\n- Builder: -\r\n- User Config: app, colorMode, ui, css, modules, runtimeConfig, authJs, pinia, nitro, alias, devtools, imports, typescript\r\n- Runtime Modules: @pinia/nuxt@0.4.11, @pinia-plugin-persistedstate/nuxt@1.2.0, @vueuse/nuxt@9.13.0, @hebilicious/authjs-nuxt@0.3.0-beta.2, @nuxtjs/eslint-module@4.1.0, nuxt-monaco-editor@1.2.7, nuxt-lodash@2.5.3, @nuxt/ui@2.14.2\r\n- Build Modules: -\r\n\r\n### Version\r\n\r\nv2.14.2\r\n\r\n### Reproduction\r\n\r\nhttps://stackblitz.com/edit/nuxt-ui-eqhn2j?file=app.vue\r\n\r\n### Description\r\n\r\nI'm getting multiple new type errors that I wasn't getting before with types that used to be valid. I think this is being caused by an update to `vue-tsc`, however I'm not sure.\r\n\r\nIn the reproduction link you can see the two examples that don't compile. Simply run `npm run typecheck` in the console to get the errors\r\nHere are the minimal examples\r\n```html\r\n\u003Cscript setup lang=\"ts\">\r\nconst value = ref\u003Cstring | null | undefined>(undefined);\r\n\u003C/script>\r\n\r\n\u003Ctemplate>\r\n \u003Cdiv>\r\n \u003CUInput v-model.trim=\"value\" />\r\n \u003C/div>\r\n\u003C/template>\r\n```\r\n```shell-script\r\nTS2322: Type 'string | null | undefined' is not assignable to type 'string | number | undefined'.\r\n```\r\n```html\r\n\u003Cscript setup lang=\"ts\">\r\nconst value = ref\u003Cboolean|undefined>();\r\nconst options = [\r\n {\r\n label: 'Yes',\r\n value: true\r\n },\r\n {\r\n label: 'No',\r\n value: false\r\n },\r\n {\r\n label: 'None selected',\r\n value: undefined\r\n }\r\n];\r\n\u003C/script>\r\n\u003Ctemplate>\r\n \u003Cdiv>\r\n \u003CUSelectMenu\r\n :options=\"options\"\r\n v-model=\"value\"\r\n value-attribute=\"value\" option-attribute=\"label\"\r\n />\r\n \u003C/div>\r\n\u003C/template>\r\n```\r\n```shell-script\r\nTS2322: Type 'boolean | undefined' is not assignable to type 'string | number | Record\u003Cstring, any> | unknown[] | undefined'.\r\n```\r\n\r\n### Additional context\r\n\r\n\r\n### Logs\r\n\r\n```shell-script\r\napp.vue:14:15 - error TS2322: Type 'string | null | undefined' is not assignable to type 'string | number | undefined'.\r\n\r\n14 \u003CUInput v-model.trim=\"inputValue\" />\r\n ~~~~~~~~~~\r\n\r\n node_modules/@nuxt/ui/dist/runtime/components/forms/Input.vue.d.ts:244:5\r\n 244 modelValue: string | number;\r\n ~~~~~~~~~~\r\n The expected type comes from property 'modelValue' which is declared here on type 'Partial\u003C{ size: InputSize; ui: any; id: string; icon: string; color: any; type: string; class: any; name: string; modelValue: string | number; leading: boolean; variant: InputVariant; ... 12 more ...; modelModifiers: { ...; }; }> & Omit\u003C...> & Record\u003C...>'\r\n\r\n\r\nFound 1 error in app.vue:14\r\n```\r\n",[3242,3243,3244],{"name":3138,"color":3139},{"name":3184,"color":3185},{"name":3211,"color":3185},1710,"Unable to use boolean values with USelectMenu or null with UInput","2025-06-19T02:12:37Z","https://github.com/nuxt/ui/issues/1710",0.7210653,{"description":3251,"labels":3252,"number":3263,"owner":3144,"repository":3144,"state":3187,"title":3264,"updated_at":3265,"url":3266,"score":3267},"### Environment\n\n- Operating System: Linux\r\n- Node Version: v16.20.0\r\n- Nuxt Version: 3.7.1\r\n- CLI Version: 3.7.3\r\n- Nitro Version: 2.6.2\r\n- Package Manager: npm@9.4.2\r\n- Builder: -\r\n- User Config: experimental\r\n- Runtime Modules: -\r\n- Build Modules: -\n\n### Reproduction\n\nYou can use my old preproduction from #23051 https://stackblitz.com/edit/github-ydxe3t?file=pages%2Findex.vue\r\n\r\nSee that the scoped style (margin) applies to the component. However, if you update Nuxt to 3.7.3, the style no longer applies, since the data-v attribute was removed. \n\n### Describe the bug\n\nThe issue #23051 was fixed in #23095.\r\n\r\nHowever, this prevented scoped style from being applied to the component. \r\n\n\n### Additional context\n\nSorry for the delayed feedback. As I noted in https://github.com/nuxt/nuxt/pull/23095#issuecomment-1712583276 the removal of data-v attribute entirely lead to styles not being reproduced. I already debugged the issue and I'm going to create a PR with a simple suggested fix.\r\n\r\nThis PR will revert the expected behavior of scoped styles as in 3.7.1 while keeping @huang-julien 's fix for 404 on soft navigation due to different component hash.\n\n### Logs\n\n_No response_",[3253,3256,3257,3260],{"name":3254,"color":3255},"3.x","29bc7f",{"name":3138,"color":3139},{"name":3258,"color":3259},"🔨 p3-minor","FBCA04",{"name":3261,"color":3262},"server components","839413",23385,"Fix for #23051 broke scoped styles in server components","2023-09-28T07:36:15Z","https://github.com/nuxt/nuxt/issues/23385",0.72289854,["Reactive",3269],{},["Set"],["ShallowReactive",3272],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fTJ3-v2ajxIspWKuiCa-L7xwp8gPk2qyJZJPyh2_SM0o":-1},"/nuxt/ui/4646"]