CSS در ۲۰۲۶؛ قابلیت‌های تازه، وضعیت استاندارد و fallback

برای پیگیری CSS در ۲۰۲۶، باید میان ایده استاندارد، پیاده‌سازی آزمایشی و قابلیت قابل استفاده برای مخاطبان سایت فرق بگذاریم. انتشار یک پیش‌نویس W3C تاریخ عرضه یکسان در همه مرورگرها نیست. وجود قابلیت در یک مرورگر هم به معنی آمادگی آن برای همه پروژه‌ها نیست. عنوان «ویژگی‌هایی که می‌آیند» اگر زمان قطعی القا کند، تصمیم توسعه را گمراه می‌کند. در این راهنما چند مسیر مهم CSS را مرور می‌کنیم و نشان می‌دهیم چگونه قابلیت تازه را با fallback و دامنه روشن وارد یک رابط واقعی کنیم.

نقشه راه واحدی برای همه مرورگرها وجود ندارد

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

معیار محصول از علاقه شخصی به syntax تازه جداست. اگر قابلیت جدید کاربر را به نتیجه سریع‌تری می‌رساند و نسخه پایه هم قابل استفاده می‌ماند، Progressive Enhancement مسیر مناسبی است. اگر نبود قابلیت کل فرم یا ناوبری را از کار می‌اندازد، به fallback جدی‌تری نیاز دارید. برای هر قابلیت بنویسید چه مشکلی را حل می‌کند و اگر پشتیبانی نشود چه اتفاقی می‌افتد. این دو جمله بحث درباره استفاده را دقیق‌تر از فهرست بلند ویژگی‌های جذاب می‌کنند.

Container Queries اجزا را از عرض صفحه مستقل‌تر می‌کنند

Media Query معمولاً به شرایط viewport نگاه می‌کند، اما یک کارت ممکن است در همان صفحه داخل ستون باریک یا بخش عریض قرار بگیرد. Container Size Query اجازه می‌دهد شکل فرزندان بر اساس اندازه container مربوط تغییر کند. راهنمای MDN این سازوکار را توضیح می‌دهد. برای component قابل استفاده در چند جای صفحه، این تغییر مهم است: تصمیم چیدمان به فضای واقعی همان جزء نزدیک‌تر می‌شود و مجبور نیستید فقط بر اساس عرض کل پنجره حدس بزنید.

Container باید روی عنصر مناسب تعریف شود. اگر wrapper کارت را container قرار می‌دهید، قاعده داخل query به فرزندان آن اعمال می‌شود؛ نباید انتظار داشته باشید اندازه خود container با همان query بدون توجه به قواعد containment تغییر کند. انتخاب wrapper و عنصر هدف بخشی از طراحی نمونه است. در مقاله Grid و Flexbox می‌توان درباره چیدمان داخلی بیشتر خواند. Container Query شرط فعال‌شدن چیدمان را تعیین می‌کند و جای خود Grid یا Flexbox را نمی‌گیرد.

نمونه کامل با نسخه پایه قابل استفاده

نمونه زیر دو کارت متنی دارد و به تصویر، کتابخانه یا JavaScript وابسته نیست. فایل را با نام container-cards.html ذخیره کنید و در مرورگر باز کنید. wrapper هر کارت یک query container است و در فضای عریض‌تر، بخش توضیح و وضعیت کنار هم قرار می‌گیرند. در عرض کمتر، ساختار یک‌ستونه پایه باقی می‌ماند. متن و وضعیت حتی در نبود پشتیبانی Container Query قابل خواندن‌اند. این نمونه کاربرد یک قابلیت مشخص را نشان می‌دهد و ادعای پشتیبانی همه ویژگی‌های تازه CSS را ندارد.

