واحدهای اندازه‌گیری CSS: چرا سایت شما با هر زوم کاربر به‌هم می‌ریزد؟

یادم می‌آید در یک پروژه‌ی شرکتی، کاربری با ضعف بینایی از مدیرعامل شکایت کرده بود که «وقتی فونت مرورگر را بزرگ می‌کنم، سایت به‌هم می‌ریزد.» تیم فنی اول فکر کرد مشکل از کاربر است، اما وقتی در جلسه‌ی بازبینی، توسعه‌دهنده‌ی ارشد با زوم ۲۰۰٪ سایت را باز کرد، همه ساکت شدند: کل چیدمان به‌هم ریخته بود، دکمه‌ها از کادر بیرون زده بودند و متن‌ها روی هم افتاده بودند. علت ساده بود اما عمیق: تمام اندازه‌ها با پیکسل ثابت (pixel) تعریف شده بودند و هیچ‌کدام به اندازه‌ی فونت کاربر احترام نمی‌گذاشتند. آن روز، واحدهای اندازه‌گیری CSS از یک جزئیات فنی به یک تصمیم معماری تبدیل شد که در تمام پروژه‌های بعدی، جدی گرفتم.

CSS برای اندازه‌گیری، ده‌ها واحد (unit) مختلف در اختیار شما می‌گذارد: از px و % گرفته تا rem، em، vw، vh، ch، fr، و نسل جدیدی مثل dvh، svh و lvh. اگر در مسیر آموزش CSS از صفر هستید، این مرحله دقیقاً همان‌جایی است که کد شما از «کار می‌کند» به «در برابر کاربر واقعی مقاوم است» می‌رسد.

چرا انتخاب واحد اندازه‌گیری، یک تصمیم معماری است؟

در روزهای اول کار، فکر می‌کردم واحدها یک جزئیات سلیقه‌ای‌اند؛ می‌شد همه‌جا از پیکسل استفاده کرد و کار راه افتاد. اما در پروژه‌های واقعی، تجربه‌ی متفاوتی به من نشان داد. سه اتفاق تکراری که ریشه‌ی همه‌شان در انتخاب نادرست واحد بود:

• شکستن چیدمان با زوم کاربر: وقتی کاربر با ضعف بینایی، فونت مرورگر را بزرگ می‌کند، اگر عرض کارت‌ها یا فاصله‌ها پیکسل ثابت باشند، همه‌چیز از کادر بیرون می‌زند.
• ناپایداری در موبایل و دسکتاپ: یک فاصله‌ی ۲۴ پیکسلی در دسکتاپ کوچک و در موبایل بزرگ به‌نظر می‌رسد. اندازه‌های نسبی، این ناهماهنگی را خودکار حل می‌کنند.
• مشکل در قالب‌های آماده: وقتی می‌خواهید قالب یا تم را برای برند مشتری رنگ‌آمیزی و تنظیم کنید، اگر همه‌ی اندازه‌ها پیکسلی باشند، هر تغییر یک جستجو و جایگزینی سراسری لازم دارد؛ در حالی که با rem، کافی است فونت ریشه را تغییر دهید.

در ده‌ها پروژه‌ای که بازبینی کرده‌ام، تفاوت بین یک قالب باکیفیت و یک قالب آماتور، معمولاً در همین جزئیات دیده می‌شود: قالب‌های حرفه‌ای، از سیستم واحدهای نسبی استفاده می‌کنند؛ قالب‌های قدیمی، همه‌جا پیکسل. اگر می‌خواهید جایگاه این بحث را در نقشه‌ی کل ببینید، CSS مدرن از Flexbox تا Grid تصویر وسیع‌تری می‌دهد.

انتخاب واحد، انتخاب آینده‌ی سایت شماست: با پیکسل، برای یک مرورگر خاص طراحی می‌کنید؛ با واحدهای نسبی، برای هر کاربری که فردا سایت را باز می‌کند.

واحدهای مطلق: px و هم‌خانواده‌های فراموش‌شده

px پرکاربردترین واحد CSS است. مزیتش واضح است: قابل پیش‌بینی، ساده و بی‌ابهام. اما همین قابل پیش‌بینی بودن، در پروژه‌های طولانی به یک دام تبدیل می‌شود.

در کنار px، چند واحد مطلق دیگر هم وجود دارند که به‌ندرت استفاده می‌شوند اما شناختنشان مفید است:

