آینده معماری CSS را با قانون پیشنهادی @package بررسی کنید. راهنمای جامع مدیریت بسته‌های CSS به صورت Native، کپسوله‌سازی و مدیریت وابستگی.
انقلابی در CSS: بررسی عمیق قانون @package برای مدیریت بسته‌های Native
برای دهه‌ها، توسعه‌دهندگان با یکی از ویژگی‌های تعریف‌کننده و چالش‌برانگیز برگه‌های استایل آبشاری (CSS) دست و پنجه نرم کرده‌اند: ماهیت سراسری آن. دامنه سراسری CSS در عین قدرتمند بودن، منبع جنگ‌های بی‌شماری در مورد ویژگی‌ها، بحث‌های مربوط به قرارداد نام‌گذاری و سردردهای معماری بوده است. ما سیستم‌های دقیقی را در بالای CSS برای رام کردن آن ساخته‌ایم، از روش‌شناسی BEM گرفته تا راهکارهای پیچیده مبتنی بر جاوااسکریپت. اما چه می‌شد اگر راه‌حل یک کتابخانه یا یک قرارداد نبود، بلکه یک بخش Native از خود زبان CSS بود؟ وارد مفهوم قانون بسته CSS شوید، یک پیشنهاد آینده‌نگرانه که هدف آن آوردن مدیریت بسته‌های قوی و Native مرورگر به طور مستقیم به برگه‌های استایل ما است.
این راهنمای جامع این پیشنهاد تحول‌آفرین را بررسی می‌کند. ما مشکلات اصلی را که هدف آن حل آنها است، تشریح می‌کنیم، سینتکس و مکانیک پیشنهادی آن را تجزیه و تحلیل می‌کنیم، نمونه‌های عملی پیاده‌سازی را مرور می‌کنیم و نگاهی می‌اندازیم به اینکه این موضوع برای آینده توسعه وب چه معنایی دارد. چه یک معمار باشید که با مقیاس‌پذیری سیستم طراحی دست و پنجه نرم می‌کند یا یک توسعه‌دهنده که از پیشوندگذاری نام کلاس‌ها خسته شده‌اید، درک این تحول در CSS بسیار مهم است.
مشکل اصلی: چرا CSS به مدیریت بسته Native نیاز دارد؟
قبل از اینکه بتوانیم از راه‌حل قدردانی کنیم، باید مشکل را به طور کامل درک کنیم. چالش‌های مدیریت CSS در مقیاس بزرگ جدید نیستند، اما در عصر معماری‌های مبتنی بر کامپوننت و پروژه‌های بزرگ مشارکتی، حادتر شده‌اند. مسائل عمدتاً از چند ویژگی اساسی زبان ناشی می‌شوند.
معمای فضای نام سراسری
در CSS، هر سلکتوری که می‌نویسید در یک دامنه سراسری، مشترک و واحد زندگی می‌کند. یک کلاس .button که در برگه استایل یک کامپوننت هدر تعریف شده است، همان کلاس .button است که در برگه استایل یک کامپوننت فوتر به آن ارجاع داده شده است. این بلافاصله خطر بالایی از برخورد ایجاد می‌کند.
یک سناریوی ساده و رایج را در نظر بگیرید. تیم شما یک کامپوننت کارت زیبا را توسعه می‌دهد:
.card { background: white; border-radius: 8px; box-shadow: 0 4px 8px rgba(0,0,0,0.1); }
.title { font-size: 1.5em; color: #333; }
بعداً، یک تیم دیگر یک ویجت وبلاگ شخص ثالث را ادغام می‌کند که از نام کلاس‌های عمومی .card و .title نیز استفاده می‌کند، اما با استایل‌دهی کاملاً متفاوت. ناگهان، کامپوننت کارت شما خراب می‌شود، یا ویجت وبلاگ اشتباه به نظر می‌رسد. آخرین برگه استایل بارگذاری شده برنده می‌شود و شما اکنون در حال اشکال‌زدایی یک مشکل ویژگی یا ترتیب منبع هستید. این ماهیت سراسری توسعه‌دهندگان را مجبور به الگوهای کدنویسی تدافعی می‌کند.
جهنم مدیریت وابستگی
برنامه‌های وب مدرن به ندرت از ابتدا ساخته می‌شوند. ما به یک اکوسیستم غنی از کتابخانه‌های شخص ثالث، کیت‌های رابط کاربری و فریم‌ورک‌ها متکی هستیم. مدیریت استایل‌ها برای این وابستگی‌ها اغلب یک فرآیند شکننده است. آیا یک فایل CSS بزرگ و یکپارچه را وارد می‌کنید و آنچه را که نیاز دارید لغو می‌کنید، به این امید که چیزی را خراب نکنید؟ آیا به نویسندگان کتابخانه اعتماد دارید که همه کلاس‌های خود را به طور کامل نام‌گذاری کرده‌اند تا از درگیری با کد شما جلوگیری شود؟ این فقدان یک مدل وابستگی رسمی به این معنی است که ما اغلب به بسته‌بندی همه چیز در یک فایل CSS بزرگ متوسل می‌شویم، وضوح در مورد منشاء استایل‌ها را از دست می‌دهیم و یک کابوس نگهداری ایجاد می‌کنیم.
کمبودهای راه‌حل‌های فعلی
جامعه توسعه‌دهندگان در ایجاد راه‌حل‌هایی برای دور زدن این محدودیت‌ها فوق‌العاده نوآور بوده است. با این حال، هر کدام با بده‌بستانی‌های خاص خود همراه است:
- روش‌شناسی‌ها (مانند BEM): روش‌شناسی Block, Element, Modifier یک قرارداد نام‌گذاری دقیق (به عنوان مثال،
.card__title--primary) برای شبیه‌سازی فضای نام ایجاد می‌کند. مزیت: این فقط CSS است و نیازی به هیچ ابزاری ندارد. نقطه ضعف: می‌تواند منجر به نام کلاس‌های بسیار طولانی و پرحرف شود، کاملاً به نظم و انضباط توسعه‌دهنده متکی است و کپسوله‌سازی واقعی را ارائه نمی‌دهد. یک اشتباه در نام‌گذاری همچنان می‌تواند منجر به نشت استایل شود. - ابزارهای زمان ساخت (مانند CSS Modules): این ابزارها CSS شما را در زمان ساخت پردازش می‌کنند و به طور خودکار نام کلاس‌های منحصر به فردی را ایجاد می‌کنند (به عنوان مثال،
.card_title_a8f3e). مزیت: ایزوله کردن دامنه واقعی در سطح فایل را فراهم می‌کند. نقطه ضعف: به یک محیط ساخت خاص (مانند Webpack یا Vite) نیاز دارد، پیوند مستقیم بین CSS که می‌نویسید و HTML که می‌بینید را قطع می‌کند و یک ویژگی Native مرورگر نیست. - CSS-in-JS: کتابخانه‌هایی مانند Styled Components یا Emotion به شما این امکان را می‌دهند که CSS را مستقیماً در فایل‌های کامپوننت جاوااسکریپت خود بنویسید. مزیت: کپسوله‌سازی قدرتمند در سطح کامپوننت و استایل‌دهی پویا را ارائه می‌دهد. نقطه ضعف: می‌تواند سربار زمان اجرا را وارد کند، اندازه بسته جاوااسکریپت را افزایش می‌دهد و جداسازی سنتی نگرانی‌ها را محو می‌کند، که برای بسیاری از تیم‌ها یک نکته مورد بحث است.
- Shadow DOM: یک فناوری Native مرورگر، بخشی از مجموعه Web Components، که کپسوله‌سازی کامل DOM و استایل را فراهم می‌کند. مزیت: قوی‌ترین شکل ایزوله کردن موجود است. نقطه ضعف: کار با آن می‌تواند پیچیده باشد، و استایل‌دهی به کامپوننت‌ها از بیرون (تم‌دهی) نیاز به یک رویکرد عمدی با استفاده از CSS Custom Properties یا
::partدارد. این یک راه‌حل برای مدیریت وابستگی‌های CSS در یک متن سراسری نیست.
در حالی که همه این رویکردها معتبر و مفید هستند، اما راه‌حل‌های موقتی هستند. پیشنهاد قانون بسته CSS هدف آن پرداختن به ریشه مشکل با ساخت مفاهیم دامنه، وابستگی‌ها و APIهای عمومی به طور مستقیم در زبان است.
معرفی قانون CSS @package: یک راه‌حل Native
مفهوم بسته CSS، همانطور که در پیشنهادات اخیر W3C بررسی شده است، در مورد یک @package واحد نیست، بلکه مجموعه‌ای از ویژگی‌های جدید و پیشرفته است که با هم کار می‌کنند تا یک سیستم بسته‌بندی ایجاد کنند. ایده اصلی این است که به یک برگه استایل اجازه دهیم یک مرز واضح را تعریف کند، و استایل‌های داخلی آن را به طور پیش فرض خصوصی کند در حالی که به طور صریح یک API عمومی را برای مصرف توسط سایر برگه‌های استایل در معرض دید قرار می‌دهد.
مفاهیم و سینتکس اصلی
بنیان این سیستم بر دو at-rule اصلی استوار است: @export و یک @import مدرن شده. یک برگه استایل با استفاده از این قوانین به یک "بسته" تبدیل می‌شود.
1. حریم خصوصی به طور پیش فرض: تغییر اساسی در تفکر این است که تمام استایل‌های موجود در یک بسته (یک فایل CSS که برای توزیع در نظر گرفته شده است) به طور پیش فرض محلی یا خصوصی در نظر گرفته می‌شوند. آنها کپسوله شده‌اند و بر دامنه سراسری یا سایر بسته‌ها تأثیر نمی‌گذارند مگر اینکه به طور صریح صادر شوند.
2. API عمومی با @export: برای اینکه امکان تم‌دهی و قابلیت همکاری فراهم شود، یک بسته می‌تواند با استفاده از at-rule @export یک API عمومی ایجاد کند. اینگونه است که یک بسته می‌گوید، "اینها بخش‌هایی از من هستند که دنیای خارج اجازه دارد ببیند و با آنها تعامل داشته باشد." در حال حاضر، این پیشنهاد بر صادرات دارایی‌های غیر سلکتوری تمرکز دارد.
- CSS Custom Properties: مکانیسم اصلی برای تم‌دهی.
- Keyframe Animations: برای به اشتراک گذاشتن انیمیشن‌های رایج.
- CSS Layers: برای مدیریت ترتیب آبشاری.
- سایر صادرات بالقوه: پیشنهادات آینده ممکن است شامل صادرات شمارنده‌ها، نام‌های گرید و موارد دیگر باشد.
سینتکس ساده است:
/* Inside my-theme.css */
@export --brand-primary: #0a74d9;
@export --border-radius-default: 5px;
@export standard-fade-in {
from { opacity: 0; }
to { opacity: 1; }
}
3. مصرف کنترل شده با @import: قانون آشنای @import فوق‌العاده شارژ می‌شود. این مکانیسمی برای وارد کردن یک بسته و دسترسی به API صادر شده آن می‌شود. این پیشنهاد شامل سینتکس جدیدی برای رسیدگی به این موضوع به روشی ساختاریافته است و از آلودگی فضای نام سراسری که @import سنتی می‌تواند ایجاد کند، جلوگیری می‌کند.
/* Inside app.css */
@import url("my-theme.css"); /* Imports the package and its public API */
پس از وارد شدن، برنامه می‌تواند از custom properties صادر شده برای استایل‌دهی به کامپوننت‌های خود استفاده کند و از سازگاری و پایبندی به سیستم طراحی تعریف شده در بسته تم اطمینان حاصل کند.
یک پیاده‌سازی عملی: ساخت یک بسته کامپوننت
تئوری عالی است، اما بیایید ببینیم این در عمل چگونه کار می‌کند. ما یک بسته کامپوننت "Alert" خودکفا و قابل تم‌دهی خواهیم ساخت که از استایل‌های خصوصی خود و یک API عمومی برای سفارشی‌سازی تشکیل شده است.
مرحله 1: تعریف بسته (`alert-component.css`)
ابتدا، فایل CSS را برای کامپوننت خود ایجاد می‌کنیم. این فایل "بسته" ما است. ما ساختار و ظاهر اصلی هشدار را تعریف خواهیم کرد. توجه داشته باشید که ما از هیچ قانون wrapper خاصی استفاده نمی‌کنیم. خود فایل مرز بسته است.
/* alert-component.css */
/* --- Public API --- */
/* These are the customizable parts of our component. */
@export --alert-bg-color: #e6f7ff;
@export --alert-border-color: #91d5ff;
@export --alert-text-color: #0056b3;
@export --alert-border-radius: 4px;
/* --- Private Styles --- */
/* These styles are encapsulated within this package.
They use the exported custom properties for their values.
The `.alert` class will be scoped when this is eventually combined with `@scope`. */
.alert {
padding: 1em 1.5em;
border: 1px solid var(--alert-border-color);
background-color: var(--alert-bg-color);
color: var(--alert-text-color);
border-radius: var(--alert-border-radius);
display: flex;
align-items: center;
gap: 0.75em;
}
.alert-icon {
/* More private styles for an icon within the alert */
flex-shrink: 0;
}
.alert-message {
/* Private styles for the message text */
flex-grow: 1;
}
نکته کلیدی: ما یک جداسازی واضح داریم. قوانین @export در بالا قرارداد با دنیای خارج را تعریف می‌کنند. قوانین مبتنی بر کلاس در زیر جزئیات پیاده‌سازی داخلی هستند. سایر برگه‌های استایل نمی‌توانند و نباید مستقیماً .alert-icon را هدف قرار دهند.
مرحله 2: استفاده از بسته در یک برنامه (`app.css`)
اکنون، بیایید از کامپوننت هشدار جدید خود در برنامه اصلی خود استفاده کنیم. ما با وارد کردن بسته شروع می‌کنیم. HTML ساده و معنایی باقی می‌ماند.
HTML (`index.html`):
<div class="alert">
<span class="alert-icon">ℹ️</span>
<p class="alert-message">This is an informational message using our component package.</p>
</div>
CSS (`app.css`):
/* app.css */
/* 1. Import the package. The browser fetches this file,
processes its styles, and makes its exports available. */
@import url("alert-component.css");
/* 2. Global styles for the application's layout */
body {
font-family: sans-serif;
padding: 2em;
background-color: #f4f7f6;
}
در این مرحله، کامپوننت هشدار با استایل پیش فرض با تم آبی در صفحه رندر می‌شود. استایل‌ها از alert-component.css اعمال می‌شوند زیرا markup کامپوننت از کلاس .alert استفاده می‌کند و برگه استایل وارد شده است.
مرحله 3: سفارشی‌سازی و تم‌دهی کامپوننت
قدرت واقعی از توانایی تم‌دهی آسان کامپوننت بدون نوشتن لغوهای نامرتب ناشی می‌شود. بیایید یک نوع "success" و "danger" با لغو API عمومی (custom properties) در برگه استایل برنامه خود ایجاد کنیم.
HTML (`index.html`):
<div class="alert">
<p class="alert-message">This is the default informational alert.</p>
</div>
<div class="alert alert-success">
<p class="alert-message">Your operation was successful!</p>
</div>
<div class="alert alert-danger">
<p class="alert-message">An error occurred. Please try again.</p>
</div>
CSS (`app.css`):
@import url("alert-component.css");
body {
font-family: sans-serif;
padding: 2em;
background-color: #f4f7f6;
}
/* --- Theming the Alert Component --- */
/* We are NOT targeting internal classes like .alert-icon.
We are only using the official, public API. */
.alert-success {
--alert-bg-color: #f6ffed;
--alert-border-color: #b7eb8f;
--alert-text-color: #389e0d;
}
.alert-danger {
--alert-bg-color: #fff1f0;
--alert-border-color: #ffa39e;
--alert-text-color: #cf1322;
}
این یک روش تمیز، قوی و قابل نگهداری برای مدیریت استایل کامپوننت است. کد برنامه نیازی به دانستن چیزی در مورد ساختار داخلی کامپوننت هشدار ندارد. فقط با custom properties پایدار و مستند تعامل دارد. اگر نویسنده کامپوننت تصمیم بگیرد نام کلاس‌های داخلی را از .alert-message به .alert__text تغییر دهد، استایل برنامه خراب نمی‌شود، زیرا قرارداد عمومی (custom properties) تغییر نکرده است.
مفاهیم پیشرفته و هم‌افزایی‌ها
مفهوم بسته CSS به گونه‌ای طراحی شده است که به طور یکپارچه با سایر ویژگی‌های CSS مدرن ادغام شود و یک سیستم قدرتمند و منسجم برای استایل‌دهی در وب ایجاد کند.
مدیریت وابستگی‌ها بین بسته‌ها
بسته‌ها فقط برای برنامه‌های کاربر نهایی نیستند. آنها می‌توانند یکدیگر را وارد کنند تا سیستم‌های پیچیده‌ای بسازند. یک بسته "theme" بنیادی را تصور کنید که فقط توکن‌های طراحی (رنگ‌ها، فونت‌ها، فاصله‌گذاری) را صادر می‌کند.
/* theme.css */
@export --color-brand-primary: #6f42c1;
@export --font-size-base: 16px;
@export --spacing-unit: 8px;
یک بسته کامپوننت دکمه می‌تواند این بسته تم را وارد کند تا از مقادیر آن استفاده کند، در حالی که custom properties خاص‌تر خود را نیز صادر می‌کند.
/* button-component.css */
@import url("theme.css"); /* Import the design tokens */
/* Public API for the button */
@export --btn-padding: var(--spacing-unit);
@export --btn-bg-color: var(--color-brand-primary);
/* Private styles for the button */
.button {
background-color: var(--btn-bg-color);
padding: var(--btn-padding);
/* ... other button styles */
}
این یک نمودار وابستگی واضح ایجاد می‌کند و ردیابی منشاء استایل‌ها و اطمینان از سازگاری در کل سیستم طراحی را آسان می‌کند.
ادغام با CSS Scope (@scope)
پیشنهاد بسته CSS ارتباط نزدیکی با یک ویژگی هیجان انگیز دیگر دارد: at-rule @scope. @scope به شما این امکان را می‌دهد که استایل‌ها را فقط در یک قسمت خاص از درخت DOM اعمال کنید. هنگامی که با هم ترکیب شوند، کپسوله‌سازی واقعی را ارائه می‌دهند. یک بسته می‌تواند استایل‌های خود را در داخل یک بلوک scope تعریف کند.
/* in alert-component.css */
@scope (.alert) {
:scope {
/* Styles for the .alert element itself */
padding: 1em;
}
.alert-icon {
/* This selector only matches .alert-icon INSIDE an .alert element */
color: blue;
}
}
/* This will NOT be affected, as it's outside the scope */
.alert-icon { ... }
این ترکیب تضمین می‌کند که استایل‌های یک بسته نه تنها یک API کنترل شده دارند، بلکه از نظر فیزیکی نیز از نشت کردن و تأثیرگذاری بر سایر قسمت‌های صفحه جلوگیری می‌کنند و مشکل فضای نام سراسری را در ریشه آن حل می‌کنند.
هم‌افزایی با Web Components
در حالی که Shadow DOM کپسوله‌سازی نهایی را فراهم می‌کند، بسیاری از کتابخانه‌های کامپوننت به دلیل پیچیدگی‌های استایل‌دهی از آن استفاده نمی‌کنند. سیستم بسته CSS یک جایگزین قدرتمند برای این کامپوننت‌های "light DOM" ارائه می‌دهد. این مزایای کپسوله‌سازی (از طریق @scope) و معماری تم‌دهی (از طریق @export) را بدون نیاز به جهش کامل به Shadow DOM ارائه می‌دهد. برای کسانی که از Web Components استفاده می‌کنند، بسته‌ها می‌توانند توکن‌های طراحی مشترک را که از طریق custom properties به Shadow DOM کامپوننت منتقل می‌شوند، مدیریت کنند و یک مشارکت کامل ایجاد کنند.
مقایسه @package با راه‌حل‌های موجود
این رویکرد Native جدید چگونه در برابر آنچه امروز استفاده می‌کنیم قرار می‌گیرد؟
- در مقابل CSS Modules: هدف بسیار مشابه است - استایل‌های scoped. با این حال، سیستم بسته CSS یک استاندارد Native مرورگر است، نه یک قرارداد ابزار ساخت. این بدان معناست که نیازی به لودرهای خاص یا تبدیل برای گرفتن نام کلاس‌های scoped محلی نیست. API عمومی نیز با
@exportصریح‌تر است، در مقایسه با دریچه فرار:globalدر CSS Modules. - در مقابل BEM: BEM یک قرارداد نام‌گذاری است که دامنه را شبیه‌سازی می‌کند. سیستم بسته CSS دامنه واقعی ارائه می‌دهد که توسط مرورگر اعمال می‌شود. این تفاوت بین یک درخواست مودبانه برای دست نزدن به چیزی و یک درب قفل شده است. این قوی‌تر است و کمتر در معرض خطای انسانی قرار می‌گیرد.
- در مقابل Tailwind CSS / Utility-First: فریم‌ورک‌های Utility-first مانند Tailwind یک پارادایم کاملاً متفاوت هستند و بر ترکیب رابط‌ها از کلاس‌های utility سطح پایین در HTML تمرکز دارند. یک سیستم بسته CSS برای ایجاد کامپوننت‌های معنایی سطح بالاتر طراحی شده است. این دو حتی می‌توانند همزیستی داشته باشند. می‌توان یک بسته کامپوننت را با استفاده از دستور
@applyTailwind به صورت داخلی ساخت، در حالی که همچنان یک API تمیز و سطح بالا برای تم‌دهی صادر می‌کند.
آینده معماری CSS: این برای توسعه‌دهندگان چه معنایی دارد؟
معرفی یک سیستم بسته CSS Native نشان دهنده یک تغییر اساسی در نحوه تفکر و نوشتن CSS است. این اوج سال‌ها تلاش و نوآوری جامعه است که در نهایت در خود پلتفرم پخته می‌شود.
تغییر به سمت استایل‌دهی Component-First
این سیستم مدل مبتنی بر کامپوننت را به عنوان یک شهروند درجه یک در دنیای CSS تثبیت می‌کند. این توسعه‌دهندگان را تشویق می‌کند تا قطعات کوچک، قابل استفاده مجدد و واقعاً خودکفا از رابط کاربری را بسازند که هر کدام استایل‌های خصوصی خود و یک رابط عمومی کاملاً تعریف شده دارند. این منجر به سیستم‌های طراحی مقیاس‌پذیرتر، قابل نگهداری‌تر و مقاوم‌تر می‌شود.
کاهش اتکا به ابزارهای ساخت پیچیده
در حالی که ابزارهای ساخت همیشه برای کارهایی مانند کوچک‌سازی و پشتیبانی از مرورگرهای قدیمی ضروری خواهند بود، یک سیستم بسته Native می‌تواند بخش CSS خطوط لوله ساخت ما را به طور چشمگیری ساده کند. نیاز به لودرها و پلاگین‌های سفارشی فقط برای رسیدگی به hashing نام کلاس و scoping می‌تواند ناپدید شود و منجر به ساخت‌های سریع‌تر و پیکربندی‌های ساده‌تر شود.
وضعیت فعلی و نحوه مطلع ماندن
بسیار مهم است که به یاد داشته باشید که سیستم بسته CSS، از جمله @export و ویژگی‌های مرتبط، در حال حاضر یک پیشنهاد است. هنوز در هیچ مرورگر پایداری در دسترس نیست. این مفاهیم به طور فعال توسط گروه کاری CSS W3C مورد بحث و بررسی قرار می‌گیرند. این بدان معناست که سینتکس و رفتاری که در اینجا توضیح داده شده است می‌تواند قبل از پیاده‌سازی نهایی تغییر کند.
برای پیگیری پیشرفت:
- توضیحات رسمی را بخوانید: CSSWG پیشنهادات را در GitHub میزبانی می‌کند. به دنبال توضیحات در مورد "CSS Scope" و ویژگی‌های مرتبط linking/importing باشید.
- فروشندگان مرورگر را دنبال کنید: مراقب پلتفرم‌هایی مانند Chrome Platform Status، موقعیت‌های استانداردهای Firefox و صفحات وضعیت ویژگی WebKit باشید.
- آزمایش با پیاده‌سازی‌های اولیه: هنگامی که این ویژگی‌ها در پشت پرچم‌های آزمایشی در مرورگرهایی مانند Chrome Canary یا Firefox Nightly قرار می‌گیرند، آنها را امتحان کنید و بازخورد ارائه دهید.
نتیجه‌گیری: فصل جدیدی برای CSS
سیستم بسته CSS پیشنهادی چیزی فراتر از یک مجموعه جدید از at-rule است. این یک بازاندیشی اساسی در CSS برای وب مدرن و مبتنی بر کامپوننت است. این درس‌های سخت به دست آمده از سال‌ها راه‌حل‌های مبتنی بر جامعه را می‌گیرد و مستقیماً در مرورگر ادغام می‌کند و آینده‌ای را ارائه می‌دهد که در آن CSS به طور طبیعی scoped است، وابستگی‌ها به طور صریح مدیریت می‌شوند و تم‌دهی یک فرآیند تمیز و استاندارد است.
با ارائه ابزارهای Native برای کپسوله‌سازی و ایجاد APIهای عمومی واضح، این تحول نوید می‌دهد که برگه‌های استایل ما را قوی‌تر، سیستم‌های طراحی ما را مقیاس‌پذیرتر و زندگی ما را به عنوان توسعه‌دهنده به‌طور قابل توجهی آسان‌تر کند. جاده از پیشنهاد تا پشتیبانی جهانی مرورگر طولانی است، اما مقصد یک CSS قدرتمندتر، قابل پیش‌بینی‌تر و ظریف‌تر است که واقعاً برای چالش‌های وب فردا ساخته شده است.