css-expect should make it practical to write small, trustworthy tests for native CSS custom functions, and eventually native CSS mixins, by asking a real browser for the computed result instead of emulating CSS in JavaScript.
- CSS library authors and design-system maintainers experimenting with native CSS custom functions.
- Frontend engineers who want unit-test-style feedback for browser-evaluated CSS values.
- Standards-aware tool builders who need diagnostics around emerging CSS features without introducing a parser, compiler, transpiler, or polyfill.
- Provide a compact ESM API that can be used from Vitest, Vite+, Playwright-aware test suites, and other async JavaScript or TypeScript runners.
- Evaluate CSS custom functions through real CSS properties and
getComputedStyle(), so the selected browser engine remains the source of truth. - Support inline CSS and ordered CSS files so tests can cover both isolated snippets and reusable CSS modules.
- Return clear expectation results and failure diagnostics, including generated CSS, browser details, feature support, expected values, and actual computed values.
- Expose focused feature-support helpers for CSS functions, mixins,
@apply, and available CSSOM metadata.
- A user can install the package, load CSS, and assert a custom function result in a few lines of test code.
- Tests fail because the browser computed a different value, not because css-expect guessed or reimplemented CSS semantics incorrectly.
- Unsupported browser features produce actionable skip or failure diagnostics, depending on the configured policy.
- The public API stays small, documented, typed, and stable enough for early adopters to use in real test suites.
- Package checks, type checks, browser-backed tests, examples, and publishing checks pass before release.
- Not a CSS parser, compiler, transpiler, optimizer, polyfill, or way to make unsupported CSS features work in browsers that do not implement them.
- Focused on testing CSS logic: custom function results now, and mixin return values when the platform supports them.
- Not a replacement for Vitest, Playwright Test, or another test runner, and not a home for broad runner or framework-specific APIs.
- Not a broad DOM assertion library, complete CSS feature-detection framework, or full suite of CSS assertions and expectations.
- Avoids normalizing computed styles in ways that hide meaningful browser differences.
- Defers large framework integrations until the core browser-backed expectation model is proven useful.
- The browser is authoritative. Prefer computed style and native CSSOM evidence over local interpretation.
- Keep assertions property-aware. CSS custom functions are evaluated in a property grammar, so expectations should require callers to name the property under test.
- Be explicit about experimental platform support. Chrome/Chromium is the currently validated target, while Firefox and WebKit options exist for future browser support.
- Keep diagnostics useful for debugging test failures and emerging CSS feature support.
- Keep the package install and publish path conservative: ESM output, generated types, ignored npm lifecycle scripts, pinned release checks, and trusted publishing.
- Prefer a small dependency surface. Playwright is the runtime browser automation dependency; new dependencies should earn their place.
- Validate the custom-function API against current Chromium support.
- Preserve good behavior when browser support is missing by supporting both fail-fast and skip policies.
- Keep examples and README usage aligned with the shipped API.
- Prepare the package for a safe first public release.