Screen-Utilities – problem with other postcss plugins

[HellPat]

Hey there,

I love my utilities to be marked as !important because i've seen some people overwriting utilities (which is more than bad). If specitifity of e.g. a bem-item is higher the utility gets overridden.

Example:

.mx-auto { … }

/* this is not good, but happens from time to time. If i mark my utilities as important, this will not work and the user MUST remove the class mx-auto from the html */
.card > .card__image {
    margin-left: 10px;
} 

<div class="card">
    <div class="card__image mx-auto">
        <img … />
    </div>
</div>

I've written a tiny postcss plugin for marking utilities important.
https://www.npmjs.com/package/postcss-important-startstop

Problem

The plugin is based on comments in the css.
It's not the only postcss plugin which does so.

If i try to use it with tailwindcss, the @tailwind utilities can be marked important by using

/* @important(start) */
@tailwind utilities;
/* @important(stop) */

This works like a charm.
The problem is, that the custom utilities are added to the end of the css-file magically.

So this happens:

/* @important(start) */
@tailwind utilities;
/* @important(stop) */

/**
 * Here you would add any custom utilities you need that don't come out of the box with Tailwind.
 */
.bg-hero-image {
    background-image: url('/some/image/file.png');
}

results in this:

I have no chance to modify the "custom utilities" with my comment-based plugin.

Is it somehow possible to "remove the magic" and render the custom utilities with something like that?

@tailwind custom-utilities;

WDYT?

[adamwathan]

I think this is a reasonable idea.

What if we did something like this:

• Add an optional marker like @tailwind screen-utilities and in the processing phase where we generate those utilities, we first looked for that marker and if it was present, output the screen specific utilities there

• If that marker is not present anywhere in the file, default to outputting the utilities at the end of the CSS file

This way you could have finer control over it if needed, and the 95% of people who want the default behavior can just pretend the option doesn't exist.

Would that solve your issue?

[HellPat]

Yeah, this would definitly solve my issue and makes perfect sense to me.

[HellPat]

Haha, i just removed my stop tag for now.
Feels nasty and it is.

/**
 * Here you would add any custom utilities you need that don't come out of the box with Tailwind.
 */
.bg-hero-image {
    background-image: url('/some/image/file.png');
}

/* @important(start) */
@tailwind utilities;

Does temporarily solve the problem.

@adamwathan If you have a hint for me where I could start to adjust this (just a quickstart) I can
try to give it a shot.

[adamwathan]

@psren This is the line that dumps it at the end of the stylesheet:

https://github.com/tailwindcss/tailwindcss/blob/master/src/lib/substituteResponsiveAtRules.js#L32

So instead we'd just want to look for some marker at-rule to replace instead if it was present.

The tricky thing is coming up with a name I don't hate for the at-rule 😄 but feel free to start a PR using @tailwind screen-utilities and we can easily change it if I can come up with something I actually like.

[HellPat]

@adamwathan i like the name, because is is equal to the helper https://tailwindcss.com/docs/functions-and-directives/#screen

[HellPat]

Aaaaand one more question.
We have two variants to test now.

With screen-utils rendered by @tailwind screen-utilities and with implicitly rendered screen-utils.

We have to keep implicit rendering (of cause) to provide BC and the "ease of use".
Later we will maybe have a third variant with the planned (or at least mentioned) modularization.

So my question before i start to implement this is:
How'd you go with tests?

I would copy the tailwind-input.css to another file for the different test and expect exactly the same output.

Every possible change to this block https://github.com/tailwindcss/tailwindcss/blob/master/__tests__/fixtures/tailwind-input.css#L5-L9 must be done twice from then on.

BUUUT: I don't think thats a problem because this part most likely won't change in any minor version.

@adamwathan WDYT?