مدیا کوئری در CSS: چرا breakpointهای شما اشتباه انتخاب شده‌اند؟

یک بار در یک پروژه‌ی بازطراحی، بعد از سه هفته کار روی بخش ریسپانسیو، مدیر پروژه پرسید «چرا این سایت روی آیفون ۱۲ درست است اما روی گوشی سامسونگ گلکسی به‌هم می‌ریزد؟» هر دو دستگاه حدوداً هم‌عرض بودند. آن شب با نگاهی به فایل CSS و DevTools، فهمیدم مشکل نه در Flexbox بود، نه در Grid، نه در واحدهای اندازه‌گیری؛ مشکل در انتخاب breakpointها بود. بعضی از آن‌ها روی عرض‌های عجیب مثل ۷۶۷ پیکسل و ۱۰۲۵ پیکسل تنظیم شده بودند که روی دستگاه‌های واقعی، درست در لبه‌ی شکستن قرار می‌گرفتند. آن تجربه، برای همیشه نگاهم به مدیا کوئری در CSS را عوض کرد: media query ابزاری نیست که «انجامش دهیم»؛ تصمیمی است که باید آگاهانه گرفته شود.

Media Query که با نام CSS Media Queries هم شناخته می‌شود، یکی از پایه‌ای‌ترین ابزارهای ریسپانسیو است. اگر در مسیر آموزش CSS از صفر هستید و ریسپانسیو با CSS را خوانده‌اید، این نوشته مرحله‌ی بعدی و ضروری شماست؛ چون در آن مقاله چیدمان را با جریان محتوا حل کردیم و در این نوشته، دقیقاً به جایی می‌رسیم که جریان به‌تنهایی کافی نیست.

چرا بعضی media queryها کار نمی‌کنند؟

در طول بازبینی ده‌ها پروژه، دیدم که media queryها معمولاً به یکی از این چهار دلیل شکست می‌خورند:

نبود تگ viewport در HTML: اگر تگ <meta name="viewport"> نباشد، media query روی موبایل به‌طور غیرمنتظره رفتار می‌کند، چون مرورگر عرض ویوپورت مجازی ۹۸۰ پیکسل را فرض می‌گیرد. تشخیص این خطا در نگاه اول سخت است چون در دسکتاپ همه‌چیز درست به‌نظر می‌رسد.
ترتیب نامناسب قواعد: اگر @media (max-width: 768px) قبل از @media (max-width: 480px) نوشته شود، در عرض‌های کوچک، هر دو اجرا می‌شوند و قاعده‌ی آخر برنده می‌شود. رویکرد درست: همیشه با min-width صعودی کار کنید یا با max-width نزولی.
مقدار breakpoint در لبه‌ی دقیق: اگر breakpoint را روی ۷۶۸ پیکسل بگذارید و کاربری با عرض ۷۶۸.۵ پیکسل داشته باشید، در حالت‌های عجیب گیر می‌افتد. مقادیر استاندارد (مثلاً ۷۶۷.۹۸) این مشکل را حل می‌کنند.
تداخل با انتخابگرهای دیگر: اگر media query شما یک خاصیت را عوض می‌کند اما انتخابگری با specificity بالاتر آن را در جای دیگری بازنویسی می‌کند، نتیجه اعمال نمی‌شود. حل این مورد در انتخابگرهای CSS توضیح داده شده است.

تجربه‌ام می‌گوید اولین سؤالی که در دیباگ ریسپانسیو باید بپرسید این نیست که «کدام media query کار می‌کند؟»، بلکه «کدام media query اصلاً وارد جریان نمی‌شود و چرا؟».

media query در CSS یک تصمیم یک‌بار برای همیشه نیست؛ یک گفت‌وگوی مداوم بین محتوا و عرض ویوپورت است.

سینتکس پایه: از max-width تا min-width

سینتکس media query ساده است اما همین سادگی، جای بیشترین اشتباهات در پروژه‌هاست. ساختار پایه:

