Use the Shadow DOM for components, isolated styles and templates

[eeegs]

Is your feature request related to a problem? Please describe.

This is not a solution to a problem, but a request to change the architecture of the generated razor DOM elements. At a high level there seems to be a very high degree of correlation in the architectural concepts being provided by Blazor and the Shadow DOM, so why fight it.

Describe the solution you'd like

Have the Razor components actually generate templates, uses slots and define themselves as shadow DOM elements using javascript classes extending HTMLElement. This would then allow css encapsulation too. Of cause you could start out by defining a class BlazorComponent: HTMLElement.

Additional context

Nope - I suspect you get the idea.
Might also help the work on allowing interaction with other javascript frameworks. #32352.

[javiercn]

@eeegs thanks for contacting us.

We might allow this in the future, however its not something we would do by default. Templates are not useful for Blazor, since it already uses its own templating system. Shadow DOM and slotted content are more interesting, and might be available in the future.

That said, we wouldn't change the way blazor normally renders for that. It is a huge breaking change and it adds overhead to the rendering process. In addition to that, it doesn't work very well with things like prerendering (there is declarative shadow dom in chrome and edge, but I believe its lacking in safari and firefox).

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[eeegs]

Thanks for the feedback and the effort to at least consider this.

Regards,

Scott

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[RChrisCoble]

@danroth27: Hello Dan. We're hitting this problem with our large Blazor app at present as we need the ability to individually style Blazor components with isolated CSS. The part of the original feature description which is impacting us is:

This would then allow css encapsulation too.

If you could consider this support during .NET 8 planning we would appreciate it, otherwise I don't see any workarounds.

[danroth27]

@RChrisCoble Thanks for sharing this feedback! Can you tell us a bit more about why the existing Blazor component CSS isolation support is insufficient for your needs?

[RChrisCoble]

Hello @danroth27,

Quick background refresher on our software and the relevant UC's we're looking to support with Blazor.

Our software has a "Design Time" build environment and a "Runtime" environment which is presenting what was built in design time. C#/WPF is the technology used in both stacks, and we're presenting moving the Runtime portion of the environment to Blazor WASM which will be consumed from Azure as a SaaS offer. After this is completed, we'll move to porting the design time tooling to Blazor WASM as well. This is a multi-year strategy as we transition the entire business to subscription.

Our design time tooling allows the user to compose an HMI (Human Machine Interface) by assembling individual components together on a screen and binding them together with business logic. A component in this case was historically just a basic WPF control that provided some widget of functionality. Once the user placed a WPF component on the screen, the exposed properties of that WPF control can be configured, bound to live values, etc. Some of those exposed properties are common things like Background Color, Foreground Color, Font, Font Color, etc., standard exposed properties one would expect to see on a UI component. The user can configure whatever colors/fonts/etc. on these individual components and in Runtime they would present themselves as configured.

We're porting this Runtime framework to Blazor, along with the WPF components we own. Our Design time tooling allows the import and configuration of three types of controls:

1. Controls we internally compile ourselves and deliver with our design time tooling. "Out of the box content" so to speak.
2. Controls customers build for our environment that often utilize our Runtime SDK.
3. 3rd party controls. These could be any WPF control. Telerik, Infragistics, built yourself without using our SDK, etc.

We're trying to support the same styling behavior with Blazor with the assumption that all these controls specified in 1-3 above become Blazor Controls instead of WPF controls. Essentially we're moving from XAML styling to CSS styling in this transition.

In our workflow we allowing importing any of these types of controls, and the user can drag/drop them then configure using our tooling. In Runtime, we're setting these styles dynamically as opposed to knowing all the styles at code compile time.

Each control on the screen may need a unique style configured specifically to that control, even if the same control is used multiple times on the screen. For UC 1 above, we can use a unique CSS class style for that control instance. For 2, we can recommended our customers follow the best practice for their Blazor controls and support a unique CSS class style as well. For 3 though, we don't have a good solution as a configured style would apply to all usages of that control as it's coming from the master CSS configuration.

One possible solution to this is having Blazor support the browser concept of a Shadow DOM, which functionally isolates the CSS styles leaking into the master CSS list, allowing the styles to stay local to the control in the Shadow DOM. Another solution is an iFrame wrapper, but you can't host Blazor in an internal iFrame. The iFrame has other issues as well.

Does this UC make sense?

Regards.

[danroth27]

@RChrisCoble Thanks for the explanation! It sounds like you basically need a way to scope CSS styles to a specific instance of a component, not just a component type, correct? If you had some way to tack IDs on to component instances would that work too for your scenarios?

[RChrisCoble]

@danroth27 I believe that would work. Just understand we're doing this all dynamically. The 3rd party control would be instantiated, we'd need to apply an ID onto that instance, (also dynamic), then inject the CSS attributes of that component in a way that it only applies to the instance.

[RChrisCoble]

@danroth27: One of the key point here in "dynamic" is the ability to set the value of the css property dynamically in our runtime.

for Instance:

{
    color: @Foreground;
    font-size: @FontSize;
    font-family: @FontFamily;
}

@Foreground, @FontSize, @FontFamily are Blazor component's properties and can be changed at runtime. When a new value comes in, we refresh the Blazor component's UI.

[RChrisCoble]

@danroth27 I keep using the "dynamic" word here as another UC we need to support is dynamically re-theming the HMI on demand. This UC looks like "Employees on a day shift might use the light theme and Employees on the night shift switch to the dark theme." of the HMI...Or one of the more interesting UC's that always stuck in my head was our software being used on submarines in a European country's navy fleet, and switching to "battle stations" changed the UX of the HMI to ensure everyone understood.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[tma-lawo]

Essential for Blazor HTML custom elements.