W3C Validation Failed - Unsolvable CSS validation errors for variables

[modbender]

Version

@nuxtjs/tailwindcss: 6.11.4 nuxt: 3.10.2

Reproduction Link

Any Nuxt 3 project using this tailwind plugin

Steps to reproduce

1. Create Nuxt 3 project
2. Add @nuxtjs/tailwindcss plugin
3. Run npm run generate or yarn generate
4. Run yarn start or npx serve .output/public
5. Go to deployment - usually http://localhost:3000
6. View source for the webpage, search for empty variables like --tw-pan-x: ;--tw-pan-y: ; in <style>.

What is Expected?

W3C valid output is expected.

What is actually happening?

I'm aiming to create a sellable template using Tailwind and I can't lie about the code being w3c validation.

I don't know if it's significant or not in terms of sales, but I atleast hope to aim for creating a w3c valid code.

I have already tested and squashed almost all html validation errors. But yet regardless of what config I use I can't seem to remove CSS variables error. And there are more than 100's of them.

An example can be below: https://validator.w3.org/nu/?doc=https%3A%2F%2Ftailwindcss.nuxtjs.org

This is validation run for https://tailwindcss.nuxtjs.org/, well regardless of it being tailwindcss plugin documentation site, any site using Nuxt 3 tailwind plugin has the same problem.

The configurations I have tried is below: For nuxt.confg.ts

  postcss: {
    plugins: {
      autoprefixer: {},
      "postcss-import": {},
      "tailwindcss/nesting": "postcss-nesting",
      tailwindcss: {},
      "postcss-lightningcss": {
        browsers: ">= .25%",
      },
      ...(process.env.NODE_ENV === "production" ? { cssnano: {} } : {}),
    },
  },

  webpack: {
    extractCSS: false,
    optimizeCSS: true,
  },

My tailwindcss.config.js:

export default {
  theme: {},
  plugins: [require("@tailwindcss/typography")],
  content: [
    "./components/**/*.{vue,js,ts}",
    "./layouts/**/*.vue",
    "./pages/**/*.vue",
    "./composables/**/*.{js,ts}",
    "./plugins/**/*.{js,ts}",
    "./utils/**/*.{js,ts}",
    "./App.{js,ts,vue}",
    "./app.{js,ts,vue}",
    "./Error.{js,ts,vue}",
    "./error.{js,ts,vue}",
    "./app.config.{js,ts}",
  ],
};

I would have accepted that this might be a global problem but I have seen Next.js sites using same headless UI and tailwind css yet not have any of these kinds of errors.

Example: https://swr.vercel.app/ https://validator.w3.org/nu/?doc=https%3A%2F%2Fswr.vercel.app%2F

The site above is using Next.js powered, Nextra (documentation generation site - similar to Nuxt Studio), Headless UI, Tailwind CSS and yet I don't see any variable errors in there.

[ineshbose]

Thanks for reporting. You're right to point this out; see related https://github.com/nuxt-modules/tailwindcss/issues/806#issuecomment-1936401819. Unfortunately, it would seem that even if these variables are not defined and removed, some styles may break.. maybe the behaviour isn't correct yet, but this needs to be investigated further, so I'll be leaving this issue open for now. 👍

[ineshbose]

I'll link this issue currently - https://github.com/tailwindlabs/tailwindcss/issues/7121

[modbender]

Is there any way to move inline css into local css file? @ineshbose I thought switching off extractCSS would do it but it didn't

[ineshbose]

Is there any way to move inline css into local css file? @ineshbose

I thought switching off extractCSS would do it but it didn't

Yes! Sorry forgot to add.. you can get around this using-

export default defineNuxtConfig({
  experimental: {
    inlineSSRStyles: false
  }
})

Based on the discussion of the tailwindlabs/tailwindcss issue above, I'll close this for now and I encourage discussion over there! 🙂

[modbender]

Is there any way to move inline css into local css file? @ineshbose I thought switching off extractCSS would do it but it didn't

Yes! Sorry forgot to add.. you can get around this using-

export default defineNuxtConfig({
  experimental: {
    inlineSSRStyles: false
  }
})

Based on the discussion of the tailwindlabs/tailwindcss issue above, I'll close this for now and I encourage discussion over there! 🙂

This works as a great workaround for anyone looking to get w3c validation fixed