Is there a way to get classes back instead of PostCSS styles? about tailwindcss-typography HOT 7 CLOSED

By the way, if anyone’s curious how this plugin actually works, here‘s the generated CSS for .prose classes from https://tailwindcss-typography.netlify.app.

from tailwindcss-typography.

Sorry I'm not sure what you mean by "PostCSS-style ones", the plugin just generates regular CSS. Can you explain what output you actually want in concrete terms with examples?

from tailwindcss-typography.

Hey Adam! Thanks for the quick reply. Sorry I lost you there.

By PostCSS-styles, I meant basically this:

module.exports = {
  default: {
    css: [
      {
        color: defaultTheme.colors.gray[700],
        maxWidth: '65ch',
        '[class~="lead"]': {
          color: defaultTheme.colors.gray[700],
        },
        // ...

What I’m hoping to get from this plugin is the corresponding Tailwind CSS classes.

So for example, instead of:

        a: {
          color: defaultTheme.colors.gray[900],
          textDecoration: 'underline',
        },

It would be really nice if the plugin or similar can generate:

.prose a {
    @apply text-gray-900 underline
}

This may very well be a non-goal, but it would be really nice if there was parity between Tailwind classes and your styles.js implementation.

I totally get that this may be a non-goal.

from tailwindcss-typography.

I still don't think I understand the problem you're trying to solve, sorry, haha...

Both of those things generate the exact same CSS. What does it matter to you how it's implemented internally? What can you do if we implement it with apply that you can't do now?

from tailwindcss-typography.

Very fair point.

I’m curious about finding dramatically simpler ways of styling articles without using CSS/PostCSS unless necessary. So for context, this is a concept for how someone might be able to style an article in Tailwind CSS: https://gist.github.com/codex-zaydek/f7e87dce51ad4e3c34f0e51853818d4f.

The concept here is that someone can style an article with dramatically less effort because they can think in terms of Tailwind CSS classes. Finally, if they need more control, they can opt-in to styles or even components.

<TailwindArticle
  h1="font-semibold text-3xl leading-tight text-black antialiased"
  emoji={{ verticalAlign: "-10%", fontSize: "120%", lineHeight: 1 }}
>
  <h1>
    Hello, world! <span className="emoji">😀</span>
  </h1>
</TailwindArticle>

Would generate:

<h1 className="font-semibold text-3xl leading-tight text-black antialiased">
  Hello, world! <span style={{ verticalAlign: "-10%", fontSize: "120%", lineHeight: 1 }}>😀</span>
</h1>

Basically. I’m not sure this is a good idea yet, but the point is by having access to the 90% Tailwind classes this plugin uses, it’s much easier to bootstrap these kinds of ideas.

Personally, I want to be able to style articles using Tailwind CSS classes. This plugin would force me to think in PostCSS/Tailwind JS which is fine, but I’m personally interested in the Tailwind CSS class-based approach.

I hope that makes more sense. I get that this may be outside of your goals for this plugin, but as a Tailwind CSS user, I was hoping to have more visibility into the Tailwind CSS classes this plugin uses, not just the compiled CSS.

from tailwindcss-typography.

Gotcha, so there's a couple reasons we have done it internally the way we have instead of using @apply:

1. There is no guarantee the classes we are trying to apply actually exist. If we say @apply text-3xl but the user has changed their font size configuration, the build would fail. So we instead reference the default Tailwind theme, where we know exactly what exists and what doesn't, and if someone wants to override something because they've changed a color or whatever they can do that by configuring the typography plugin itself.

2. We wanted to define all spacing and sizing in em instead of rem, so that if someone made a simple customization like changing the font size in the plugin, everything would scale somewhat sensibly and nothing would be completely broken.

There are also a lot of rules that are contextual, like we do stuff like h1 + * for example to override the margin on anything following an h1. Using your approach you'll run into issues there, because you might say <TailwindArticle p="my-6"> but you don't have a way of overriding the top margin to 0 when the p tag is following an h1 without reimplementing CSS syntax all over again, like <TailwindArticle 'h1+*'="mt-0"> or something, which I don't even think is valid JSX.

I've tried what you are trying to do here using MDX and the MDXProvider configuration to add class names to each element and it fell apart quickly because of the contextual differences in styles.

At a high level I think the important thing to think about here is that Tailwind classes are not set in stone, they are a build artifact that depend on your personal theme configuration, so the theme is the source of truth, not the classes themselves.

Either way you can definitely use our styles as inspiration to build what you're building, just look through our styles.js file and translate as much of it as you can to a class-based approach. We don't consider the styles.js file to be an export or anything, so actually pulling it in and using it would always be at-your-own-risk.

So for the reasons outlined above no plans to change this unfortunately 👍

from tailwindcss-typography.

Thanks for replying! I’m grateful for your interaction.

I agree with your perspective and can now understand why you pushed for a PostCSS-first approach. Thank you for clearly outlining your reasons.

All the best. 😀

from tailwindcss-typography.