Statamic Latte Laravel Package

Product Decisions This Supports

• Build vs. buy on the rendering layer. The package is maturing in exactly the areas teams usually end up hand-rolling: safe output of rich-text/HTML field types, link-state markup, and content-conditionals. Each release that closes one of these gaps is a point in favor of "buy/adopt" over building a bespoke helper layer your team has to maintain.
• Security posture for user-generated content. "Smart escaping for fieldtypes with html output" is the highest-signal item here. If your roadmap includes rich-text editing, CMS-authored pages, or any field type that emits markup, this reduces the amount of manual {!! !!}-style escaping logic and the XSS review burden that comes with it. That's a risk-reduction line item, not just a feature.
• Accessibility and navigation-state roadmap work. The n:href attribute (current / external / download link marking) removes a recurring custom-helper task. If you have an accessibility conformance goal — or a design system that specifies distinct treatments for current-page, external, and download links — this converts a per-project chore into a configuration decision.
• Test strategy for content-heavy UI. iftext / n:iftext makes "is this text visible to the user?" an assertable, template-level concept. That supports a decision to lean on template-level tests rather than brittle end-to-end selectors for conditional content, which is usually cheaper to maintain and less flaky.
• Sprint-level roadmap placement. This is a minor, additive release with no deprecations or breaking changes. Cost of adoption is effectively zero beyond an upgrade-and-regression pass, so it can ride along with existing work rather than needing its own slot.
• Representative use cases to evaluate against: marketing/CMS-driven pages, transactional email templates, multi-tenant or white-label theming where markup varies per tenant, and any surface where non-engineers author content that renders into HTML.

When to Consider This Package

Adopt when:

• You render server-side templates in Laravel/PHP and expect content from field types, editors, or CMS entries to include HTML.
• You have (or plan) accessibility requirements around link semantics and current-page state — the n:href work is otherwise duplicated in every project.
• Your team writes template-level or snapshot tests and wants conditionals expressed in the template rather than in test-only branching.
• You're comfortable adopting a small attribute/tag DSL in templates; the n: prefix conventions are the package's idiom and are worth standardizing on deliberately.

Look elsewhere when:

• Your front end is SPA/JS-first and server rendering is a thin API layer — these features won't be exercised.
• You want zero template DSL and strict separation between markup and logic; the attribute/tag approach is the opposite trade-off.
• You need guarantees this release doesn't speak to: formal i18n/RTL coverage, a published accessibility conformance statement, or a long-term support commitment. Nothing in these notes addresses those, so treat them as open questions rather than solved.
• You're on a version older than the current minor line with heavy local customization of escaping or link helpers — you may have already built around the gaps this release fills, and migrating is a net-neutral exercise.

How to Pitch It (Stakeholders)

For executives: This is a routine minor release with no breaking changes and no migration effort. Its value is risk reduction and compliance-adjacent polish: smarter escaping lowers the chance of injected markup from content fields reaching users, and built-in link-state markup supports accessibility requirements we'd otherwise pay to build and maintain ourselves. Recommendation is to take it in the normal upgrade cadence — no dedicated budget or roadmap slot required.

For engineering: Additive only — one escaping improvement for HTML-emitting field types, an n:href attribute that tags current/external/download links, and an iftext tag plus n:iftext attribute for asserting visible content. All opt-in; no deprecations. Upgrade is low-risk, but do a regression pass on any templates that currently hand-escape field output, and confirm the new escaping behavior doesn't double-escape existing sanitized fields. Worth standardizing the n: conventions in the style guide if we adopt.