@media (max-width: 768px) {
  .sidebar {
    display: none;
  }
}

سه نکته که در روزهای اول کارم زمان زیادی از من گرفت:

فاصله‌ی بین @media و پرانتز ضروری است. یک اشتباه تایپی ساده، قاعده را کاملاً نادیده می‌گیرد و هیچ خطایی هم نمایش داده نمی‌شود. مرورگر بی‌سروصدا آن را رد می‌کند.
مقدار بدون واحد، بی‌معنی است. max-width: 768 کار نمی‌کند؛ باید 768px باشد. این اشتباه در کدهایی که از JS تولید می‌شوند بیشتر دیده می‌شود.
نوع media در نسخه‌های مدرن معمولاً حذف می‌شود. در گذشته @media screen and (max-width: 768px) می‌نوشتیم، اما امروز فقط @media (max-width: 768px) کافی است چون پیش‌فرض برای همه‌ی صفحه‌ها اعمال می‌شود.

اگر با ساختار کلی CSS آشنایی ندارید، پیشنهاد می‌کنم ابتدا استانداردهای HTML و CSS را مرور کنید تا بتوانید ارتباط تگ‌ها و media query را بهتر درک کنید.

Mobile-First یا Desktop-First؛ تصمیمی که همه چیز را عوض می‌کند

دو رویکرد برای نوشتن media query وجود دارد و انتخاب بین آن‌ها، یک تصمیم معماری است که در بلندمدت روی ساختار کل پروژه اثر می‌گذارد:

معیار	Mobile-First	Desktop-First
سینتکس	`min-width`	`max-width`
نقطه‌ی شروع طراحی	موبایل، ساده‌ترین حالت	دسکتاپ، کامل‌ترین حالت
حجم CSS پایه	کم، لایه‌های بعدی روی آن می‌آیند	زیاد، لایه‌های بعدی چیزی حذف می‌کنند
تعامل با محتوای جدید	ساده‌تر، چون پایه سبک است	پیچیده‌تر، چون هر تغییر ممکن است به همه‌ی breakpointها اثر بگذارد
هم‌راستایی با ترافیک واقعی	بیشتر، چون اکثر کاربران موبایل‌اند	کمتر، مگر سایت‌های B2B خاص
نگهداری در بلندمدت	پایدارتر	شکننده‌تر

در ده‌ها پروژه‌ای که اخیراً بازبینی کرده‌ام، پروژه‌هایی که با Mobile-First نوشته شده بودند، در حالت تغییر و نگهداری پایدارتر بودند. تجربه‌ی من: اگر قرار است در پروژه‌ای انتخاب کنید، Mobile-First را جدی بگیرید، حتی اگر طراحی مرجع روی دسکتاپ انجام می‌شود. دلیلش ساده است: هر چیزی که در موبایل طراحی می‌شود، در دسکتاپ به‌سادگی بزرگ‌تر می‌شود؛ اما هر چیزی که در دسکتاپ طراحی می‌شود، در موبایل به‌سختی کوچک می‌شود.

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

/* Mobile-First */
.card { padding: 1rem; }

@media (min-width: 768px) {
  .card { padding: 2rem; }
}

@media (min-width: 1200px) {
  .card { padding: 3rem; }
}

این ساختار به‌طور طبیعی با Mobile-First هم‌راستاست: هر بخش، فقط وقتی لازم است، اضافه می‌شود.

انتخاب breakpoint: نه بر اساس دستگاه، بر اساس محتوا

بزرگ‌ترین سوءتفاهم درباره‌ی media query این است که باید برای هر دستگاه یک breakpoint تعریف کرد. این رویکرد در ابتدا شهودی به‌نظر می‌رسد، اما بعد از مدتی به یک کابوس نگهداری تبدیل می‌شود. تجربه‌ی من: breakpointها باید بر اساس محتوا تعیین شوند، نه بر اساس دستگاه.

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

