برخی از افراد بر این باور هستند که یادگیری CSS آسان است اما مسلط شدن روی مفاهیم شوارتر است. باید این را بگوییم که یادگیری اصول اولیه CSS واقعا ساده است اما با این حال، برخی از اشتباهات رایج نیز وجود دارد که بسیاری از ما به راحتی آن‌ها را مرتکب می‌شویم و همین موضوع باعث می‌شود تا مشکلاتی به‌وجود بیاید. در این مقاله یاد می‌گیریم که چگونه این اشتباهات را بشناسیم و از آن‌ها دوری کنیم.

۱) اختصاصی بودن بیش از اندازه

در ادامه یک مثال در این رابطه داریم که آن را باهم بررسی می‌کنیم:

#external-wrapper > .items-list + .actions a.link,
#content header nav.links > ul a,
section#external-wrapper footer.page-footer > ul a {
    /*...*/
}

چند مشکل بزرگ در سلکتورهای مثال بالا وجود دارد:

  1. برای دسترسی به المنت‌ها از IDها استفاده می‌کنند که به‌طور قابل توجهی این ویژگی اختصاصی بودن را بیشتر می‌کند.
  2. سلکتورها بسیار طولانی هستند و همین موضوع می‌تواند این ویژگی را افزایش دهد.
  3. آن‌ها به شکل غیرضروری نام کلاس‌ها را با یک المنت (به عنوان مثال footer.page-footer) ترکیب می‌کنند. که این مورد نه تنها ویژگی اختصاصی بودن را افزایش می‌دهد، بلکه امکان استفاده مجدد را بسیار محدود می‌کند.

برای حل این مشکل چه کاری باید انجام دهیم؟

به عنوان یک قاعده کلی، سلکتورهای ما باید تا حد امکان کوتاه باشند. بهترین حالت ممکن این است که سلکتور دارای یک سطح باشد، اما دو سطحی بودن نیز قابل قبول است. در نهایت بیشترین سطحی که یک سلکتور می‌تواند داشته باشد سه سطح است. همینطور تا حد ممکن باید از استفاده از IDها اجتناب کنیم (در ادامه کمی بیشتر در این موضوع صحبت خواهیم کرد) و نام تگ‌ها را به کلاس‌های خود اضافه نکنیم.

۲) استفاده نادرست از important!

این مورد هم باعث می‌شود تا مشکل اختصاصی بودن بیش از حد درست شود. استفاده از important! معمولاً به این معنی است که ما سعی می‌کنیم برخی از ویژگی‌ها را نسبت به ویژگی‌هایی که اولویت بالاتری دارند نادیده بگیریم، یا نمی‌خواهیم توسعه‌دهندگان دیگر بتوانند ویژگی‌هایی را که ما تنظیم می‌کنیم تغییر دهند. در مورد اول، به عنوان مثال ممکن است سعی کنیم یک کامپوننت third-party را شخصی‌سازی کنیم. این یک use case منصفانه (fair) با رعایت حقوق خواهد بود زیرا در این صورت ما کنترلی بر روی کد خارجی نداریم، مگر اینکه تصمیم بگیریم یک نسخه کپی از آن را حفظ کنیم. اگر نمی‌خواهیم افراد دیگر یک یا چند ویژگی را از قاعده‌ای که ما تعریف کرده‌ایم تغییر دهند، سؤالی که باید از خود بپرسیم این است: چرا؟ چرا سایر برنامه‌نویس‌ها نباید بتوانند برخی از جنبه‌های استایل برنامه را سفارشی‌ کنند، به خصوص اگر همه ما روی یک پروژه کار می‌کنیم؟ اگر واقعاً پاسخ خوبی برای این سؤال پیدا نکردیم، شاید بهتر باشد در استفاده از important! تجدید نظر کنیم.

برای حل این مشکل چه کاری باید انجام دهیم؟

