Let dwind express keyframes, pseudo-elements and arbitrary declarations

[JedimEmO]

Stacked on #21. Base is modernize-example-app — retarget to main once #21 lands.

Auditing every raw CSS string in the example site produced one finding:

raw CSS was reached for because of the selector or the at-rule, never because of a property.

Three additions close that gap. Everything is additive — dwind 0.7.0, dwind-macros 0.4.0, dwind-base 0.1.1 and dwui 0.9.0 are published, and no currently-successful dwclass! input changes meaning except the one case called out below.

dwkeyframes!

A utility class is a single declaration block, so a @keyframes could never be one — the CSS binding pipeline has no at-rule support at all (ParsedSelector is only SingleClass | Complex). Every crate worked around it with a hand-written &str blob pushed through stylesheet_raw: three of them, with no deduplication, no collision detection, and every keyframe paying its cost whether the page used it or not.

dwkeyframes! {
    #[animation("900ms cubic-bezier(0.16, 1, 0.3, 1) both")]
    fade_up {
        "from" => "opacity: 0; transform: translateY(14px);",
        "to"   => "opacity: 1; transform: translateY(0);",
    }
}

html!("div", { .dwclass!("animate-fade-up") })

This is Tailwind's model — declare the keyframe body and the utility that uses it together, emit both — adapted to dwind's "the class name is a Rust constant" invariant.

• Emits the at-rule and a compile-time-checked animate-* utility, so a typo is still a build error.
• Injected the first time the class — or the handle's Display — is used, and never twice. format!("{FADE_UP_KEYFRAMES} 600ms {delay}ms") registers as a side effect, which is what runtime-composed shorthands need.
• Namespaced by the consuming crate via env!("CARGO_CRATE_NAME"), so two crates declaring fade_up don't collide. #![prefix = "..."] to override, #[name = "..."] to pin an exact name. One name registered with two different bodies now panics in debug instead of silently winning.
• dwind's spin/ping/pulse/bounce and dwui's five dwui-* keyframes migrated onto it, names pinned and injection timing unchanged.

Every CSS fragment is a string literal deliberately: Rust's lexer splits 0%, --sx and .35 in ways that don't round-trip through TokenStream::to_string().

Arbitrary declarations — [property:value]

.dwclass!("[mask-composite:exclude] [--sx:50%] hover:[color:red]")

Unambiguous against the variant syntax because a variant's ] is always followed by :. No new sigil needed.

This is provably non-breaking, and it fixes a footgun: a bracket group without a trailing colon previously failed every parser, so many0 stopped and parse_class_string discarded the remainder — dwclass!("foo [a:b] bar") yielded one class, not three, with no diagnostic. That silent truncation is fixed, and a bracket group with no colon is now a compile error that says so.

Underscores in the value become spaces ([transition:opacity_650ms_ease]); the property side is left alone so custom properties keep theirs.

Pseudo-elements that render

[&::before]: variants already parsed — but a ::before with no content never generates a box, so the utility did nothing on its own. dwind now emits content: "" when a variant's last compound targets ::before/::after.

DomBuilder::raw appends rather than replaces (dominator/src/bindings.rs:160), so a user's own content-[…] later in the same class still wins. That's why this needs none of Tailwind's --tw-content indirection — Tailwind needs it only because its variants are static stylesheet rules with fixed source order.

Shorthands added: before:, after:, placeholder:, marker:, selection:, backdrop:, first-letter:, first-line:.

Bug fix: render_generator ignored class.variant entirely, so [&::before]:bg-color-[red] compiled and silently styled the element itself.

The one behaviour change: before:/after: previously rendered as the legacy single-colon :before. They now render ::before — equivalent in every engine — and gain generated content. before: was useless without content, so this should be safe, but it's the only currently-working input whose meaning changes.

New utilities

delay-0…delay-1000, underline/overline/line-through/no-underline, tracking-*, whitespace-*, list-none/list-disc/list-decimal, content-empty/content-none, font-inherit, isolate, mix-blend-*, will-change-*, outline-none.

Deliberately not added: a mask-* family. Every real mask in the example is a bespoke gradient or a mask-composite: xor pair — a scale would cover none of them, and the escape hatch covers all of them.

Testing

dwind-macros had zero tests. It now has 29 — the pre-existing shapes are pinned first, in their own commit-order, so the parser change can be shown not to move them (verify_child_selector_parser is the disambiguation guard). Codegen had no tests at all and now does.

New browser suite crates/dwui/tests/styling.rs — 9 tests covering what token assertions can't: an unused keyframe is absent from document.styleSheets, two instantiations produce exactly one CSSKeyframesRule, getComputedStyle(el, "::before").content is not none, and arbitrary declarations (including --sx) reach the computed style.

cargo test -p dwind-macros -p dwind -p dwind-base   # 33 pass
wasm-pack test --headless --firefox crates/dwui      # 32 + 9 pass

The example site rebuilds and renders identically — 19 routes clean, no horizontal overflow at 1440px/390px, ⌘K palette and pointer-spotlight tracking intact.

Versions

dwind-base 0.1.2, dwind-macros 0.5.0, dwind 0.8.0, dwui 0.9.1, with path-dep pins bumped in the same commit so cargo publish can't resolve a stale dwind-macros against the new dwind.

A follow-up PR migrates examples/webpage onto all of this and deletes most of styles.rs.

🤖 Generated with Claude Code