سازگاری مرورگرها؛ قبل از استفاده از یه ویژگی جدید، چک کنید

تو این دوره، چند بار به‌طور پراکنده اشاره کردیم که یه ویژگی خاص (مثل subgrid، oklch یا container query) «تو مرورگرهای مدرن پشتیبانی می‌شه، ولی قبل از استفاده تو یه پروژه‌ی واقعی چک کنید». حالا با شروع آخرین فصل این دوره، وقتشه ببینیم این چک کردن دقیقاً یعنی چی، از کجا انجام بشه، و چطور یه تصمیم آگاهانه درباره‌ی استفاده یا عدم استفاده از یه ویژگی جدید بگیریم.

چرا سازگاری مرورگر هنوز یه موضوع مهمه؟

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

Can I Use: منبع اصلی و استاندارد

معروف‌ترین و پرکاربردترین ابزار برای چک کردن سازگاری، caniuse.com هست. کافیه اسم یه ویژگی (مثل subgrid یا :has()) رو جست‌وجو کنید تا یه جدول رنگی ببینید که نشون می‌ده هر مرورگر، از کدوم نسخه به بعد، این ویژگی رو پشتیبانی می‌کنه:

/* قبل از استفاده از این، caniuse رو چک کنید */
.parent:has(> .featured) {
  border: 2px solid gold;
}

رنگ سبز یعنی پشتیبانی کامل، زرد معمولاً یعنی پشتیبانی جزئی یا نیاز به یه پیشوند خاص، و قرمز یعنی عدم پشتیبانی. یه نکته‌ی مهم: caniuse معمولاً یه درصد «Global usage» هم نشون می‌ده که تخمین می‌زنه چند درصد از کاربرهای کل دنیا، مرورگری با پشتیبانی این ویژگی دارن؛ ولی این عدد جهانیه، نه مخصوص کاربرهای پروژه‌ی شما.

MDN: مستندات رسمی‌تر و دقیق‌تر

در کنار caniuse، مستندات MDN (Mozilla Developer Network) برای هر ویژگی CSS یه جدول «Browser compatibility» در انتهای صفحه داره که معمولاً جزئیات بیشتری نسبت به caniuse می‌ده؛ مثلاً این‌که آیا یه مقدار خاص از یه ویژگی (نه کل ویژگی) پشتیبانی می‌شه یا نه، یا این‌که پشتیبانی «جزئی» دقیقاً یعنی چی. برای ویژگی‌های پیچیده‌تر که رفتارشون بین مرورگرها ممکنه کمی فرق داشته باشه (نه فقط «هست یا نیست»)، MDN معمولاً منبع دقیق‌تریه.

خوندن درست یه جدول سازگاری: نسخه مهمه، نه فقط اسم مرورگر

یه اشتباه رایج اینه که فقط چک کنیم «آیا Chrome پشتیبانی می‌کنه یا نه»، بدون توجه به این‌که از کدوم نسخه به بعد. یه ویژگی ممکنه تو Chrome ۱۲۰ باشه ولی تو Chrome ۹۰ نباشه؛ و اگه بخشی از کاربرهای پروژه‌تون (طبق آمار analytics خودتون، نه فرض کلی) هنوز رو نسخه‌های قدیمی‌تر باشن، عدد سبز caniuse به‌تنهایی کافی نیست.

Baseline: یه استاندارد جدیدتر و ساده‌تر برای تصمیم‌گیری سریع

یه مفهوم نسبتاً جدید که هم تو caniuse و هم تو MDN دیده می‌شه، «Baseline» است. این یه برچسب ساده‌ست که می‌گه یه ویژگی الان تو همه‌ی مرورگرهای اصلی مدرن (Chrome، Firefox، Safari، Edge) به‌طور پایدار پشتیبانی می‌شه یا نه، بدون نیاز به این‌که خودتون جدول رو ریز بررسی کنید:

برچسب Baselineمعنی
Widely availableحداقل ۳۰ ماهه که تو همه‌ی مرورگرهای اصلی پشتیبانی می‌شه؛ استفاده‌ش معمولاً امنه
Newly availableبه‌تازگی تو همه‌ی مرورگرهای اصلی رسیده؛ هنوز به‌اندازه‌ی کافی قدیمی نشده که کاملاً مطمئن باشیم
Limited availabilityحداقل یکی از مرورگرهای اصلی هنوز پشتیبانی نمی‌کنه

