Subtotal 0,00 د.إ Subtotal: 0,00 د.إ
SCOPED
Scoped CSS in 2027Shadow DOM, Modules & @scope
Every developer who’s worked on a large codebase has hit this: you change a `.card` style and something completely unrelated breaks across the app. You rename a class and spend 20 minutes hunting for all the places it was used. You add a third-party component and its styles leak into yours.
Global CSS was fine for small sites. For component-based applications, it’s a liability.
Scoped CSS means styles that apply *only* to their intended component — no leaking in, no bleeding out. In 2027, you have more options than ever to achieve this, and picking the right one depends on your stack.
“Shadow DOM lets you attach a DOM tree to an element, and have the internals hidden from JavaScript and CSS running in the page.”
MDN Web Docs
MODULES
The Practical WorkaroundCSS Modules
CSS Modules aren’t a browser feature — they’re a build-tool transformation (Webpack, Vite, esbuild). They automatically generate unique class names so styles are guaranteed never to collide.
/* Button.module.css */
.button {
padding: 0.5rem 1.25rem;
background: #275896;
color: white;
border-radius: 6px;
font-weight: 500;
}
.button:hover {
background: #0d2266;
}
.primary {
font-size: 1rem;
}
.small {
font-size: 0.875rem;
padding: 0.25rem 0.75rem;
}// Button.jsx (React)
import styles from "./Button.module.css";
export function Button({ variant = "primary", size, children, onClick }) {
return (
<button
className={`${styles.button} ${styles[size] ?? ""}`}
onClick={onClick}
>
{children}
</button>
);
}
// In the compiled output, .button becomes something like:
// .Button_button__xK9mZ — globally unique, zero collisionsPros
Simple, widely supported, works with any CSS feature, great TypeScript support.
Cons
Build-tool dependency, no true encapsulation (styles are still global, just uniquely named), can’t style slotted/child content from outside.
SHADOW DOMW
True EncapsulationShadow DOM
Shadow DOM is a native browser feature that creates a completely isolated DOM subtree. Styles inside the shadow root cannot affect the outside, and outside styles cannot affect the inside (with a few exceptions like inherited properties and CSS custom properties).
// Native Web Component with Shadow DOM
class ProfileCard extends HTMLElement {
constructor() {
super();
// Attach a shadow root — "open" means JS can access it from outside
const shadow = this.attachShadow({ mode: "open" });
shadow.innerHTML = `
<style>
/* These styles ONLY apply inside this shadow root */
:host {
display: block;
border-radius: 8px;
overflow: hidden;
font-family: system-ui, sans-serif;
}
.card {
padding: 1.5rem;
border: 1px solid #e2e8f0;
background: white;
}
.name {
font-size: 1.125rem;
font-weight: 600;
color: #0d2266;
margin-block-end: 0.25rem;
}
.role {
color: #808080;
font-size: 0.875rem;
}
</style>
<div class="card">
<p class="name"><slot name="name">Anonymous</slot></p>
<p class="role"><slot name="role">Developer</slot></p>
</div>
`;
}
}
customElements.define("profile-card", ProfileCard);<!-- Usage — completely framework-agnostic -->
<profile-card>
<span slot="name">Sarah Ahmed</span>
<span slot="role">Senior Frontend Engineer</span>
</profile-card>Pros
True isolation, works in any framework, reusable across projects.
Cons
Verbose to write, can’t style internal parts directly from outside (use `::part()` for escape hatches), inherited CSS doesn’t cross shadow boundaries.
PART
Styling Shadow DOM From Outside`::part()`
/* Allow external CSS to reach specific shadow parts */
/* In the shadow DOM component, expose a part: */
/* <button part="trigger">Click me</button> */
/* From outside the component: */
profile-card::part(trigger) {
background: #275896;
border-radius: 4px;
}VUE
The DX Sweet SpotVue Scoped Styles
Vue’s `<style scoped>` is similar to CSS Modules but with even cleaner ergonomics. It uses PostCSS to add a unique `data-v-*` attribute to both the component’s elements and CSS selectors — no class renaming, no imports.
<!-- ProfileCard.vue -->
<template>
<div class="card">
<p class="name">{{ name }}</p>
<p class="role">{{ role }}</p>
</div>
</template>
<script setup>
defineProps(["name", "role"]);
</script>
<style scoped>
/* This .card only affects THIS component's .card elements */
.card {
padding: 1.5rem;
border: 1px solid #e2e8f0;
border-radius: 8px;
}
.name {
font-weight: 600;
color: #0d2266;
}
/* Use :deep() to intentionally pierce scoping for child components */
:deep(.child-class) {
color: #808080;
}
</style>Pros
Minimal syntax, no imports needed, excellent DX, full CSS feature support.
Cons
Vue-specific, compiled output, `:deep()` can get messy if overused.
CSS SCOPE
The Native FutureCSS `@scope`
The new `@scope` rule is a native CSS feature that lets you define a scoping root and an optional lower boundary — no build tools, no framework.
/* @scope — styles apply only within .card, not leaking out */
@scope (.card) {
.title {
font-size: 1.25rem;
font-weight: 600;
color: #0d2266;
}
.description {
color: #808080;
line-height: 1.6;
}
}
/* Scoping with a lower boundary — styles apply between .card and .footer */
@scope (.card) to (.card-footer) {
p {
margin-block-end: 0.75rem;
}
}NOTE:
As of 2027, `@scope` has cross-browser support (Chrome, Firefox 131+, Safari). Use with progressive enhancement in mind.
Pros
Native CSS, no build tools, elegant lower-boundary concept, great for style isolation without components.
Cons
Still relatively new, some edge cases with Shadow DOM need care.
| Scenario | Recommended Approach |
|---|---|
| React project, Vite/Webpack build | CSS Modules |
| Vue 3 project | Vue <style scoped> |
| Framework-agnostic web component | Shadow DOM |
| Plain CSS, modern browser targets | @scope |
| Already using Tailwind | Tailwind + @layer (scoping via utility discipline) |
| Design system published as npm package | CSS Modules or Shadow DOM (web components) |
WHY MATTERS
Why This Matters in PracticeFor Business Leaders
CSS encapsulation problems scale with team size. When you have one developer, global CSS is manageable. With five developers and fifty components, it becomes a daily source of regressions and debugging time.
Every unscoped style is a potential bug waiting to happen. Investing in a consistent scoping strategy early saves significant engineering time as the codebase grows. This is the kind of technical foundation that determines whether a product becomes easier or harder to maintain as it scales.
Explore project snapshots or discuss custom web solutions.
A good architecture is one where you can change one thing without changing everything else.
Michael Feathers,
Working Effectively with Legacy Code - 2004
Thank You for Spending Your Valuable Time
I truly appreciate you taking the time to read blog. Your valuable time means a lot to me, and I hope you found the content insightful and engaging!
FAQ's
Frequently Asked Questions
No HTML changes needed. Logical properties are purely CSS. You may need to add `dir="rtl"` to your `<html>` or a container element to trigger RTL layout, but your markup structure stays the same.
`direction` controls inline (horizontal) text flow — left-to-right vs right-to-left. `writing-mode` changes the entire axis of text flow — horizontal vs vertical. Logical properties adapt to both automatically.
Yes, but be careful. Mixing them can cause unexpected results, especially when directions change. If you use `margin-left` and `margin-inline-start` on the same element, both apply and can conflict. Pick one approach per property and be consistent.
A few older properties are still catching up. `background-position` doesn't have a full logical equivalent in all browsers yet. For most layout and spacing properties however, logical equivalents exist and have excellent browser support.
Tailwind v3.3+ introduced logical property utilities like `ms-*` (margin-inline-start), `me-*` (margin-inline-end), `ps-*`, `pe-*`. If you're on Tailwind, use these classes. They work exactly the same way under the hood.
Comments are closed