Component scoping

I was playing around with custom components and I noticed that I can set CSS properties for other page elements/components. These changes are not reflected within the Elements preview itself, but are visible in the Safari/browser preview.

While this behaviour can be handy at times (say if you want to set the page background colour when there is no way to currently do that in Elements), is there any plan to scope custom components to avoid any unexpected conflicts?

https://files.bryanrieger.com/component-leak.elements.zip

Hey Bryan!

Iā€™m not sure how familiar you (or anyone else reading this) are with Tailwind, so Iā€™ll provide a detailed explanation below. Some parts may not seem related to scoped CSS, but I thought it important to give everyone a better understanding and some context.

Excuse the long winded reply if you are aware of some/most of this information :slight_smile:


I reviewed your project file and understand why youā€™re considering scoped CSS given how the CSS is written. However, I recommend using Tailwind for styling your components.

Scoped CSS
I know scoped CSS is great for ensuring that styles are applied only to a specific component, preventing style leakage into other components/pages. However, managing scoped CSS can become a bit cumbersome as a project grows. Elements would have to ensure that each componentā€™s styles are correctly isolated, which will inevitably lead to bloated style sheets with many duplicated CSS declarations.

Utility-First Approach
Tailwind offers a utility-first approach to styling. This means you apply small, reusable utility classes directly to your HTML elements. Instead of writing a lot of custom CSS, you can compose styles using these predefined classes.

Direct Application in Templates
Instead of writing CSS in the Styles area, you can use Tailwind utilities directly in your template. This means adding classes like bg-blue-500, text-center, or mt-4 right on your HTML elements. This way, you remove the need for scoped CSS because each componentā€™s styles are already self-contained.

Preventing Style Leakage
Because Tailwind styles are applied directly to DOM elements using utility classes we prevent style leakage between components. Each componentā€™s styles stay within its HTML structure meaning they donā€™t affect other components or pages on your site.

A Standardized Approach
We use Tailwind for all our components, and I highly recommend everyone using and building for Elements does the same.

If everyone is using Tailwind we can ensure consistency across all components, making it easier for end users to build sites that are consistent and easy to update.

It also makes collaboration smoother, as everyone follows the same styling method.

Customization with Properties
For customization, you can use properties (like you have with color and width in your project file) to generate Tailwind classes ready to use within your templates. This way, you keep flexibility while sticking to the utility-first approach.

Optimized CSS Generation
To sum it up, the custom CSS in your Styles area could be replaced with Tailwind classes in your template. This change removes the need for scoped CSS and keeps all styling within Tailwind. Elements can then generate only the CSS your page uses, since it builds Tailwind locally and includes just the necessary utilities. This results in a smaller, more efficient CSS file(s).


I really want to scope my CSS

If youā€™ve read all that and are saying ā€œgreat, thanks! But I still need scoped CSS!ā€ then there is still hope :smiley:

You could manually ā€œscopeā€ your CSS classes by using the componentā€™s ID in your Template and Styles. I know thatā€™s not strictly ā€œscoped CSSā€, but it will encapsulate the CSS to each individual component instance.

In your Styles

.{{id}} {
    ...
}

.{{id}} .child-element {
    ...
}

In your Template

<div class="{{id}} ...">...</div>

Hope that explains things! Let me know if you have more questions :slight_smile:

1 Like

Thanks @bon that makes perfect sense. Can I ask then that in the node tree you create a consistent base node that represents the page (probably called ā€˜pageā€™) so that thereā€™s an easy way to add padding, margins, background colours, etc to the page itself?

We have already discussed internally about how to add styling for ā€œpageā€ or ā€œsiteā€ level things (like the body background colour) but we havenā€™t got to that yet!

3 Likes