در پروژه‌های وب، از این هم‌خانواده‌ها فقط وقتی استفاده می‌کنم که هدف خروجی چاپ باشد — مثلاً یک فاکتور یا برچسب قابل پرینت. در رابط کاربری معمولی، جای آن‌ها نیست.

نکته‌ی مهم درباره‌ی px: در دنیای امروزی، پیکسل CSS یک واحد مطلق واقعی نیست. مرورگر آن را با در نظر گرفتن devicePixelRatio دستگاه کاربر محاسبه می‌کند. این یعنی ۱۰۰ پیکسل CSS روی یک نمایشگر ۱x و یک نمایشگر ۲x به‌طور فیزیکی متفاوت است اما در محاسبات CSS ثابت در نظر گرفته می‌شود. همین رفتار باعث می‌شود که استفاده‌ی خالص از px برای همه‌چیز، در عمل به یک چیدمان شکننده در برابر زوم کاربر منجر شود.

em و rem: تفاوت بنیادی که خیلی‌ها اشتباه می‌گیرند

دو واحد پرکاربرد نسبی که بیشترین سردرگمی را در پروژه‌ها ایجاد می‌کنند، em و rem هستند. تفاوت در یک جمله: rem به فونت ریشه وابسته است، em به فونت همان عنصر.

:root {
  font-size: 16px; /* font ریشه */
}

.card {
  font-size: 20px;
  padding: 1rem;    /* = 16px چون به root وابسته */
  margin: 1em;      /* = 20px چون به font خود card وابسته */
}

تفاوت عملی این دو در پروژه‌ها:

• rem پیش‌بینی‌پذیر است: همیشه می‌دانید ۱ رم در کل سایت چه اندازه‌ای دارد. برای فاصله‌گذاری، اندازه‌ی فونت و ارتفاع خط، از rem استفاده می‌کنم.
• em انعطاف‌پذیر اما تله‌ساز است: اگر روی عنصری font-size را تغییر دهید، تمام مقادیر em داخل آن هم به‌طور خودکار بزرگ‌تر می‌شوند. این رفتار در بعضی موارد مفید است (مثلاً کامپوننتی که باید با نسبت‌های خودش بزرگ شود) اما در اکثر پروژه‌ها، منجر به پیچیدگی و باگ می‌شود.

دو الگوی واقعی که در پروژه‌ها به‌کار می‌برم:

/* الگو ۱: کامپوننت نسبی با em */
.button {
  font-size: 16px;
  padding: 0.75em 1.5em; /* padding نسبت به font خود دکمه */
}

.button--large {
  font-size: 20px; /* padding خودکار بزرگ‌تر می‌شود */
}

/* الگو ۲: فاصله‌گذاری سراسری با rem */
.section {
  padding-block: 2rem;
  margin-block-end: 3rem;
}

الگوی اول در سیستم‌های کامپوننت‌محور (مثل طراحی دکمه‌ها و بج‌ها) جای بسیار مناسبی دارد. الگوی دوم برای چیدمان کلی صفحه، استاندارد من است. اگر در مسیر فلکس باکس در CSS و گرید در CSS هستید، این دو الگو، همراه همیشگی چیدمان شما خواهند بود.

قاعده‌ی سرانگشتی من: چیدمان با rem، رفتار داخلی کامپوننت با em. اگر نمی‌دانید کدام را انتخاب کنید، rem انتخاب امن است.

درصد (%): نسبیت در چیدمان و font-size

درصد یکی از قدیمی‌ترین واحدهای نسبی CSS است و رفتارش کاملاً به خاصیتی که در آن استفاده می‌شود بستگی دارد. این یکی از پرتکرارترین منشأهای سردرگمی در پروژه‌های تازه‌کار است:

• width و height: نسبت به ابعاد والد محاسبه می‌شود.
• padding و margin: همیشه نسبت به عرض والد، حتی padding-top و margin-bottom. این یکی از عجیب‌ترین رفتارهای CSS است.
• font-size: نسبت به font-size والد محاسبه می‌شود — نه به font ریشه.
• line-height: اگر به‌صورت درصد باشد، نسبت به font-size خود عنصر است.

یک دام کلاسیک که در پروژه‌ها زیاد دیده‌ام: تعریف padding با درصد، با این تصور که نسبت به ارتفاع عنصر محاسبه می‌شود. مثال:

.banner {
  width: 800px;
  height: 400px;
  padding: 10% 0; /* = 80px بالا و پایین، نه 40px */
}