مرورگر را باز کنید و عرض پنجره را از پایین به بالا تغییر دهید.
نقطه‌ای که چیدمان شروع به زشت شدن می‌کند را پیدا کنید.
همان نقطه را به‌عنوان breakpoint ثبت کنید — نه عرض iPhone یا iPad.

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

Breakpoint	مرجع	کاربرد
`480px`	موبایل بزرگ	تغییرات جزئی چیدمان موبایل
`768px`	تبلت عمودی	شروع چیدمان دوستونه
`1024px`	تبلت افقی / دسکتاپ کوچک	افزودن سایدبار یا ستون سوم
`1200px`	دسکتاپ	حداکثر عرض محتوا، فاصله‌های بزرگ‌تر

اما یک نکته‌ی مهم که در پروژه‌های تیمی به‌کار می‌برم: این مقادیر را در متغیرهای CSS نگه ندارید، چون media query در مرورگرهای امروز از متغیرهای CSS در شرط‌ها پشتیبانی نمی‌کند. به‌جایش، این مقادیر را در یک فایل مشترک Sass یا در مستندات پروژه تعریف کنید تا همه‌ی اعضای تیم یک عدد واحد استفاده کنند.

سینتکس محدوده: Media Queries مدرن

یک قابلیت جدید که مدتی است پشتیبانی مرورگرها را به‌دست آورده، سینتکس محدوده (range syntax) است. به‌جای ترکیب min-width و max-width برای محدوده‌های پیچیده، می‌توانید مستقیم از عملگرهای ریاضی استفاده کنید:

/* قبل */
@media (min-width: 768px) and (max-width: 1024px) {
  .grid { grid-template-columns: repeat(2, 1fr); }
}

/* بعد */
@media (768px <= width <= 1024px) {
  .grid { grid-template-columns: repeat(2, 1fr); }
}

سه مزیت این سینتکس که در پروژه‌ها مفید بوده:

خوانایی بالاتر: محدوده‌ها به‌طور طبیعی خوانده می‌شوند، نه با ترکیب دو شرط.
کاهش اشتباهات مرزی: دیگر نگران نیستید که یک شرط را جا بیندازید یا بازه را اشتباه تعریف کنید.
انعطاف بیشتر با عملگرهای مختلف: می‌توانید از <، >، <= و >= استفاده کنید.

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

عملگرهای منطقی: and، or، not و only

media queryها از چهار عملگر منطقی پشتیبانی می‌کنند که ترکیب شرط‌ها را ممکن می‌سازند:

and: هر دو شرط باید برقرار باشند. @media (min-width: 768px) and (orientation: landscape).
کاما (,): معادل «یا». هر شرطی که برقرار باشد اجرا می‌شود.
not: نفی کل media query. @media not all and (monochrome).
only: برای مرورگرهای بسیار قدیمی که media query را پشتیبانی نمی‌کنند، این عملگر باعث می‌شود قاعده کاملاً نادیده گرفته شود. در مرورگرهای مدرن نقش کاربردی ندارد.

در پروژه‌ها بیشتر از and و کاما استفاده می‌کنم. not کاربرد کمی دارد و بیشتر برای موارد خاص مثل احترام به تنظیمات دسترس‌پذیری سیستم کاربر استفاده می‌شود.

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

ویژگی‌های دیگر: orientation، hover، prefers-color-scheme

media query فقط محدود به width نیست. ویژگی‌های دیگری وجود دارند که در پروژه‌های واقعی کاربردی هستند:

orientation

جهت دستگاه را تشخیص می‌دهد: portrait (عمودی) یا landscape (افقی). در پروژه‌ای که یک بازی سبک با وب داشتیم، این ویژگی برای تغییر چیدمان در حالت افقی حیاتی بود. دام: در دسکتاپ، این ویژگی بیشتر بر اساس نسبت عرض به ارتفاع پنجره است، نه واقعاً جهت دستگاه.

