معرفی Feature Query جایگزینی برای کتابخانه Modernizr

ابزاری در css تعبیه شده که شاید تاکنون نام آن را نشنیده باشید اما زمانی که با آن آشنا شوید حتما به یکی از ویژگی های محبوب css برایتان مبدل خواهد شد.

این ابزار با نام Feature Query به دستور @supports استفاده می شود. به وسیله @supports میتوان دید که آیا یک property یا value در css در مرورگرهای مختلف شناخته شده و معتبر هست یا نه. به طور مثال:

@supports (display: grid) {
 	 main {
    		display: grid;
  }
}

کد بالا در صورتی اجرا می شود که مقدار grid برای این property در مرورگر تعریف داشته باشد. در غیر اینصورت کد درون براکت skip شده و اجرا نخواهد شد.

ممکن است برخی در خصوص مفهوم Feature Query این تصور اشتباه را داشته باشند که بوسیله آن می توان بررسی نمود آیا یک مرورگر property مورد نظر را در css به درستی پیاده سازی کرده است یا نه. در صورتیکه عملکرد Feature Query برخلاف این تصور، یک Verification از خارج ارسال نمی کند بلکه یک گزارش از خود مرورگر دریافت می کند که آیا یک ویژگی در css را پشتیبانی می کند یا نه. به عبارتی اگر مرورگر ویژگی های css را به درستی پیاده سازی نکرده باشد، @supports به ما کمکی نخواهد کرد. اگر مرورگر گزارش غلطی از ویژگی های پشتیبانی کننده خود می دهد، باز هم @supports کمکی نخواهد کرد. یعنی؛ @supports یک ابزار جادویی برای رفع bugهای مرورگرها نیست. با این حال، این ابزار می تواند بسیار مفید باشد. کاری که بسیاری برای انجام آن از Modernizr ای استفاده می کنند که مبتنی بر javascript است، با Feature Query قابل دستیابی است. اگرچه فایل Modernizr.js حجم بالایی ندارد، اما باید حتما قبل از فایل css دانلود و اجرا شود. استفاده از js همواره سرعت را در مقایسه با حالتی که تنها از css استفاده می کنیم، کاهش می دهد.

Query دارای syntax مشابه Media Query است.

ما می دانیم مرورگرها در صورت پشتیبانی نکردن از یک property یا value پیغام خطایی ارسال نکرده و از روی کد عبور می کنند و آن را اجرا نمی کنند. سوالی که پیش می آید این است که پس دلیل ایجاد @support چیست؟ پاسخ این سوال را به این شکل می دهیم؛

Feature Query یک ابزاری است که بوسیله آن یک مجموعه css declaration را تحت شروط خاصی اجرا می کنیم. گاهی نیاز داریم بخشی از کد css را تنها در صورتیکه یک property یا value توسط مرورگر پشتیبانی شود، اجرا کنیم. برای مثال، property جدیدی در css با عنوان initial-letter ایجاد شده است که حرف اول یک رشته کاراکتر را انتخاب می کند. می خواهیم تنها در صورتیکه این برای مرورگر شناخته شده بود، حرف اول پاراگراف را قرمز، بولد و درشت تر کند. برای این کار از Feature Query استفاده می کنیم.

حال ما برای انجام این کار و تست شرط مورد نظر به یک روش نیازمندیم:

@supports (initial-letter: 4) or (-webkit-initial-letter: 4) {
  p::first-letter {
     -webkit-initial-letter: 4;
     initial-letter: 4;
     color: #ff0000;
  }
}

سوالی که پیش می آید این است که چرا Initial-letter:4 ؟ آیا عدد 4 اهمیت خاصی دارد؟ پاسخ این است که @supports برای انجام تست و بررسی شرط، نیاز به property و value دارد. و ما گاهی می خواهیم تنها یک از این دو را بررسی کنیم. بنابراین در نمونه بالا عدد 4 هیچ اهمیتی ندارد. و میتوان از هر عددی دیگری استفاده کرد. اما در مورد حالتی مانند display: grid واضح است که هر دو property و value دارای اهمیت هستند.

پشتیبانی مرورگرها از Feature Query:

@supports (height: 100vh) {
  //  طرح با توجه به ارتفاع viewport 
}
@supports not (height: 100vh) {
  // طرح دیگر برای مرورگرهای قدیمی
}

کد بالا در صورتیکه ارتفاع viewport مقدار مشخصی باشد، یک طرح و در غیر اینصورت طرح دیگری را نمایش می دهد. حال نکته اینجاست که اگر خود مرورگر @supports را نشناسد، کاملا از روی این بخش از کد عبور کرده و هیچ یک از دو طرح را نمایش نمی دهد. آیا این بدان معنی است که ما نمی توانیم تا زمانی که پشتیبانی کامل از Feature Query انجام بگیرد، از این ابزار استفاده کنیم؟ جواب خیر است. حتما بهتر است که این کار را انجام دهیم. فقط باید کد خود را به شکل نمونه بالا ننویسیم. چگونه؟ درست مثل زمانی که Media Query ها هنوز به طور کامل توسط مرورگرها پشتیبانی نمی شدند اما با این حال ما از آنها استفاده می کردیم.

وضعیت پشتیبانی از Feature Query طبق سایت caniuse.com به شکل زیر است:

شاید به نظر برسد عدم پشتیبانی IE مشکل بزرگی است اما در عمل واقعا اینگونه نیست. فرض کنید می خواهیم از object-fit: cover استفاده کنیم و در صورتیکه برای مرورگر شناخته شده نبود، طرح دیگری را پیاده سازی کنیم:

div {
  width: 300px;
  background: yellow;
}  //fallback code برای مرورگر های قدیمی 


@supports (object-fit: cover) {
  img {
    object-fit: cover;
  }
  div {
    width: auto;
    background: green;
  }
}

برای کد بالا چهار حالت وجود دارد:

حالت 1 که حالت ایده آل است. و کد درست همان طور که می خواهیم اجرا خواهد شد.

حالت 2، حالتی است که @supports برای مرورگر تعریف شده است. بنابراین کد داخل براکت skip نمی شود و مرورگر آن را می خواند. که ما برای حالتی که property مورد نظر پشتیبانی نشود، آلترناتیو در نظر گرفته ایم. پس مشکلی بوجود نخواهد آمد.

در حالت 3 با توجه به آنکه کد درون براکت را شما برای حالتی نوشته اید که مرورگر @supports را می شناسد، پس در غیر اینصورت، از روی کد عبور خواهد کرد. اینجاست که fallback code به کمک شما خواهد آمد. یعنی تا زمانی که property موردنظر توسط مرورگر پشتیبانی نشود، اینکه @supports برای آن تعریف شده نیست، اهمیتی پیدا نمی کند.

مشکل اصلی حالت 4 است. یعنی مرورگر property را می شناسد اما چون @supports برایش معنا ندارد، آن ویژگی css ای را اعمال نخواهد کرد.

اکنون متوجه می شویم چرا @supports و @supports not در کنار آن به عنوان آلترناتیو آن مسئله، روش مناسبی نیست. چرا که برای مرورگرهای قدیمی همواره باید یک fallback code در نظر گرفت

به هر حال نکته ای که وجود دارد این است که مانند سایر ویژگی ها جدید css برای استفاده سراسری از این ابزار، باید منتظر پشتیبانی کامل مرورگرها در آینده ماند.