چون عرض والد ۸۰۰ پیکسل است، ۱۰٪ آن می‌شود ۸۰ پیکسل، و همین مقدار برای padding-top و padding-bottom استفاده می‌شود. این رفتار عجیب، در پروژه‌های چیدمان‌محور می‌تواند منشأ باگ‌های بصری ظریف باشد.

درصد در چیدمان، به‌خصوص برای عرض‌های نسبی، ارزش خودش را دارد. اما در اکثر موارد، انتخاب مدرن‌تر fr در Grid یا استفاده از flex-basis در Flexbox است. برای درک دقیق این جایگزینی، به گرید در CSS و فلکس باکس در CSS سر بزنید.

واحدهای مبتنی بر ویوپورت: vw، vh و dvh جدید

واحدهای ویوپورت (viewport units) نسبت به عرض یا ارتفاع ویوپورت محاسبه می‌شوند:

• vw — ۱٪ عرض ویوپورت.
• vh — ۱٪ ارتفاع ویوپورت.
• vmin — ۱٪ از کوچک‌ترین بُعد (عرض یا ارتفاع).
• vmax — ۱٪ از بزرگ‌ترین بُعد.

کاربرد اصلی این واحدها در ساخت بخش‌های تمام‌صفحه (full-screen sections) یا المان‌هایی است که باید نسبت مشخصی از ویوپورت را بگیرند. اما یک تله‌ی بزرگ که در موبایل ظاهر می‌شود:

در مرورگرهای موبایل، نوار آدرس در ابتدای بارگذاری نمایش داده می‌شود و هنگام اسکرول کوچک می‌شود. اگر از 100vh استفاده کنید، مرورگر ارتفاع کامل ویوپورت را در نظر می‌گیرد، اما بعد از کوچک شدن نوار آدرس، عنصر شما بلندتر از فضای واقعی می‌شود و کاربر مجبور می‌شود برای دیدن پایین عنصر اسکرول کند. این یک باگ معروف بود که سال‌ها در پروژه‌ها دیده می‌شد.

راه‌حل مدرن: واحدهای جدید dvh (dynamic viewport height)، svh (small viewport height) و lvh (large viewport height):

/* کلاسیک، مشکل‌دار در موبایل */
.hero {
  min-height: 100vh;
}

/* مدرن، سازگار با نوار آدرس متغیر */
.hero {
  min-height: 100dvh;
}

تفاوت این سه:

• svh — ارتفاع ویوپورت در حالت کوچک (نوار آدرس باز).
• lvh — ارتفاع ویوپورت در حالت بزرگ (نوار آدرس بسته).
• dvh — ارتفاع پویا که با تغییر نوار آدرس به‌روز می‌شود.

در پروژه‌های اخیرم، برای هر چیزی که تجربه‌ی تمام‌صفحه داشته، از dvh استفاده می‌کنم. برای مطالعه‌ی این که این واحدها چطور با ریسپانسیو کار می‌کنند، ریسپانسیو با CSS و مدیا کوئری در CSS را در کنار این بخش ببینید.

ch، ex و واحدهای وابسته به فونت

دو واحد کم‌شناخته‌شده که در پروژه‌های معمولی هم کاربردهای خوبی دارند:

• ch: عرض کاراکتر «0» در فونت فعلی. برای عرض متن‌محور استفاده می‌شود.
• ex: ارتفاع کاراکتر x در فونت فعلی. تقریباً هیچ‌وقت به‌تنهایی استفاده نمی‌کنم.

کاربرد طلایی ch که در پروژه‌ها زیاد از آن استفاده کرده‌ام، عرض بهینه‌ی ستون متن است:

.article {
  max-width: 70ch;
}

مطالعات خوانایی نشان می‌دهند که طول ایده‌آل یک خط برای خواندن، بین ۵۰ تا ۷۵ کاراکتر است. با 70ch، عرض ستون شما همیشه در این بازه می‌ماند، صرف‌نظر از فونت یا سایز. این یکی از تمیزترین راه‌حل‌هایی است که در پروژه‌های محتوایی استفاده کرده‌ام. اگر روی سایت‌های محتوایی یا تایپوگرافی در طراحی وب کار می‌کنید، این یک تصمیم کوچک با اثر بزرگ است.

واحد fr و دنیای Grid

fr یک واحد منحصربه‌فرد در CSS Grid است که سهمی از فضای آزاد را توصیف می‌کند:

.layout {
  display: grid;
  grid-template-columns: 250px 1fr 2fr;
}