hover و pointer

این دو ویژگی به شما می‌گویند کاربر با ماوس کار می‌کند یا با لمس:

@media (hover: hover) {
  .button:hover {
    background: #0033aa;
  }
}

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

prefers-color-scheme

تم تیره یا روشن سیستم کاربر را تشخیص می‌دهد:

@media (prefers-color-scheme: dark) {
  :root {
    --color-bg: #121212;
    --color-text: #eaeaea;
  }
}

ترکیب این ویژگی با متغیرهای CSS، تم داینامیک را در چند خط CSS پیاده می‌کند. تجربه‌ی من این است که در پروژه‌های امروز، این یک انتظار کاربری است، نه یک قابلیت لوکس.

prefers-reduced-motion

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

Container Queries و آینده‌ی ریسپانسیو

یکی از مهم‌ترین قابلیت‌های جدید در CSS، Container Queries است که در چند سال اخیر پشتیبانی مرورگرها را به‌دست آورده. تفاوت بنیادی با media query:

Media Query بر اساس عرض ویوپورت تصمیم می‌گیرد.
Container Query بر اساس عرض والد تصمیم می‌گیرد.

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

.card-wrapper {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card {
    display: flex;
    gap: 1rem;
  }
}

این الگو در پروژه‌های Component-Based بسیار کاربردی است و در آینده‌ی نزدیک جایگزین بخش زیادی از media queryهای فعلی خواهد شد. اگر با فریم‌ورک‌هایی مثل React یا Vue کار می‌کنید، ارزشش را دارد که از همین امروز با آن آشنا شوید. برای مطالعه‌ی روند کلی این تغییر، CSS مدرن از Flexbox تا Grid و ترفندهای CSS برای طراحی سریع‌تر دید وسیع‌تری می‌دهند.

الگوهای واقعی از پروژه‌ها

سه الگویی که در پروژه‌های خودم بیشترین استفاده را داشته‌اند:

تبدیل سایدبار به منوی همبرگری: در دسکتاپ سایدبار همیشه باز است؛ در تبلت به منوی همبرگری تبدیل می‌شود. breakpoint را معمولاً در ۹۹۲ یا ۱۰۲۴ پیکسل می‌گذارم — نه بر اساس دستگاه، بلکه بر اساس عرضی که در آن سایدبار بدون فشردگی محتوا جا می‌شود.
شبکه‌ی کارت‌ها با تعداد ستون متغیر: در دسکتاپ چهار کارت در ردیف، در تبلت دو، در موبایل یک. اگر از گرید در CSS استفاده می‌کنید، ترکیب auto-fit و minmax می‌تواند بسیاری از این حالت‌ها را بدون media query حل کند. media query فقط برای موارد خاص مثل تغییر ترتیب یا مخفی کردن بخشی از محتوا نگه دارید.
فرم‌های چندستونه: در دسکتاپ دو ستون، در موبایل یک ستون. با Grid، این کار در یک قاعده انجام می‌شود؛ اگر با Flexbox کار می‌کنید، نیاز به یک media query ساده دارید. جزئیات در فلکس باکس در CSS.

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

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