اگر ما یا تیم ما کدی داریم که حاوی قانون(هایی) است و  می‌خواهیم آن‌ها را نادیده بگیریم، به منظور استفاده کم‌تر از سلکتورهای اختصاصی باید refactoring آن‌ها را نیز در نظر بگیریم(به مورد قبلی مراجعه کنید). به این ترتیب، به سادگی با استفاده از سلکتور دیگری با همان ویژگی، می‌توانیم important! را کنار بگذاریم.

۳) import@ در CSS

@import url("font-face.css");
@import url("base.css");
@import url("utilities.css");

وقتی فایل‌های استایل را با استفاده از import at-rule@ در CSS وارد می‌کنیم، اتفاقات زیر رخ می‌دهد:

  1. فایل HTML لود می‌شود.
  2. فایل CSS لود می‌شود.
  3. import at-rule@ پیدا می‌شود و فایلی که به آن ارجاع داده شده است لود می‌شود.
  4. اگر فایل‌های استایل وارد شده حاوی import@ بیشتر باشد، این فایل‌های اضافی نیز لود می‌شوند.
  5. پس از لود شدن همه فایل‌های استایل صفحه نمایش داده می‌شود.

برای حل این مشکل چه کاری باید انجام دهیم؟

باید همیشه استفاده از تگ <link> در HTML را به استفاده از import at-rule@ ترجیح دهیم. Importهای CSS دانلودهای موازی را مسدود می‌کند. بهترین کار این است که تعداد فایل‌های استایلی که استفاده می‌کنیم را کاهش دهیم (استفاده از یک فایل واحد بهترین انتخاب است). استفاده از یک پیش‌پردازنده یا پس‌پردازشگر انجام این کار را بسیار ساده‌تر می‌کند زیرا، می‌توانیم چندین فایل استایل داشته باشیم و به راحتی آن‌ها را در یک فایل واحد با یکدیگر ترکیب کنیم. یعنی این bundle را کوچک کنیم و با استفاده از تگ <link> در فایل خود وارد کنیم.

۴) نام‌گذاری متناقض

گاهی اوقات، در یک پروژه واحد قوانینی مانند موارد زیر را می‌بینیم:

.user-panel {/*...*/}

.AlertBox {/*...*/}

.items_list {/*...*/}

این امر مخصوصاً در پروژه‌هایی که توسط چندین توسعه‌دهنده نگهداری می‌شوند رایج است، اما در کارهای انفرادی نیز اتفاق می‌افتد.

برای حل این مشکل چه کاری باید انجام دهیم؟

پروژه ما باید از یک قرارداد نام‌گذاری واحد استفاده کند. یعنی قراردادی را که هم برای ما و هم برای تیممان خوب باشد را انتخاب کنیم و به آن پای‌بند باشیم. یک گزینه خوب برای این کار BEM است، یک قرارداد نام‌گذاری آزمایش شده که هزاران تیم سال‌هاست که از آن استفاده می‌کنند.

۵) inline CSS

<div style="color: #D3D3D3; right: 0; padding: 0"></div>

امکان استفاده مجدد در برنامه‌نویسی چیز خوبی است و CSS نیز از این قاعده مستثنی نیست. با اینکه CSS یک زبان برنامه نویسی نیست اما برای کلاس‌های CSS نیز امکان استفاده مجدد درنظر گرفته شده‌ است. هنگامی که با استفاده از ویژگی style به المنتی استایل اضافه می‌کنیم، ممکن است مرتکب سه اشتباه بزرگ شویم:

  1. ترکیب کد markup و presentation
  2. جلوگیری از هرگونه امکان استفاده مجدد از کد، زیرا این ویژگی‌هایی که به‌صورت inline نوشته شده‌اند مختص آن المنت هستند
  3. استایل‌های inline دارای ویژگی‌هایی هستند که اولویت بالاتری نسبت به هر استایل خارجی دارند. فقط با استفاده از important! می‌توانیم اولویت آن‌ها را لغو کنیم و تغییر دهیم

برای حل این مشکل چه کاری باید انجام دهیم؟