برای پروژه‌هایی که می‌خوان بدون درگیر شدن با جزئیات نسخه‌به‌نسخه، یه تصمیم سریع بگیرن، Baseline معمولاً کافیه: اگه «Widely available» باشه، تو اکثر پروژه‌ها می‌شه بدون نگرانی خاصی ازش استفاده کرد.

تفاوت «عدم پشتیبانی» با «پشتیبانی متفاوت»

یه نکته‌ی ظریف که caniuse همیشه به‌وضوح نشونش نمی‌ده: بعضی وقت‌ها یه ویژگی تو همه‌ی مرورگرها «هست»، ولی رفتارش کمی فرق می‌کنه (مثلاً یه گوشه‌ی گرد که تو یه مرورگر یه پیکسل متفاوت رندر می‌شه، یا یه انیمیشن که تو یه مرورگر کمی کندتره). این نوع تفاوت‌ها معمولاً تو جدول‌های سازگاری دیده نمی‌شن و فقط با تست دستی رو خود مرورگرها (یا با گزارش‌های تجربی سایر توسعه‌دهنده‌ها) کشف می‌شن.

چطور تصمیم بگیریم که یه ویژگی جدید رو استفاده کنیم یا نه؟

یه سؤال عملی: caniuse می‌گه یه ویژگی ۹۲٪ پوشش جهانی داره؛ آیا کافیه؟ جواب بستگی داره به چند فاکتور: اول، آیا این ویژگی برای «کارکرد اصلی» سایت حیاتیه یا فقط یه بهبود ظاهری جزئیه؟ دوم، آیا یه fallback ساده و کم‌هزینه (مثل چیزی که تو درس @supports دیدیم) براش وجود داره؟ سوم، و مهم‌تر از همه، آمار analytics خود پروژه چی می‌گه؛ اگه ۹۸٪ کاربرهای واقعی سایت شما از مرورگرهای پشتیبانی‌کننده استفاده می‌کنن، عدد جهانی caniuse خیلی کم‌ربط‌تر از این آمار داخلیه.

نکته مهم: هیچ‌وقت تصمیم سازگاری رو صرفاً بر اساس حس شخصی («فکر کنم همه از Chrome جدید استفاده می‌کنن») نگیرید. آمار analytics واقعی پروژه (که معمولاً تو ابزارهایی مثل Google Analytics قابل مشاهده‌ست) همیشه دقیق‌تر از فرض ذهنیه.

Progressive Enhancement: استراتژی اصلی برای کنار اومدن با ناهماهنگی

رویکرد رایج و پیشنهادی برای استفاده از ویژگی‌های جدید، «بهبود تدریجی» (progressive enhancement) هست: طوری طراحی کنید که سایت تو مرورگرهای قدیمی‌تر هم کاملاً کار کنه (شاید کمی ساده‌تر)، و مرورگرهای جدیدتر یه تجربه‌ی بهبودیافته ببینن. این دقیقاً همون الگوییه که تو درس @supports با not دیدیم؛ به‌جای این‌که کل قابلیت رو قربانی کنید، فقط بخش بصری اضافه رو مشروط می‌کنید.

اشتباه رایج: چک کردن سازگاری فقط یه‌بار، در ابتدای پروژه

یه اشتباه رایج اینه که سازگاری یه ویژگی رو فقط یه‌بار، موقع اولین استفاده چک کنیم و بعد فراموشش کنیم. ولی پشتیبانی مرورگرها دائم در حال تغییره؛ یه ویژگی که ۶ ماه پیش «Limited availability» بوده، ممکنه الان «Widely available» شده باشه (یا برعکس، یه تصمیم قدیمی درباره‌ی جلوگیری از یه ویژگی، دیگه لازم نباشه). بازبینی دوره‌ای این تصمیم‌ها، خصوصاً برای پروژه‌های بلندمدت، ارزشش رو داره.

جمع‌بندی

caniuse.com و جدول‌های سازگاری MDN، دو منبع اصلی برای چک کردن پشتیبانی مرورگرها از یه ویژگی CSS هستن؛ برچسب Baseline هم یه راه سریع‌تر برای تصمیم‌گیری کلیه. تصمیم نهایی درباره‌ی استفاده از یه ویژگی جدید، باید بر اساس آمار واقعی کاربرهای همون پروژه (نه فرض یا حتی عدد جهانی caniuse) و اهمیت اون ویژگی برای عملکرد اصلی سایت گرفته بشه، با در نظر گرفتن progressive enhancement به‌عنوان استراتژی اصلی برای کنار اومدن با ناهماهنگی.