<!doctype html>
<html lang="fa" dir="rtl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>کارت با Container Query</title>
  <style>
    * { box-sizing: border-box; }
    body { margin: 0; padding: 1rem; font-family: sans-serif; line-height: 1.8; color: #172333; background: #f5f7fa; }
    .board { max-width: 60rem; margin-inline: auto; display: grid; gap: 1rem; }
    .card-shell { container-type: inline-size; container-name: project; }
    .card { display: grid; gap: 1rem; padding: 1.25rem; background: white; border: 1px solid #c8d2df; border-radius: .75rem; }
    .card h2, .card p { margin: 0; }
    .status { align-self: start; padding: .25rem .75rem; background: #e6f4e9; color: #205a31; border-radius: .5rem; }
    @container project (min-width: 28rem) {
      .card { grid-template-columns: minmax(0, 1fr) auto; align-items: start; }
    }
  </style>
</head>
<body>
  <main class="board">
    <h1>پروژه‌ها</h1>
    <div class="card-shell">
      <article class="card">
        <div><h2>بازطراحی فرم درخواست</h2><p>متن خطاها و ترتیب فیلدها در حال بررسی است.</p></div>
        <span class="status">در حال انجام</span>
      </article>
    </div>
    <div class="card-shell">
      <article class="card">
        <div><h2>راهنمای انتخاب محصول</h2><p>نسخه نخست راهنما برای بازبینی آماده است.</p></div>
        <span class="status">آماده بازبینی</span>
      </article>
    </div>
  </main>
</body>
</html>

کلاس card-shell در HTML روی wrapper قرار دارد و کلاس card روی فرزند مستقیم آن است. این جداسازی عمدی است، چون query اندازه wrapper را می‌خواند و چیدمان card را عوض می‌کند. آستانه 28rem به فضای لازم برای دو بخش این نمونه مربوط است و عددی عمومی برای همه کارت‌ها نیست. اگر محتوای خودتان طولانی‌تر شد، آستانه را از نیاز واقعی متن انتخاب کنید. ساختاری که روی دو کلمه کوتاه خوب است ممکن است با عنوان فارسی بلند، کنارهم‌چینی مناسبی نداشته باشد.

قاعده پایه پیش از @container آمده و کارت را یک‌ستونه می‌سازد. مرورگری که query را نمی‌فهمد همان قاعده پایه را نگه می‌دارد. برای تغییر نمونه، متن دو کارت را عوض کنید و عرض container را بررسی کنید؛ selector تازه‌ای بدون markup متناظر اضافه نکنید. اگر بخواهید تعداد ستون‌های فهرست بیرونی را عوض کنید، باید قاعده board را تغییر دهید. اگر شکل داخل کارت را تغییر می‌دهید، card و query مربوط محل کار هستند. این تفکیک نگهداری کد را ساده‌تر می‌کند.

Style Query همان Size Query نیست

Style Query به وضعیت سبک container مربوط است و نباید آن را با خواندن هر مقدار دلخواه CSS برابر گرفت. راهنمای Size و Style Queries تفاوت دامنه این پرسش‌ها را توضیح می‌دهد. نمونه‌های متداول بر Custom Property تکیه دارند. اگر پروژه به پرسش از یک ویژگی دیگر نیاز دارد، پشتیبانی همان ویژگی را بررسی کنید. جمله کلی «می‌توان همه استایل‌های والد را پرسید» برای انتخاب پیاده‌سازی بیش از حد گسترده است.

یک کاربرد قابل فهم، رساندن وضعیت تم به اجزاست. container مقدار یک Custom Property را تعیین می‌کند و فرزند بر اساس آن ظاهر مناسب می‌گیرد. با این حال، برای یک تم ساده شاید استفاده مستقیم از همان متغیر کافی باشد و query اضافه ضرورتی نداشته باشد. انتخاب قابلیت جدید باید از مسئله بیاید. هر لایه شرطی تازه، فهم cascade را دشوارتر می‌کند. اگر متغیر و inheritance کار را روشن‌تر انجام می‌دهند، همان ساختار ساده‌تر را نگه دارید.

Custom Functions و Mixins هنوز باید جدا ارزیابی شوند

پیش‌نویس CSS Functions and Mixins مسیر تعریف توابع و استفاده دوباره از قواعد را مطرح می‌کند. این سند را نباید وعده حذف فوری Sass در همه پروژه‌ها خواند. Function و Mixin مفهوم یکسانی ندارند: یکی به تولید مقدار مرتبط است و دیگری به استفاده دوباره از مجموعه قواعد. وضعیت استاندارد و پشتیبانی مرورگر هر بخش را جدا دنبال کنید. مهاجرت ابزار ساخت فقط بر پایه عنوان یک ماژول می‌تواند قواعد فعلی پروژه را بدون جایگزین رها کند.

مستند @function در MDN syntax تابع سفارشی و نام‌گذاری آن را شرح می‌دهد. برای استفاده عملی، جدول Browser Compatibility همان صفحه را در زمان پیاده‌سازی بخوانید. نمونه‌ای که تنها در محیط آزمایشی اجرا می‌شود برای مقاله آموزشی عمومی باید با محدودیت معرفی شود. اگر مقصد شما مرورگر سازمانی قدیمی است، نسخه build-time یک محاسبه ممکن است همچنان لازم باشد. قابلیت native و قابلیت ابزار ساخت در زمان‌های متفاوتی ارزیابی می‌شوند.

پیش از حذف preprocessor، کاربردهای موجود آن را فهرست کنید: متغیر، محاسبه، تولید selector یا سازمان‌دهی فایل. ممکن است بخشی از نیاز با CSS فعلی حل شود و بخشی هنوز به ابزار ساخت وابسته بماند. مهاجرت مرحله‌ای اجازه می‌دهد تغییر رفتار و تغییر ابزار از هم جدا بمانند. هدف باید کاهش پیچیدگی باشد؛ جایگزینی یک abstraction آشنا با چند شرط تازه فقط برای استفاده از syntax جدید، لزوماً کد قابل نگهداری‌تری نمی‌سازد.

شرط‌های inline و cascade به دقت نیاز دارند

تابع if() در CSS مسیر شرط‌گذاری در مقدار property را معرفی می‌کند. این قابلیت به معنی تبدیل CSS به JavaScript نیست و مدل اجرا و cascade خودش را دارد. برای یک شرط ساده، ممکن است if() خوانایی خوبی بدهد؛ برای چند حالت مرتبط، قواعد جدا یا متغیرهای نام‌دار واضح‌تر باشند. وقتی شرط در چند property تکرار می‌شود، به نگهداری آن فکر کنید. کوتاه‌ترشدن تعداد سطرها همیشه به معنی آسان‌ترشدن فهم رفتار نیست.

قاعده‌ای که مرورگر نمی‌شناسد معمولاً در محاسبه سبک پذیرفته نمی‌شود، اما fallback باید عمداً طراحی شود. مقدار پایه را پیش از مقدار تازه قرار دهید و برای قابلیت‌های مناسب از @supports استفاده کنید. Feature Detection وجود یک رفتار syntax را می‌سنجد و درباره کیفیت طراحی یا نبود خطای پیاده‌سازی حکم نمی‌دهد. پشتیبانی را با فهرست مرورگرهای هدف و نیاز محصول تطبیق دهید. برای ثبت تصمیم، نام قابلیت، مرجع و رفتار نسخه پایه را کنار هم بنویسید.

Anchor Positioning و حرکت را به نیاز واقعی وصل کنید

CSS Anchor Positioning برای قرارگیری عناصر نسبت به anchor و مدیریت موقعیت‌های جایگزین سازوکار دارد. منوی کوچک کنار دکمه نمونه‌ای از مسئله مرتبط است. مکان ظاهرشدن، محدودیت viewport و تعامل صفحه‌کلید باید با هم بررسی شوند. جای‌گذاری بصری خوب به تنهایی رفتار دسترسی‌پذیر منو را نمی‌سازد. اگر مثال به JavaScript برای بازوبسته‌شدن نیاز دارد، باید آن بخش و markup مربوط هم کامل ارائه شوند، نه فقط چند property تازه.

در قابلیت‌های حرکت نیز هدف را مشخص کنید. جابه‌جایی بصری می‌تواند تغییر وضعیت را قابل فهم کند، اما حرکت اجباری برای همه کاربران مناسب نیست. حالت Reduced Motion باید اطلاعات لازم را بدون حرکت غیرضروری نگه دارد. قابلیت تازه را روی تعامل ضروری آزمایش ذهنی کنید: اگر انیمیشن حذف شود، آیا کاربر هنوز می‌فهمد چه چیزی تغییر کرده؟ اگر جواب منفی است، پیام یا ساختار رابط به اصلاح نیاز دارد. حرکت باید توضیح را همراهی کند و جای آن را نگیرد.

برای برنامه‌ریزی CSS پروژه، یک قابلیت را انتخاب کنید که مسئله مشخصی را حل می‌کند. مرجع رسمی و وضعیت سازگاری را ثبت کنید، نسخه پایه را بسازید و enhancement را روی آن قرار دهید. نمونه container این مقاله یک الگوی همین کار است: محتوا در همه حالت‌ها خوانا می‌ماند و چیدمان در محیط پشتیبانی‌شده بهتر می‌شود. چنین روالی از انتظار یک «عرضه بزرگ CSS در ۲۰۲۶» قابل استفاده‌تر است و تصمیم تیم را به رفتار واقعی رابط وصل می‌کند.