راه‌حل برای این مشکل بسیار ساده است و آن این است که همیشه از کلاس‌ها استفاده کنیم.

۶) مقادیر بی معنی z-index

.sign-up-form {
  z-index: 99999;
}

بسیاری از توسعه‌دهندگان زمانی که سعی می‌کنند یک عنصر را در مقابل عناصر دیگر قرار دهند، از مقادیر بسیار بالای z-index استفاده می‌کنند. اگر این کار را انجام دهیم و شخص دیگری نیاز باشد تا عنصر دیگری را در محور Z به سمت بالا منتقل کند، در این صورت باید مقدار z-index را روی مقادیر بسیار بالاتری تنظیم کند و همین موضوع شرایط را بسیار بدتر می‌کند.

برای حل این مشکل چه کاری باید انجام دهیم؟

به جای استفاده از این مقادیر بالا، راه‌حل درست استفاده عاقلانه و متعادل از z-index است یعنی مقدار آن را تنها تا زمانی که به نتیجه مطلوب و مورد نظر خود برسیم افزایش دهیم. اگر از یک پیش‌پردازنده مانند Sass یا Stylus استفاده می‌کنیم، راه‌های هوشمندانه‌تری برای مدیریت لایه‌های z-index در برنامه ما وجود دارد که می‌توانیم از آن‌ها بهره‌مند شویم.

۷) استفاده از سلکتورهای ID به جای کلاس‌ها

در بخش‌های قبلی به این نکته اشاره کردیم و دوباره می‌گوییم استفاده مجدد یک امکان بسیار خوب است اما IDها این قابلیت را ندارند. یعنی این که یک ID می‌تواند تنها توسط یک المنت در یک صفحه استفاده شود. علاوه بر این، IDها ویژگی اختصاصی بودن سلکتور را به گونه‌ای افزایش می‌دهند که تنها در این موارد می‌توان آن را نادیده گرفت:

  1. استفاده از یک سلکتور دیگر برای انتخاب همان ID یکسان
  2. با استفاده از important!
  3. استفاده از استایل inline

برای حل این مشکل چه کاری باید انجام دهیم؟

نباید از IDها برای استایل‌دهی استفاده کنیم. تنها استثنایی که وجود دارد، استایل دادن به برخی از صفحات یا کامپوننت‌ها است که نشانه‌گذاری آن‌ها تحت کنترل ما نیست. در چنین شرایطی اگر تنها چیزی که می‌توانیم به کمک آن به یک المنت خاص ارجاع دهید ID آن باشد، پس در این صورت بهتر است همین کار را انجام دهیم اما برای موقعیت‌های دیگر، از کلاس‌های CSS استفاده کنیم.

۸) نام‌گذاری کلاس‌ها به شکل عمومی

تعریف کلاس‌ها با نام‌های خیلی عمومی نیز می‌تواند مشکل‌ساز باشد. برای مثال، با نام‌هایی مانند card، .panel ،.box. و یا grid. هر لحظه این احتمال وجود دارد که تداخلی رخ دهد و مشکلی به وجود بیاید، به خصوص اگر فایل استایل third-party را در برنامه خود import کرده باشیم.

برای حل این مشکل چه کاری باید انجام دهیم؟

اگر بخواهیم نام کلاس‌های خود را کوتاه نگه داریم، اضافه کردن یک پیشوند (مانند be-card. یا zo-grid.) می‌تواند راه‌حل خوبی باشد. همچنین mangling نام نیز یک راه‌ دیگر برای حل این مشکل است. برای مثال، با استفاده از ماژول‌های CSS، فایل‌های استایل ما محدوده‌بندی می‌شوند و نام کلاس‌ها به‌طور خودکار تنظیم می‌شوند.

جمع‌بندی

در دوره آموزش CSS فرانت کست تمامی مفاهیم به شکل عمیق مورد بررسی قرار گرفته‌ است. همچنین اگر این مقاله برای شما مفید بود آن را با دوستان خود هم به اشتراک بگذارید.