تعریف breakpoint برای هر دستگاه: در پروژه‌ای دیدم که برای iPhone، iPad، Galaxy و Pixel جداگانه media query نوشته شده بود. نتیجه، فایلی پر از قواعد تکراری و غیرقابل نگهداری بود. راه‌حل: بر اساس محتوا تصمیم بگیرید، نه دستگاه.
min-width و max-width در یک پروژه به‌طور تصادفی: در یک تیم دیده‌ام که یک توسعه‌دهنده با min-width می‌نوشت، یکی با max-width. نتیجه، ترتیب قواعد ناسازگار و رفتار غیرقابل پیش‌بینی. راه‌حل: یک رویکرد، یک پروژه.
تکیه بر media query به‌جای جریان محتوا: هر جا با تغییر چیدمانی مواجه می‌شوم که با جریان Flexbox یا Grid خودکار حل می‌شد، یک media query غیرضروری هست. کاهش این نوع media query، حجم CSS را به‌طور محسوس پایین می‌آورد.
نادیده گرفتن حالت Landscape موبایل: بسیاری از پروژه‌ها فقط حالت Portrait را طراحی می‌کنند و در Landscape چیدمان به‌هم می‌ریزد. اگر سایت شما در حالت افقی موبایل هم استفاده می‌شود، حتماً تست کنید.
نبود تست روی دستگاه واقعی: بعضی از media queryها فقط در شبیه‌ساز درست به‌نظر می‌رسند. تفاوت‌های کوچک در نوار آدرس موبایل، مقیاس پیکسل‌ها و رفتار مرورگرها فقط روی دستگاه واقعی معلوم می‌شود.

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

تست media query روی دستگاه واقعی

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

DevTools Responsive Mode: برای تست سریع و تنظیم breakpointها عالی است. اما شبیه‌ساز، رفتار واقعی مرورگر موبایل را کامل بازتولید نمی‌کند.
گوشی واقعی با اینترنت سلفون: استاندارد طلایی. رفتار نوار آدرس، پیکسل‌های واقعی و رفتار لمسی، همه اینجا معلوم می‌شود.
ابزارهای تست ریسپانسیو آنلاین: برای تست روی دستگاه‌هایی که در دسترس نیستند. مفید اما نباید جایگزین دستگاه واقعی شود.

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

لایه‌ای زیر سینتکس media query

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

Media Query Evaluation و ترتیب اعمال: مرورگر در هر بار تغییر اندازه‌ی ویوپورت، تمام media queryها را بازارزیابی می‌کند. یعنی هر resize یک چرخه‌ی کامل از parse، match و اجرای قواعد است. اگر تعداد media queryها بالا باشد و مرورگر برای هرکدام یک شرط منطقی پیچیده محاسبه کند، هزینه‌ی این بازارزیابی قابل اندازه‌گیری است — به‌خصوص در انیمیشن‌های resize یا تغییر جهت صفحه.
Cascade و ترتیب Source Order: وقتی دو media query روی یک عنصر اثر می‌گذارند، برنده با cascade تصمیم گرفته می‌شود که در آن source order و specificity ملاک است. به همین دلیل، ترتیب قواعد در فایل CSS معنای عملی دارد، نه فقط خوانایی. این توضیح می‌دهد چرا بعضی media queryها کار می‌کنند اما نتیجه‌ی مطلوب را نمی‌دهند: شاید یک قاعده‌ی دیگر با specificity بالاتر، آن‌ها را در لحظه‌ی اعمال بازنویسی می‌کند.
Style Recalculation Cost: هر بار که media query فعال می‌شود، مرورگر مجبور است style محاسبه‌شده‌ی تمام عناصر داخل آن را از نو بازسازی کند. اگر یک media query در سطح گسترده (مثل body) باشد و subtree بزرگی را تحت تأثیر قرار دهد، هزینه می‌تواند قابل توجه شود. در پروژه‌های با DOM بزرگ (مثل جداول دیتای سنگین یا لیست محصولات زیاد)، این هزینه در پروفایلر مرورگر به‌طور واضح دیده می‌شود.
Container Queries و Performance Model متفاوت: برخلاف media query که همگام با تغییر ویوپورت بازارزیابی می‌شود، container query بر اساس عرض والد ارزیابی می‌شود. یعنی هر تغییر در ابعاد والد، trigger می‌شود. این یک مدل Performance متفاوت است: ممکن است در پروژه‌ای با انیمیشن‌های روی اندازه، تعداد زیادی container query فعال و غیرفعال شوند که بار اضافه‌ای به موتور رندر وارد می‌کند. توصیه: برای اجزایی که انیمیشن روی اندازه دارند، از container query استفاده نکنید.
Interaction با React و Virtual DOM: در پروژه‌های React و Vue، وقتی کامپوننت‌ها بر اساس media query ظاهر یا مخفی می‌شوند، دقت کنید که وضعیت (state) کامپوننت در دو حالت حفظ می‌شود یا نه. یک الگوی رایج که در تیم‌ها دیدم: کامپوننتی که با display: none در موبایل مخفی می‌شود، state خودش را حفظ می‌کند اما منابعی مثل event listenerهای فعال را هم آزاد نمی‌کند. این تفاوت را می‌توان با v-if در Vue یا conditional rendering در React حل کرد. برای مطالعه‌ی موازی این لایه با کارایی کلی سایت، بهینه سازی جاوااسکریپت و بهینه‌سازی سرعت سایت را ببینید.

