[v4] @apply not effected (SvelteKit, Vite)

[szig83]

What version of Tailwind CSS are you using?

4.0.0-alpha.9

What build tool (or framework if it abstracts the build tool) are you using?

Svelte 5.0.0-next.80, SvelteKit 2.5.4, @tailwindcss/vite 4.0.0-alpha.9, vite 5.2.2

What version of Node.js are you using?

For example: v20.10.0

What browser are you using?

Brave (Chrome), Firefox, Safari

What operating system are you using?

macOS

Reproduction URL

https://github.com/szig83/svelte5-tailwind4
(https://github.com/szig83/svelte5-tailwind4/blob/main/src/routes/%2Bpage.svelte)

Describe your issue
The problematic code snippet can be found in the src/routes/+page.svelte file. I created a custom CSS class where I wanted to use the @apply directive. There is no error during build and runtime, but the @apply directive seems to not take effect.
The div element with the Tailwind class (bg-gray-700) is applied correctly.

[coolemur]

@apply should be deprecated

[szig83]

And what would be the solution if I want to apply Tailwind classes within my own class definition?

[coolemur]

And what would be the solution if I want to apply Tailwind classes within my own class definition?

The main question is why you think you need @apply, not why you don't have it.

Take a look a this: https://twitter.com/adamwathan/status/1226511611592085504?lang=en

[coolemur]

And if you really need it, why not just apply plain CSS class with custom styles?
This must be exceptional use case, not a pattern in your code anyway.

[szig83]

I see. It's logical after all :) Thanks for the info.

[QuentiumYT]

I think it should still be included for CMS that uses content from a WYSIWYG for example. I do have some default styles using Tailwind for some blocs :)

[fweth]

I like @apply, but I think it might be less relevant in v4 when everything is configured via custom properties, as you can access those also in vanilla CSS.

[aaronadamsCA]

Just because there are lots of bad use cases for @apply doesn't mean there aren't some great ones too!

If anything, given v4 ships CSS-first configuration and built-in nesting support, I think the use case for @apply is even stronger than it was before.

For example, roll your own .prose class for styling HTML you don't control:

@layer components {
  .prose {
    @apply text-neutral-700 *:first:mt-0 *:last:mb-0;
    caption {
      @apply caption-bottom mt-4 text-left text-xs;
    }
    del {
      @apply opacity-70;
    }
    iframe {
      @apply border-0;
    }
    p {
      @apply my-4;
    }
    /* etc. etc. etc. */
  }
}

This approach stays true to Tailwind, but is much more readable than the alternative. I'd love to see this supported.

[coolemur]

Just because there are lots of bad use cases for @apply doesn't mean there aren't some great ones too!

If anything, given v4 ships CSS-first configuration and built-in nesting support, I think the use case for @apply is even stronger than it was before.

For example, roll your own .prose class for styling HTML you don't control:

@layer components {
  .prose {
    @apply text-neutral-700 *:first:mt-0 *:last:mb-0;
    caption {
      @apply caption-bottom mt-4 text-left text-xs;
    }
    del {
      @apply opacity-70;
    }
    iframe {
      @apply border-0;
    }
    p {
      @apply my-4;
    }
    /* etc. etc. etc. */
  }
}

This approach stays true to Tailwind, but is much more readable than the alternative. I'd love to see this supported.

Yes and no.

By enabling @apply you open door to abusing it
(And developers will. Espacially in larger code bases. You won't be able to enforce the rule "don't create custom utils using @apply - which defeats the purpose of Tailwind")

And this prose case is just exception that could be handled using pure CSS instead of applying styles.

[coolemur]

To those who disagree - wait till you work on big scale project with larger team who will abuse @apply rule... Then you will understand my concern. 🤙

[fweth]

I don't think software should make itself non-abusable. If @apply is difficult to maintain and there are more important features that could use those ressources, then sure, drop it. But otherwise, I'd say it's the responsibility of the library users to ensure clean code, not the responsibility of the library authors.

[QuentiumYT]

I agree, a lot of developers write the code how they want. We should have the ability to choose what to write and how we use the features. Indeed, there is some good and bad ways but sometimes we have to use some "deprecated" features rather than the forced way to do it.

[coolemur]

I don't agree, seeing abused code on a daily basis where it could be solved worldwide with a single opinionated solution 🙃

It's like seatbelts or DUI - if ppl had freedom, they would make big mistakes.

And I am telling you right-now: freedom + saying "don't use it" will not work. 😆