Php Css Parser Laravel Package

Product Decisions This Supports

• Build vs buy for server-side CSS transformation. This package is the "buy" answer when the requirement is "read CSS, change it, write CSS back." Composer one-liner, MIT, no service to run. Typical scopes: prepending a tenant/brand ID to every selector (style scoping without iframes), stripping legacy rules (font-*, cursor, IE filter), halving/normalizing absolute sizes, rewriting theme colors, re-rendering pretty or compact.
• Multi-tenant theme and embed isolation. If the product promise is "your CSS, contained," selector rewriting gives you cheap containment for email templates, CMS themes, and embedded widgets. Decide explicitly against Shadow DOM/iframes: choose those when you also need JS and DOM isolation; choose this when the constraint is one stylesheet, many tenants.
• Roadmap sequencing for styling features. Because manipulation is AST-level and deterministic, v1 can be a single narrow transform ("strip vendor prefixes," "remove unsafe properties") and each later feature is a new rule-set traversal, not new infrastructure. This is a low-regret bet that keeps styling work inside the PHP backend instead of adding a Node build step.
• Design-system hygiene as internal tooling. Enumerating all rule sets, rules, and values makes token audits (hard-coded colors/sizes vs variables, absolute-unit drift, orphaned selectors) a report generator rather than a manual review — a credible "reduce design debt" initiative with measurable output.
• Explicitly not supported by this dependency: anything cascade-dependent. Selector carries a specificity slot that is not populated, and there is no @media evaluation or cascade resolution — so critical-CSS extraction, unused-CSS elimination, and "computed style" features must not be scoped onto this package in planning.

When to Consider This Package

Adopt when:

• The requirement can be phrased as "for every selector / rule / value, do X." If so, this is likely the cheapest correct path in PHP.
• Input is trusted or semi-controlled (generated CSS, tenant themes, uploaded overrides) and you can afford a separate validation/sanitization pass.
• You want zero runtime footprint and a single dependency with changelog, CI, coverage, and recent releases.
• You're transforming moderately sized files in a request or job, not streaming megabytes per request.

Look elsewhere when:

• You need selector matching, cascade, or computed styles → headless browser, or a PostCSS/Lightning CSS toolchain.
• You only need byte reduction → use a dedicated minifier; this parses and re-renders, it does not optimize.
• You must support modern syntax (@layer, @container, nesting, custom-property-aware transforms) — validate coverage against your real corpus first, not against the README examples.
• Parsing cost is on a hot path: the README itself offers disabling mb_* functions as a speed lever while warning about correctness, which tells you parsing throughput is a real constraint.

Adoption gate before committing:

1. Run your top ~100 real stylesheets through default and strict settings; count exceptions.
2. Diff render() against input. Output is normalized (e.g., #rrggbb becomes rgb(...), URLs get quoted) — round-trip is not byte-identical. Get stakeholder sign-off on this early; it is the most common surprise.
3. Decide the sanitization story. This is a parser, not a sanitizer: @import, url(javascript:), and legacy expression() are structural, not policy. If the feature is "customers upload CSS," budget the whitelist layer as its own work item.
4. Confirm maintenance risk: small maintainer team, version pinning, and a documented exit path (keep transforms behind a thin interface so the parser is swappable).

How to Pitch It (Stakeholders)

To executives: A small, free, MIT-licensed PHP library that lets our backend treat CSS as structured data instead of text. It unlocks styling features we currently can't ship — per-tenant style scoping, brand token rewrites, legacy rule cleanup, and per-channel CSS output — with no new infrastructure, no Node service, and no parser to maintain ourselves. Cost is measured in days of engineering plus one Composer dependency; the risk is bounded because every transform stays behind our own interface and can be swapped out.

To engineering: Treat it as the AST layer, never the policy layer. The seam is Parser → Document → CSSList / RuleSet / Rule / Value → render(OutputFormat); whitelisting, sanitization, and any cascade logic stay in our code, because the package deliberately stops at structure. Expect normalized output rather than byte-identical round-trips, pin the version, run strict parsing in tests to surface malformed input, and keep each transform a pure, separately tested function so a future migration to a PostCSS-based pipeline is a swap, not a rewrite.