Typography unused code not removed with JIT (tw 3)

[istr]

What version of @tailwindcss/typography are you using?

v0.5.0

What version of Node.js are you using?

v16.13.2

What browser are you using?

Chrome, Brave, Firefox

What operating system are you using?

Linux

Reproduction repository

https://github.com/istr/tw-typo-nojit

Describe your issue

The typography plugin seems to always add all classes, regardless of the content that the tailwind 3 JIT detects.
This leads to exactly the kind of bloat tw / JIT wanted to avoid.

To reproduce:

git clone https://github.com/istr/tw-typo-nojit.git ; cd tw-typo-nojit/ ; npm install ; npm start

Since index.html does not contain blockquote it is expected that dist/output.css does not contain the CSS for that.
This is only an example, lots of unused variables and unused code is introduced by the plugin.

[istr]

Probably the root cause is the massive usage of :where in typography that the defaultExtractor.js in tw is unable to recognize / optimize (just a wild guess). Apart from that other CSS optimization tools have problems with the newer :where construct too, so I would propose to just go back to the old (legacy) behavior. This will generate a larger CSS when the full feature set is used, but will probably create far better (smaller) results in common use cases that only need a small subset. What looks like a good general optimization (using :where) just creates the opposite effect in reality.

The larger rendering with plain selectors will especially occur with massive use of the not-prose feature, but I doubt that there are many scenarios where this plays any significant role.

Update: checked with legacy mode and got the same effect. I saw that (unlike in the aspect ratio plugin) the matching API (matchComponents) is not used at all in this plugin.

[adamwathan]

Hey! This behavior is by design, unless I'm misunderstanding (which is possible!)

Since index.html does not contain blockquote it is expected that dist/output.css does not contain the CSS for that.

The reason we include those styles anyways is because one of the main use cases for this plugin is dealing with content that is stored in a database or coming in through an API call to a headless CMS. That content can't be scanned by Tailwind, so we can't know what elements/classes are and aren't used.

So the behavior of this plugin is to check if the parent class is present (like prose) and if so, keep all of the rules related to that class. If you don't use a certain parent class (like say you aren't using prose-stone), none of those rules will be present. But if you do use that class, every rule containing that class is preserved for the reasons mentioned above.

The reason we use :where isn't for optimization, it's to control specificity. By using :where, it becomes possible to override prose styles with utilities on child elements, but without it you can't because the specificity of the typography styles is higher than the specificity of the utilities.

Will leave this open for now to make sure I see your reply (I don't see comments on closed issues) just in case I'm missing something, but as long as things are working as I've described then they are working the way we intended.

If there's a bug that causes all of the prose-stone rules to be generated even when not using the prose-stone class though that's definitely a bug and something we'd fix 👍🏻

[istr]

Hey! This behavior is by design, unless I'm misunderstanding (which is possible!)

If this should be the case, I would need some other plugin that provides the same functionality (nice typography) along with one of the major features of tailwind: massively optimized CSS.

The use case I have in mind is usage in a https://gohugo.io/ theme. In this situation you always have all content at hand an can leverage the full power of the JIT in combination with PostCSS. See gohugoio/hugo#8343
If it is OK for you, I could come up with a proposal / PR that could do both, but I still consider it a bug, that optimization is not enabled by default. In the situations you outline, a "no-optimize" flag could be more in line with the expectation of unsuspecting Tailwind users who buy one of the main USPs, namely

Performance
It's tiny — never ship unused CSS again.

Tailwind automatically removes all unused CSS when building for production, which means your final CSS bundle is the smallest it could possibly be. In fact, most Tailwind projects ship less than 10kB of CSS to the client.

[adamwathan]

If you would like to remove those styles, I would recommend using PurgeCSS as part of your build where you can have more fine-grained control over this.

As I explained in my comment above, the current behavior is by design and no plans to make changes here, so going to close. Sorry if it isn't the behavior you would like — all of this stuff is MIT licensed of course though so you are welcome to take any of this code and adapt it to your needs however you like.

[istr]

As I explained in my comment above, the current behavior is by design and no plans to make changes here, so going to close.

Never mind. See https://www.npmjs.com/package/tailwindcss-semantic-typography / https://github.com/istr/tailwindcss-semantic-typography for a plugin with a different focus.

https://github.com/istr/tailwindcss-semantic-typography#why-another-typography-plug-in

[mrkaluzny]

@istr Using semantic tags is a great idea, but that should still be locked within a class. I have to remove typography plugin from my site as well as it triples the CSS size.

It used to work much better TBH 😩

[istr]

@istr Using semantic tags is a great idea, but that should still be locked within a class.

Maybe... I'd rather use the <main> tag as a signal to use typography inside. ymmv. Probably the change to the code to opt for another selector (e.g. a class) is trivial.

[mrkaluzny]

I ended up rewriting some basic styles for Typography plugin, cut down around 70% of the package. I like the main approach, but I mostly work with blocks of that use the same content styling, that's why the class name is preferable for me :)