Zest Css Laravel Package

Product Decisions This Supports

• Build vs. buy for CSS selector handling in PHP. If a roadmap item requires parsing, validating, normalizing, or re-serializing CSS selectors server-side, Zest is a credible "buy" (adopt) candidate versus writing a tokenizer/parser in-house — a deceptively deep problem once you account for escapes, namespaces, attribute operators, and pseudo-classes.
• Security gating for user-generated CSS. The clearest high-value use case: accepting styles from untrusted authors (themes, template editors, tenant-level white-labeling, CMS content) and needing to reject or constrain selectors before they hit a renderer. Zest's provenance — extracted from MediaWiki's TemplateStyles, which runs on Wikipedia-scale user-authored CSS — makes the "sanitize untrusted selectors" feature a low-risk capability to commit to.
• Scoping and namespacing features. Products that let customers customize a widget without bleeding styles into the rest of the page need selector rewriting (prefixing, restricting to a subtree). A parser you control is a prerequisite; Zest enables that feature without a full CSS engine.
• Tooling and developer-experience bets. Linters, migration codemods, design-system audits, or "find all selectors targeting this component" features all reduce to selector parsing. This is an enabler for internal tooling rather than an end-user feature, so treat it as infrastructure spend, not product differentiation.
• Roadmap risk assessment. Because the package is small, MIT-licensed, and dependency-light, adopting it does not meaningfully constrain future architecture. The decision is reversible — a parser sits behind a thin internal interface, so swap cost stays low. That lowers the bar for saying yes.
• Explicit non-decision: it does not justify a "we now support arbitrary CSS" roadmap item on its own. Parsing selectors is maybe 10% of a CSS-safety story; property/value validation, @-rule handling, and URL/expression() filtering are separate workstreams.

When to Consider This Package

Adopt when most of these are true:

• You need selector-level parsing or validation in PHP, not full stylesheet parsing.
• The input is untrusted or semi-trusted, and you want an allowlist-based approach to which selectors are permitted.
• You want to round-trip or rewrite selectors — prefix them, strip them, diff them — rather than merely match them against a document.
• You are already in, or comfortable with, the MediaWiki/Gerrit ecosystem and its contribution and release conventions.
• You value a tiny dependency surface over ecosystem breadth; supply-chain review will be short.
• You can pin a version and accept that upstream velocity is driven by Wikimedia's needs, not yours.

Look elsewhere when:

• You need selector matching against a DOM as the primary capability. symfony/css-selector with DomCrawler, or a dedicated matcher, is the better-supported path; matching and parsing are different jobs.
• You need a complete CSS parser — at-rules, declarations, custom properties, source maps. Reach for a full CSS parser instead and treat selector parsing as one stage.
• Your org requires high community adoption as a procurement signal. Four stars and zero recorded dependents will fail a naive health check, even though the package underpins a top-10 website. Expect to argue this one explicitly.
• You need guaranteed responsiveness to external bug reports or feature requests. The GitHub repo is a mirror; real contribution flows through Gerrit and Wikimedia's developer-access process. If your team cannot or will not engage there, you are a spectator on the roadmap.
• You require PSR-standard interfaces or framework integration out of the box — there is nothing to bind into Laravel's service container here; you will write the wrapper yourself.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a feature that requires us to accept CSS from people outside the company and render it safely. Doing that without a parser means either blocking the feature or hand-rolling a security-sensitive component. This library is a small, MIT-licensed selector parser that was built inside MediaWiki and is exercised by Wikipedia's TemplateStyles system, where untrusted user CSS is a core, long-running production concern. It is a narrow dependency with no framework lock-in, so the downside is capped and the exit cost is a thin adapter. The tradeoff is community visibility: it is deliberately low-profile outside Wikimedia, so we should not expect third-party tutorials, Stack Overflow answers, or fast upstream turnaround on our requests.

To engineering (short): It parses CSS selectors and gives you a structured representation you can validate, rewrite, and serialize — not a DOM matcher, not a full CSS parser. Wrap it in an internal SelectorValidator interface on day one: one adapter class, one test suite seeded with hostile selectors (deeply nested :not(), escapes, comments, namespace prefixes, @-rule lookalikes), and a pinned version. Budget for reading the source rather than the docs; the API is small enough that this is an afternoon, not a sprint. Flag the Gerrit contribution path in the tech radar so nobody files a GitHub issue expecting a reply.