You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to use daisyUI to style some HTML which I do not have the ability to edit directly. Accordingly, I'm building CSS selectors to match the existing structure of the HTML and adding daisyUI styles with @apply.
I'm encountering problems when attempting to @applythe .input class, but I suspect the issue is more general.
Given the input CSS:
@tailwind base;
@tailwind components;
@tailwind utilities;
/* Any ".myfield" element should be treated as ".input"
Place this outside a @layer to ensure it's always built. */
.myfield {
@apply input;
}
Note, the .myfield rule is exactly what's desired, but the additional rules (like .myfield-group > .input and .myfield-disabled, .myfield[disabled]) should not be created, as these class names do not actually exist anywhere.
Things like the daisyUI source rule .input { &-disabled, &[disabled] } are being emitted as .myfield-disabled, .myfield[disabled]. This definitely seems like a bug, but it makes sense that the @apply rule might be substituting the .input rule for .myfieldbefore PostCSS Nested transforms the &-disabled sub-rule.
My example uses a rule for .myfield, but my actual use case also has rules for selectors like input[type='text'], which outputs the rule input[type='text']-group, which is not even valid CSS. I used the .myfield example because it's easier to understand the substitutions taking place.
I've verified that this failure occurs both with the Tailwind CLI build process and with a PostCSS + Parcel build process (which is what I'm actually using). For rules that generate invalid CSS, the Tailwind CLI completes successfully, while the PostCSS + Parcel is not even able to build. For the example here, the builds both complete, since they're still valid CSS.
I'm trying to use daisyUI to style some HTML which I do not have the ability to edit directly. Accordingly, I'm building CSS selectors to match the existing structure of the HTML and adding daisyUI styles with
@apply
.I'm encountering problems when attempting to
@apply
the.input
class, but I suspect the issue is more general.Given the input CSS:
The
tailwindcss
CLI emits output CSS containing:Note, the
.myfield
rule is exactly what's desired, but the additional rules (like.myfield-group > .input
and.myfield-disabled, .myfield[disabled]
) should not be created, as these class names do not actually exist anywhere.There might actually be two different bugs here:
.input-group { > .input }
are being emitted as.myfield-group > .input
. I cannot figure out why this is happening..input { &-disabled, &[disabled] }
are being emitted as.myfield-disabled, .myfield[disabled]
. This definitely seems like a bug, but it makes sense that the@apply
rule might be substituting the.input
rule for.myfield
before PostCSS Nested transforms the&-disabled
sub-rule.My example uses a rule for
.myfield
, but my actual use case also has rules for selectors likeinput[type='text']
, which outputs the ruleinput[type='text']-group
, which is not even valid CSS. I used the.myfield
example because it's easier to understand the substitutions taking place.I've verified that this failure occurs both with the Tailwind CLI build process and with a PostCSS + Parcel build process (which is what I'm actually using). For rules that generate invalid CSS, the Tailwind CLI completes successfully, while the PostCSS + Parcel is not even able to build. For the example here, the builds both complete, since they're still valid CSS.
Here's a repo to reproduce this: https://github.com/brianhelba/daisy-apply-bug
The text was updated successfully, but these errors were encountered: