Phoenix LiveView 1.2: CSS Colocation Ships, but Browser Support Leaves Scoping Optional

Phoenix LiveView 1.2 dropped on June 10th, and the headline feature tells a story about where web development tooling is heading, even if the ecosystem isn't quite ready to follow. The release introduces colocated CSS, allowing developers to embed styles directly in HEEx templates alongside the JavaScript colocated hooks that arrived in version 1.1.

The concept isn't new. Vue single-file components have bundled styles with templates for years. Svelte scoped its CSS from day one. What makes LiveView's approach distinctive is the mechanism it leverages: the CSS @scope rule, a relatively recent addition to the specification that provides native browser support for component-level style isolation.

Here's how it works in practice. When you write a component in LiveView 1.2, you can include a <style> tag with a :type attribute pointing to a colocated CSS module. At compile time, LiveView extracts this content into a special build directory, where your existing bundler (Tailwind, Esbuild, or whatever you prefer) processes it as part of your normal CSS pipeline. The styles themselves look like regular CSS, but the rendered HTML gets annotated with special attributes. A phx-r attribute marks root elements of each template, and unique phx-css-* attributes identify component boundaries. This allows you to write @scope rules that target only elements within a specific component's DOM tree.

The technical depth here is worth appreciating. Making colocated CSS work required a fundamental change to how HEEx templates compile. The team split compilation into separate tokenization and parsing steps, a refactor that not only enabled macro components like colocated CSS and JS but also consolidated code that was previously duplicated between template compilation and formatting logic. They published a separate technical deep dive explaining the internals, which is required reading for anyone curious about the compiler internals.

Here's where the story gets interesting. LiveView 1.2 ships the infrastructure for scoped CSS but doesn't enable scoping by default. The reason is pragmatic: the @scope rule lacks broad browser support as of June 2026. The team provides a @behaviour you can implement to handle custom scoping strategies, and they've documented an early-adopter implementation using @scope, but the default is no scoping at all.

This decision reveals a tension that runs through modern web development. Frameworks want to adopt cutting-edge platform features, but they also need to ship stable tools that work across browsers. LiveView's solution is characteristic of the Elixir ecosystem's approach: build the infrastructure, provide escape hatches, but let developers opt into bleeding-edge features rather than forcing them. It's a pattern that respects developer autonomy while still pushing the ecosystem forward.

The release also bundles several smaller improvements that address practical pain points. A new Phoenix.LiveView.HTMLFormatter.TagFormatter behaviour lets you format <script> and <style> tags in HEEx with external tools like Prettier. Phoenix.LiveView.JS structs now auto-encode when sent via push_event if you're using Jason or the built-in JSON module, eliminating a common source of friction. Debug annotations in HEEx can now be configured per module rather than globally, and test warnings are categorized separately for easier filtering.

What does this release signal about the broader Elixir and Phoenix ecosystem? The colocated styles approach aligns with a pattern where server-rendered frameworks increasingly borrow ideas from the SPA world without abandoning their core philosophy. LiveView still runs on the server, still updates the DOM over WebSocket connections, still avoids the complexity of client-side state management. But it's integrating frontend conventions like colocated assets because they genuinely improve developer experience regardless of where your code executes.

The community reaction on the Phoenix blog and Elixir forums will likely split into camps. Pragmatists will appreciate the opt-in nature of scoping and the compiler improvements. Early adopters will experiment with @scope immediately, accepting that browser support is incomplete. Skeptics might question whether colocated CSS in a server-rendered framework addresses a real problem, given that LiveView's component model already provides implicit style boundaries through its rendering lifecycle.

The counter-perspective is worth considering. LiveView components don't share a client-side runtime the way React or Vue components do. Each component is rendered server-side, and DOM updates are surgical. Style conflicts between components are less of a practical problem when you're not dealing with a client-side component tree that might render unpredictable combinations of markup. The colocated CSS feature solves a problem that exists more in theory than in practice for many LiveView applications.

That said, as LiveView applications grow in complexity and teams scale, having explicit style boundaries becomes more valuable. The compiler infrastructure LiveView 1.2 introduces positions the framework to enable scoping by default once browser support catches up, which is a reasonable bet given the trajectory of CSS specifications.

LiveView 1.2 is available now. Update your mix.exs to {:phoenix_live_view, "~> 1.2.0"} and re-fetch dependencies. The full changelog documents all changes, and the documentation includes the colocated CSS implementation details.