Feature request: Type-safe component CSS with implicit "$styles" in templates #71879

Which @angular/* package(s) are relevant/related to the feature request?

compiler, compiler-cli

Description

Angular provides style encapsulation but doesn't type-check CSS class references in templates. Renaming or removing a class from a component stylesheet can silently break its usage.

Validating existing class attributes or [class.name] bindings isn't viable because classes may come from global stylesheets, Tailwind, or third-party libraries.

Proposed solution

Introduce an implicit, compiler-provided $styles object in Angular templates, exposing class names declared in the component's own stylesheets (styleUrl, styleUrls, or inline styles).

Example:

/* button.component.css */
.primary { background: blue; }
.loading { opacity: 0.5; }

<!-- Existing syntax remains unrestricted -->
<button class="flex items-center" [class.loading]="loading()">
  Save
</button>

<!-- Explicitly type-checked local CSS references -->
<button [class]="$styles.primary">Save</button>
<button [class]="$styles.missing">Save</button>
<!-- Error: 'missing' does not exist -->

This could enable compile-time diagnostics, autocomplete, go-to-definition, and rename refactoring across templates and stylesheets.

Alternatives considered

TypeScript 7.1 content mappers could potentially provide stylesheet-derived types to Angular's existing template type-checking infrastructure.

$styles would be a compile-time abstraction resolving to ordinary class names, requiring no runtime object, CSS Modules imports, or changes to Angular's existing view encapsulation.

Angular would control the content mapper and language service highlighting.
Can leverage css modules under the hood. The limitation is not having access to the $styles object in the ts but existing @let synax should be good enough for dynamic class composition directly in the template.

Edge case: <component [prop]="$styles" (emit)="handler($styles)/> - can leak into the ts. Which basicaly forces a css module implementation if to be supported. Alternative is compile error.

css modules had been rejected before when used "as is", but this is a controlled angular api that would leverage content mappers so it deserves a discussion.