در این مثال، ستون اول ثابت ۲۵۰ پیکسل، بقیه‌ی فضا به نسبت ۱ و ۲ بین دو ستون دیگر تقسیم می‌شود. مزیت اصلی fr در مقایسه با درصد:

• فضای آزاد باقیمانده را تقسیم می‌کند، نه کل عرض را.
• با gap ترکیب می‌شود بدون نیاز به محاسبه‌ی دستی.
• در minmax() رفتار انعطاف‌پذیری دارد که در درصد ممکن نیست.

جزئیات کامل این واحد و کاربردهایش در گرید در CSS آمده. اما نکته‌ی مهم: fr فقط در context گرید معنی دارد؛ نمی‌توانید از آن در عرض‌ها یا ارتفاع‌های معمولی استفاده کنید.

توابع clamp، min و max و اندازه‌گیری هوشمند

سه تابع که در CSS مدرن تحولی واقعی ایجاد کرده‌اند:

clamp()

h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

یک مقدار با حد پایین، حد بالا و یک مقدار ترجیحی. این یک خط، تیتر شما را در هر عرضی به‌طور هوشمند مقیاس‌پذیر می‌کند. جایگزین چند media query می‌شود.

min() و max()

.container {
  width: min(90%, 1200px);
}

.sidebar {
  width: max(250px, 20%);
}

min() کوچک‌ترین مقدار را برمی‌گرداند و max() بزرگ‌ترین. این توابع، جایگزین محاسبات پیچیده یا media queryهای ساده هستند.

ترکیب این توابع با واحدهای نسبی، در پروژه‌های اخیر، حجم CSS را محسوس کاهش داده است. اگر روی پروژه‌ای کار می‌کنید که در آن ترفندهای CSS برای طراحی سریع‌تر را به‌کار می‌برید، این توابع باید در ابزار استاندارد شما باشند.

تصمیم‌نامه‌ی انتخاب واحد برای هر موقعیت

بعد از سال‌ها کار روی پروژه‌های مختلف، به یک نقشه‌ی ذهنی رسیده‌ام که در جدول زیر خلاصه‌اش می‌کنم:

استفاده از این جدول در پروژه‌ها، به‌طور محسوسی حجم CSS را کاهش می‌دهد و نگهداری را ساده‌تر می‌کند.

اشتباهاتی که در پروژه‌ها دیدم

• استفاده‌ی خالص از px برای همه‌چیز: شایع‌ترین خطایی که در قالب‌های قدیمی وردپرسی می‌بینم. نتیجه: سایت با زوم کاربر به‌هم می‌ریزد و در موبایل ناهماهنگ به‌نظر می‌رسد.
• استفاده‌ی نابجا از vw برای فونت: font-size: 4vw باعث می‌شود در نمایشگرهای بزرگ، متن به‌طور غیرقابل‌خواندن بزرگ شود. راه‌حل: ترکیب با clamp() یا استفاده از rem در کنار media query.
• پیکسل روی فونت ریشه: تعریف :root { font-size: 16px; } و فراموش‌کردن اینکه کاربر می‌تواند این مقدار را در تنظیمات مرورگر تغییر دهد. برای دسترس‌پذیری، بهتر است فونت ریشه را به 100% یا 1rem تنظیم کنید و در صورت نیاز، از clamp() استفاده کنید.
• ترکیب بی‌دلیل em و rem: در پروژه‌ای که بازبینی کردم، چهار کامپوننت مختلف از دو واحد متفاوت برای فاصله‌گذاری استفاده می‌کردند. نتیجه، ناهماهنگی بصری ظریف اما محسوس. راه‌حل: یک رویکرد در پروژه، مستندات در تیم.
• نادیده گرفتن dvh در پروژه‌های موبایل‌محور: بخش‌های تمام‌صفحه با 100vh، در موبایل مشکل ایجاد می‌کنند. این یک باگ واقعی است که تا کاربر روی دستگاه واقعی تست نکنید، در DevTools دیده نمی‌شود.

بخشی از این اشتباهات در اشتباهات رایج طراحی ریسپانسیو هم آمده است.

تست واحدها در شرایط واقعی

سه ابزار و روش که در پروژه‌ها به‌کار می‌برم:

1. تست زوم مرورگر: سایت را با زوم ۲۰۰٪ باز کنید. اگر چیدمان به‌هم ریخت، معنی‌اش این است که واحدهای انتخابی شما به تنظیمات کاربر احترام نمی‌گذارند. این یک تست سه‌دقیقه‌ای است که اکثر باگ‌های واحدها را کشف می‌کند.
2. تست روی دستگاه واقعی با نوار آدرس موبایل: بخش‌های تمام‌صفحه را روی گوشی خودتان باز کنید و ببینید آیا با ظاهر و ناپدید شدن نوار آدرس، مشکل بصری ایجاد می‌شود. اگر بله، احتمالاً 100vh جایگزین 100dvh نشده است.
3. تست فونت‌های جایگزین: در DevTools، فونت سایت را به یک فونت دیگر تغییر دهید و ببینید چیدمان چقدر تغییر می‌کند. اگر تغییرات محسوس هستند، احتمالاً خیلی از مقادیر شما با ch یا em جایگزین‌پذیرند.

روش کامل تست در تست چیدمان واکنش‌گرا در مرورگرها آمده است. اگر روی وردپرس هستید و می‌خواهید این تست‌ها را در قالب خودتان اجرا کنید، ریسپانسیو کردن سایت گام‌به‌گام راهنماست.

لایه‌ای زیر سینتکس: موتور رندر و واحدها

اینجا وارد لایه‌ای می‌شوم که در پروژه‌های معمولی به آن نگاه نمی‌شود اما برای مهندسان پلتفرم و توسعه‌دهنده‌های ارشد اهمیت دارد. آنچه موتور رندر با واحدهای CSS شما می‌کند، در چهار مفهوم خلاصه می‌شود:

1. Computed Value و Relative Resolution در زمان Layout: واحدهای نسبی مثل %، em، vw و ch در لحظه‌ی استفاده از خاصیت resolve می‌شوند، نه در لحظه‌ی parse. یعنی هر بار که layout از نو محاسبه می‌شود، موتور باید مقادیر نسبی را با توجه به context فعلی دوباره محاسبه کند. در درخت‌های بزرگ DOM، این محاسبه‌ی مکرر می‌تواند هزینه‌ی قابل توجهی داشته باشد، به‌خصوص وقتی از em در چند لایه استفاده شده باشد چون هر لایه به لایه‌ی والد وابسته است و کل زنجیره باید حل شود.
2. ترتیب حل واحدها در Cascade: وقتی یک خاصیت با واحد نسبی مقدار می‌گیرد، موتور رندر ابتدا مقدار والد را resolve می‌کند، سپس مقدار خود عنصر را. اگر این والدین هم نسبی باشند، زنجیره‌ای از محاسبات شکل می‌گیرد. این توضیح می‌دهد چرا استفاده‌ی عمیق از em در پروژه‌های بزرگ می‌تواند بهره‌وری را پایین بیاورد: هر عنصر، هزینه‌ی محاسباتی والدین خودش را هم می‌پردازد. راه‌حل عملی: در لایه‌های پایه‌ی ساختار، از rem استفاده کنید که فقط به یک نقطه وابسته است.
3. Re-layout و Effect on Viewport Units: واحدهای ویوپورت (vw, vh, dvh) هر بار که ابعاد ویوپورت تغییر می‌کند، بازارزیابی می‌شوند. در دستگاه‌های موبایل، هر بار که نوار آدرس ظاهر یا ناپدید می‌شود، ویوپورت تغییر می‌کند و در نتیجه تمام عناصری که از واحدهای ویوپورت استفاده می‌کنند، نیاز به بازچینش دارند. اگر در صفحه‌ای تعداد زیادی عنصر با vh یا vw داشته باشید، این تغییرات مکرر در زمان اسکرول می‌تواند به jank (پرش بصری) منجر شود. واحد dvh اگرچه مشکل بصری را حل می‌کند، اما خودش به‌طور مداوم به‌روز می‌شود و هزینه‌ی محاسباتی دارد. توصیه‌ی من: در پروژه‌های پرمحتوا، محدوده‌ی استفاده از واحدهای ویوپورت را محدود کنید.
4. Interaction با clamp() و Layout Thrashing: تابع clamp() اگرچه بسیار مفید است، اما وقتی در آن از واحدهای ویوپورت استفاده شود (clamp(1rem, 4vw, 3rem))، در هر تغییر اندازه‌ی ویوپورت، دوباره محاسبه می‌شود. این یعنی عنصر شما در هر resize یک هزینه‌ی محاسباتی جدید دارد. در پروژه‌های معمولی این هزینه ناچیز است، اما در پروژه‌های بزرگ با تعداد زیادی عنصر که از clamp با vw استفاده می‌کنند، می‌تواند در پروفایلر دیده شود. برای مطالعه‌ی موازی این لایه با کارایی کلی، بهینه‌سازی CSS و بهینه‌سازی سرعت سایت را ببینید.

