Scoping RFC

[matthewp]

This RFC introduces a new scopedStyleStrategy option to re-enable class based scoping, preventing bugs associated with CSS ordering that occur with the current where based strategy.

Links

• Fully rendered proposal
• Stage 2 proposal
• Stage 1 proposal

[tony-sull]

Any thoughts on how we might document the pros & cons of each strategy? I'm a little concerned with how tricky it might be to explain why the two options exist, when to pick one over the other, and what to do if both strategies don't work for a certain project structure

@layer definitely feels like a longer term solution here since the bundled CSS could stacked into the correct layer, though maybe there are still gotchas even then due to bundling :thinking:

For 3.0+, is the idea that we'd switch the default back to class or add a layer option as the default?

---

Can I Use stats for global support of all tracked browsers:

:where() 92.72% @layer 90.1%

I'm actually a little surprised the support @layer is nearly as high as the :where() function we depend on today 👀

[matthewp]

@tony-sull I'm not actually sure how to solve this problem using layers. We could wrap Astro component styles in a layer, but that wouldn't cause it to take priority. See for example: https://codepen.io/matthewp/pen/LYJvqLo?editors=1100

From my understanding, everything needs to be in a layer for you to control layer priority. But someone's global.css isn't in a layer. We could wrap all styles in a layer, but that would be tricky to do. How could we know what is a global style vs. a component style? Are only .astro styles prioritized or all component types? How do we do the wrapping without breaking source maps?

I agree that's it's an interesting tool that we can potentially use, I'm just not sure how to use it at this time.

Also, automatically putting styles into layers without the user knowing about it means that they can't effectively use layers of their own. I think it's going to take some time (and more usage in the general web community) before we understand how to use it.

This proposal is meant to be an immediate fix to the problem, while leaving the door open for future experimentation on better approaches.

[tony-sull]

@matthewp could have sworn I sent a reply to this from mobile, looks like it never published! Sorry for the delay!

I could see us handling that by defining what layers Astro supports out of the box. Global styles could be wrapped in something like @layer astro.global { } or similar to make sure it's always layered correctly compared to other layers like astro.imports or astro.components

I'm always torn on that kind of solution since it's really dependent on documenting a naming convention for the layers, I could go either way on whether that's worth the tradeoff.

[matthewp]

This RFC is now under consensus vote. If anyone sees a reason as to why this RFC should not be merged, please chime in now. Thank you!

[ThatOneCalculator]

I've reviewed the RFC, and it seems good. However, the "Switch the default in 3.0" part may be a bit polarizing -- this may work better as an opt-in feature?

[tony-sull]

Big 👍 from me!

My comments above fall more in the "what could we do here in a future RFC" bucket - I really like this proposal for a user configurable toggle to switch between :where() and class scoping, clean solution to the problem at hand!

[matthewp]

@ThatOneCalculator We have to pick one as the default. Given our inability to guarantee CSS ordering going with where as a default sets people up to have dev/prod differences. I don't think we can keep allowing that as a default. Until we figure out a solution that uses @layer or @scope or something else, class is the sane default here. Advanced users who want more control can use where knowing the potential downsides.

[ThatOneCalculator]

Fair enough.