هنگام یادگیری اصول اولیه CSS، نوشتن سبک های مدولار، قابل استفاده مجدد و توصیفی برای اطمینان از قابلیت نگهداری، آموزش داده می شود. اما وقتی توسعهدهندگان با برنامههای دنیای واقعی درگیر میشوند، اغلب اضافه کردن ویژگیهای UI بدون نشت سبکها در مناطق ناخواسته غیرممکن به نظر میرسد. این موضوع اغلب به یک حلقه خودشکوفایی تبدیل می شود. سبک هایی که از نظر تئوری به یک عنصر یا کلاس محدود می شوند در جایی که به آنها تعلق ندارند نشان داده می شوند. این امر توسعه دهنده را مجبور می کند تا انتخابگرهای خاص تری را برای نادیده گرفتن سبک های لو رفته ایجاد کند، که سپس به طور تصادفی سبک های جهانی و غیره را نادیده می گیرند. قراردادهای نام سخت کلاس، مانند BEM، یکی از راه حل های نظری برای این موضوع است. متدولوژی BEM (Block, Element, Modifier) روشی سیستماتیک برای نامگذاری کلاسهای CSS برای اطمینان از قابلیت استفاده مجدد و ساختار درون فایلهای CSS است. قراردادهای نامگذاری مانند این می تواند بار شناختی را با استفاده از زبان دامنه برای توصیف عناصر و وضعیت آنها کاهش دهد و اگر به درستی اجرا شود، می تواند حفظ سبک ها را برای برنامه های بزرگ آسان تر کند. با این حال، در دنیای واقعی، همیشه اینطور نیست. اولویت ها می توانند تغییر کنند و با تغییر، اجرا ناسازگار می شود. تغییرات کوچک در ساختار HTML می تواند نیاز به بازنگری نام کلاس CSS زیادی داشته باشد. با برنامههای جلویی بسیار تعاملی، نامهای کلاسهایی که از الگوی BEM پیروی میکنند میتوانند طولانی و دشوار شوند (به عنوان مثال، app-user-overview__status--is-authenticating)، و عدم رعایت کامل قوانین نامگذاری ساختار سیستم را شکسته و در نتیجه مزایای آن را نفی میکند. با توجه به این چالش ها، جای تعجب نیست که توسعه دهندگان به چارچوب ها روی آورده اند، Tailwind محبوب ترین فریم ورک CSS است. به جای تلاش برای مبارزه با چیزی که به نظر می رسد یک جنگ ویژگی غیرقابل پیروزی بین سبک ها است، راحت تر از CSS Cascade صرف نظر کنید و از ابزارهایی استفاده کنید که جداسازی کامل را تضمین می کنند. توسعه دهندگان بیشتر به Utilities متکی هستند چگونه متوجه شویم که برخی از توسعه دهندگان علاقه مند به اجتناب از سبک های آبشاری هستند؟ این ظهور ابزارهای front-end "مدرن" است - مانند چارچوب های CSS-in-JS - که به طور خاص برای این منظور طراحی شده اند. کار با سبکهای مجزا که به شدت به اجزای خاص محدود شدهاند، میتواند مانند یک نفس تازه به نظر برسد. این نیاز به نامگذاری چیزها را از بین می برد - که هنوز هم یکی از منفورترین و وقت گیرترین کارهای فرانت اند است - و به توسعه دهندگان اجازه می دهد بدون درک کامل یا استفاده از مزایای وراثت CSS، سازنده باشند. اما حذف CSS Cascade مشکلات خاص خود را دارد. برای مثال، نوشتن سبکها در جاوا اسکریپت به پیکربندیهای ساخت سنگین نیاز دارد و اغلب منجر به درهم آمیختن سبکها با نشانهگذاری مؤلفه یا HTML میشود. بهجای قراردادهای نامگذاری بهدقت در نظر گرفته شده، به ابزارهای ساخت اجازه میدهیم تا انتخابگرها و شناسهها را بهطور خودکار برای ما تولید کنند (مثلاً .jsx-3130221066)، که از توسعهدهندگان میخواهد تا با شبهزبان دیگری به خودی خود همراه باشند. (انگار بار شناختی درک آنچه که تمام استفادههای مؤلفه شما انجام میدهند از قبل کافی نبوده است!) انتزاع بیشتر کار نامگذاری کلاس ها به ابزارسازی به این معنی است که اشکال زدایی اولیه اغلب به نسخه های برنامه خاصی که برای توسعه کامپایل شده اند، محدود می شود، به جای استفاده از ویژگی های بومی مرورگر که از اشکال زدایی زنده پشتیبانی می کنند، مانند ابزارهای توسعه دهنده. تقریباً مانند این است که ما نیاز به توسعه ابزارهایی داریم تا ابزارهایی را که برای انتزاعی کردن آنچه که وب در حال حاضر ارائه میکند، اشکالزدایی کنیم - همه به خاطر فرار از "درد" نوشتن CSS استاندارد. خوشبختانه، ویژگیهای مدرن CSS نه تنها نوشتن CSS استاندارد را انعطافپذیرتر میکند، بلکه به توسعهدهندگانی مانند ما قدرت بیشتری میدهد تا آبشار را مدیریت کنند و آن را برای ما کارساز کنند. لایههای آبشار CSS نمونهای عالی هستند، اما ویژگی دیگری وجود دارد که مورد توجه قرار نمیگیرد – اگرچه اکنون که اخیراً سازگار با Baseline شده است، این ویژگی در حال تغییر است. CSS @scope At-Rule من CSS @scope at-rule را یک درمان بالقوه برای نوعی اضطراب ناشی از نشت سبک میدانم که پوشش دادهایم، اضطرابی که ما را مجبور به به خطر انداختن مزایای وب بومی برای انتزاعها و ابزارهای ساخت اضافی نمیکند. «@scope CSS at-rule به شما امکان میدهد عناصر را در زیردرختهای DOM خاص انتخاب کنید، و عناصر را دقیقاً بدون نوشتن انتخابگرهای خیلی خاص که به سختی نادیده گرفته میشوند، هدف قرار دهید، و بدون اینکه انتخابگرهای خود را خیلی محکم به ساختار DOM متصل کنید.» - MDN.
به عبارت دیگر، ما میتوانیم با سبکهای مجزا در موارد خاص بدون قربانی کردن وراثت، آبشار یا حتی جداسازی اساسی نگرانیها کار کنیم.این یک اصل راهنما درازمدت در توسعه front-end بوده است. به علاوه، پوشش مرورگر عالی دارد. در واقع، فایرفاکس 146 پشتیبانی از @scope را در ماه دسامبر اضافه کرد و آن را برای اولین بار با Baseline سازگار کرد. در اینجا یک مقایسه ساده بین یک دکمه با استفاده از الگوی BEM در مقابل قانون @scope وجود دارد:
<سبک> .button .button__text { /* styles text button */ } .button .button__icon { /* styles icon button */ } .button--primary { styles button اولیه */ }
<سبک> @scope (.primary-button) { span:first-child { /* styles text button */ } span:last-child { /* styles icon button */ } }
قانون @scope امکان دقت با پیچیدگی کمتر را فراهم می کند. توسعه دهنده دیگر نیازی به ایجاد مرزها با استفاده از نام کلاس ها ندارد، که به نوبه خود به آنها اجازه می دهد انتخابگرها را بر اساس عناصر HTML بومی بنویسند، در نتیجه نیاز به الگوهای نام کلاس CSS تجویزی را از بین می برد. با حذف ساده نیاز به مدیریت نام کلاس، @scope میتواند ترس مرتبط با CSS را در پروژههای بزرگ کاهش دهد. استفاده پایه برای شروع، قاعده @scope را به CSS خود اضافه کنید و یک انتخابگر ریشه که استایلها به آن محدوده میشوند را وارد کنید: @scope (<انتخابگر>) { /* سبک ها به <انتخابگر> */ }
بنابراین، برای مثال، اگر بخواهیم استایل ها را به یک عنصر
@scope (nav) { a { /* سبک های پیوند در محدوده ناو */ }
a:active { /* سبک های پیوند فعال */ }
a:active::before { /* پیوند فعال با شبه عنصر برای استایل بیشتر */ }
@media (حداکثر عرض: 768 پیکسل) { a { /* تنظیمات پاسخگو */ } } }
این به خودی خود یک ویژگی پیشگامانه نیست. با این حال، یک آرگومان دوم را می توان به دامنه اضافه کرد تا یک مرز پایین تر ایجاد کند، که به طور موثر نقاط شروع و پایان دامنه را مشخص می کند.
/* هر عنصری در داخل ul استایل های اعمال شده را نخواهد داشت */ @scope (nav) تا (ul) { یک { اندازه فونت: 14px; } }
به این عمل محدودهبندی donut گفته میشود، و روشهای مختلفی وجود دارد که میتوان از آنها استفاده کرد، از جمله یک سری انتخابگرهای مشابه و بسیار خاص که بهطور محکم با ساختار DOM کوپل شدهاند، یک انتخابگر :نه شبه، یا تخصیص نامهای کلاس خاص به عناصر در
نتیجه گیری فریمورکهای CSS اولیۀ کاربردی، مانند Tailwind، برای نمونهسازی اولیه و پروژههای کوچکتر به خوبی کار میکنند. با این حال، هنگامی که در پروژههای بزرگتر که بیش از چند توسعهدهنده در آن شرکت دارند، مزایای آنها به سرعت کاهش مییابد. توسعه Front-end در چند سال اخیر به طور فزاینده ای پیچیده شده است و CSS نیز از این قاعده مستثنی نیست. در حالی که قانون @scope یک راه حل نیست، می تواند نیاز به ابزار پیچیده را کاهش دهد. هنگامی که به جای یا در کنار نامگذاری کلاس استراتژیک استفاده می شود، @scope می تواند نوشتن CSS قابل نگهداری را آسان تر و سرگرم کننده تر کند. ادامه مطلب
CSS @scope (MDN) «CSS @scope»، خوان دیگو رودریگز (CSS-Tricks) یادداشت های انتشار فایرفاکس 146 (فایرفاکس) پشتیبانی مرورگر (CanIUse) فریمورک های محبوب CSS (وضعیت CSS 2024) "C" در CSS: Cascade، Thomas Yip (CSS-Tricks) معرفی BEM (دریافت BEM)