یک تجربه‌ی واقعی از پروژه‌ای که با مشکل re-layout مواجه شدیم: در یک لندینگ با بخش‌های تمام‌صفحه‌ی متعدد که هر کدام از min-height: 100vh استفاده می‌کردند، در دستگاه‌های موبایل با نوار آدرس پویا، هر بار که کاربر اسکرول می‌کرد، مرورگر مجبور بود تمام این بخش‌ها را بازارزیابی کند. نتیجه، پرش‌های بصری محسوس و در بعضی موارد، ظاهر شدن اسکرول‌بار نامناسب. با جایگزینی 100vh به 100dvh، رفتار بصری پایدار شد؛ اما در پروفایلر، ما دیدیم که هزینه‌ی محاسباتی در هر اسکرول اندکی بالا رفت. راه‌حل نهایی: ترکیب min-height: 100svh (ارتفاع کوچک که تغییر نمی‌کند) با یک @supports برای پشتیبانی از dvh در مرورگرهای مدرن. این رویکرد، هم رفتار پایدار و هم هزینه‌ی محاسباتی بهینه را تضمین کرد.

اگر روی پروژه‌های وردپرسی هستید و قالب شما از واحدهای سنگین مثل vw در تایپوگرافی سراسری استفاده می‌کند، پیشنهاد می‌کنم دلایل کندی قالب را هم در کنار این بخش بخوانید؛ چون مهاجرت به قالب سبک، بستر بهتری برای اعمال این تصمیم‌ها فراهم می‌کند. برای درک این لایه در چارچوب استانداردهای وب، استانداردهای HTML و CSS و CSS مدرن از Flexbox تا Grid دید وسیع‌تری می‌دهند. اگر با موضوع دسترس‌پذیری و انتخاب واحدهای سازگار با کاربر هم درگیر هستید، استانداردهای دسترس‌پذیری وب و WCAG چیست نقطه‌ی شروع مناسبی است.

انتخاب واحد اندازه‌گیری، سه اثر هم‌زمان دارد: ظاهر، دسترس‌پذیری و کارایی. تصمیمی که فقط بر اساس یکی از این سه گرفته شود، در دو مورد دیگر می‌بازد.

سخن پایانی این مسیر

واحدهای اندازه‌گیری را می‌توان در یک جمله خلاصه کرد: «ابزاری برای توصیف نسبت‌ها، نه فقط طول‌ها.» سه درس که از این مسیر با خودم بردم:

1. برای چیدمان، نسبی فکر کنید. اکثر نیازهای چیدمان با rem، %، fr و clamp() حل می‌شوند. پیکسل را برای تزئینات و حاشیه‌های کوچک نگه دارید.
2. به تنظیمات کاربر احترام بگذارید. اگر تمام اندازه‌های فونت شما rem باشند، کاربر می‌تواند با بزرگ کردن فونت مرورگر، سایت را برای خودش قابل استفاده کند. این یک الزام دسترس‌پذیری است، نه یک لوکس.
3. در موبایل، از dvh غافل نشوید. تفاوت بین 100vh و 100dvh در DevTools دیده نمی‌شود اما روی گوشی واقعی، تجربه‌ی کاربری را به‌طور محسوس تغییر می‌دهد.

مسیر یادگیری CSS با این نوشته تمام نمی‌شود. اگر می‌خواهید مرحله‌ی بعدی را بردارید، متغیرهای CSS، مدیا کوئری در CSS و ترنزیشن در CSS سه قدم منطقی بعدی هستند. اگر هم به سمت طراحی می‌روید، اصول تایپوگرافی در طراحی وب و بهترین فونت‌های فارسی برای وب دید وسیع‌تری می‌دهند.

اگر در پروژه‌ای با یک باگ عجیب مرتبط با واحدها روبرو شده‌اید — مثلاً عنصری که فقط در گوشی‌های خاصی از کادر بیرون می‌زند، یا متن‌هایی که با زوم کاربر روی هم می‌افتند — جزئیات سناریو را در دیدگاه بنویسید. مخصوصاً اگر با ترکیب clamp() و dvh به یک الگوی پایدار رسیده‌اید، همان تجربه برای خواننده‌ی بعدی از هر توضیح کلی ارزشمندتر است. 📐