یک تجربه‌ی واقعی از پروژه‌ی داشبوردی که در آن هزینه‌ی style recalculation مسئله شد: در یک صفحه با جدول بزرگ که تعداد ردیف‌هایش به هزار می‌رسید، یک media query در سطح body تعریف شده بود که در عرض ۱۰۲۴ پیکسل، کل grid را از سه ستونه به دو ستونه تغییر می‌داد. هر بار که کاربر پنجره را کوچک و بزرگ می‌کرد، مرورگر مجبور بود تمام styleهای جدول را از نو محاسبه کند. با محدود کردن دامنه‌ی media query به container اصلی و کاهش تعداد عناصر درگیر، هزینه‌ی هر resize به‌طور محسوس کاهش پیدا کرد. اگر روی پروژه‌های وردپرسی هستید، پیشنهاد می‌کنم دلایل کندی قالب و بهینه‌سازی CSS را در کنار این بخش بخوانید. برای درک این لایه در چارچوب موتورهای مرورگر، مفاهیم پیشرفته جاوااسکریپت و استانداردهای HTML و CSS دید وسیع‌تری می‌دهند. اگر روی انتخابگرها و interaction آن‌ها با media query حساس هستید، انتخابگرهای CSS را هم ببینید.

media query که روی یک container بزرگ اعمال می‌شود، مثل بازچینش کل کتابخانه است برای جابه‌جا کردن یک کتاب؛ هزینه‌اش از سودش بیشتر است.

آخرین کلمه این مسیر

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

اول جریان، بعد media query. اگر بتوانید چیدمان خود را با Flexbox و Grid خودتنظیم بسازید، اکثر دستگاه‌ها بدون دخالت شما کار می‌کنند. media query را برای مواردی نگه دارید که جریان طبیعی جواب نمی‌دهد.
breakpointها را بر اساس محتوا انتخاب کنید، نه دستگاه. عرض دستگاه‌ها هر شش ماه عوض می‌شود اما نقاط شکستن محتوا ثابت می‌مانند. اگر بر اساس دستگاه تصمیم بگیرید، هر سال باید بازبینی کنید.
سینتکس محدوده و Container Queries را جدی بگیرید. این دو قابلیت مدرن، در آینده‌ی نزدیک بخش زیادی از media queryهای فعلی را جایگزین می‌کنند. اگر امروز با آن‌ها آشنا شوید، فردا یک قدم جلوترید.

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

اگر در پروژه‌ای با یک مشکل عجیب media query روبرو شده‌اید — مثلاً حالتی که در یک مرورگر خاص کار می‌کند و در مرورگر دیگر نه، یا رفتاری که فقط در Landscape موبایل ظاهر می‌شود — جزئیات سناریو را در دیدگاه بنویسید. مخصوصاً اگر با کاهش تعداد media queryها یا جایگزینی آن‌ها با Container Queries به نتیجه‌ای رسیده‌اید، همان تجربه برای خواننده‌ی بعدی از هر توضیح کلی ارزشمندتر است. 🧭