ব্রাউজার সাপোর্ট — Can I use, fallback, @supports আর progressive enhancement

১ · একই কোড, ভিন্ন ব্রাউজার — পার্থক্য আসে কোথা থেকে

একটি পরিচিত গল্প দিয়ে শুরু করি। নাদিয়া একটি অনলাইন শাড়ির দোকানের পাতা বানিয়েছেন। নিজের ল্যাপটপে Chrome-এ সব নিখুঁত। কিন্তু দোকানের মালিক বললেন, “আমার iPhone-এ নিচের বোতামটা অর্ধেক কাটা।” আর এক ক্রেতা ফেসবুকে লিংক চেপে পাতা খুলে দেখলেন, পণ্যের কার্ডগুলো এলোমেলো। কোড একটাই — তবু তিন জায়গায় তিন রকম ফল। কেন?

পর্ব ০১ আর ০২-এ দেখেছেন, ব্রাউজারের যে অংশ HTML-CSS পড়ে পাতা আঁকে, তার নাম rendering engine. আজকের ওয়েবে প্রধান ইঞ্জিন মাত্র তিনটি, কিন্তু ব্রাউজারের নাম অনেক:

এখানেই প্রথম শিক্ষা: ব্রাউজারের নাম নয়, ইঞ্জিন আর তার সংস্করণই ঠিক করে আপনার CSS কেমন দেখাবে। নাদিয়ার মালিকের iPhone-এ Chrome থাকলেও পাতা আঁকছে WebKit. আবার যে ব্রাউজার নিজে থেকে নিয়মিত আপডেট হয়, তাকে বলে evergreen browser — কিন্তু “নিজে থেকে” মানে সবসময় নয়। পুরোনো iPhone নতুন iOS না পেলে Safari-ও পুরোনো সংস্করণে আটকে থাকে।

বাংলাদেশের বাস্তবতা — পুরোনো ফোন আর অ্যাপের ভেতরের ব্রাউজার

ঢাকার অফিসের ডেভেলপার সাধারণত নতুন ল্যাপটপে সর্বশেষ Chrome চালান। কিন্তু আপনার পাতার পাঠকদের বড় একটি অংশ কম দামি বা কয়েক বছরের পুরোনো Android ফোনে, অনেক সময় দুর্বল নেটওয়ার্কে পাতা খোলেন। তাঁদের অনেকে ব্রাউজার আপডেট করেন না, ফোনের জায়গা কম বলে আপডেট বন্ধ রাখেন, বা এমন ফোন ব্যবহার করেন যা আর নতুন সিস্টেম আপডেট পায় না। সংখ্যা প্রতি বছর বদলায়, তাই নির্দিষ্ট হিসাব নয় — শুধু মনে রাখুন, “সবার ব্রাউজার আমার মতো নতুন” ধরে নেওয়া এখানে সবচেয়ে বড় ভুল।

আরেকটি বড় উৎস হলো in-app browser: ফেসবুক, মেসেঞ্জার বা অন্য অ্যাপে লিংক চাপলে পাতা খোলে অ্যাপের ভেতরেই। সেখানে পাতা আঁকে WebView — Android-এ Chromium-ভিত্তিক, iPhone-এ WebKit-ভিত্তিক। বাংলাদেশে অনলাইন দোকানের বড় অংশ ক্রেতা আসে ঠিক এই পথে — ফেসবুক পেজের পোস্ট থেকে।

২ · সাপোর্টের তথ্য পড়া — Can I use, MDN, Baseline আর Interop

“এই CSS কি সব ব্রাউজারে চলবে?” — প্রশ্নটির উত্তর অনুমানে নয়, তথ্যে খুঁজতে হয়। পেশাদাররা চারটি জায়গা দেখেন।

Baseline-এর তিন অবস্থা — আর এই কোর্স কীভাবে লেবেল দেয়

Baseline একটি নির্দিষ্ট “মূল ব্রাউজার-গুচ্ছ” দেখে: কম্পিউটারের Chrome, Edge, Firefox ও Safari, আর মোবাইলের Chrome (Android), Firefox (Android) ও Safari (iOS).

• Limited availability (not yet Baseline): এক বা একাধিক মূল ব্রাউজারে এখনো নেই। এই কোর্সে লিখি “not yet Baseline”. ব্যবহার করলে বাধ্যতামূলকভাবে fallback.
• Newly available: সব মূল ব্রাউজারের সর্বশেষ সংস্করণে এসেছে। কিন্তু যিনি কয়েক মাস আপডেট করেননি, তাঁর কাছে নেই। সাথে সাধারণত একটি বছর লেখা থাকে — “Baseline 2024” মানে সেই বছরে Newly হয়েছে।
• Widely available: Newly হওয়ার ৩০ মাস পরে এই লেবেল আসে। ধরে নেওয়া হয়, ততদিনে প্রায় সব ব্যবহারকারীর ব্রাউজার আপডেট হয়ে গেছে। এই কোর্সে কোনো ফিচারকে “Baseline Widely available” বললে মানে — সাধারণ প্রজেক্টে নিশ্চিন্তে ব্যবহার করুন।

উদাহরণ: পর্ব ৩৪-এর :has() ২০২৩ সালের শেষে Firefox যোগ দেওয়ায় Newly available হয়; ৩০ মাস পরে, ২০২৬ সালের মাঝামাঝি, Widely available. অন্যদিকে পর্ব ২৫-এর Flexbox বা পর্ব ২৭-এর Grid বহু বছর ধরেই Widely available. নতুন একটি ফিচার ব্যবহার করবেন কি না, সিদ্ধান্তটি ধাপে ধাপে দেখুন:

৩ · Progressive enhancement বনাম graceful degradation

সব ব্রাউজারের জন্য পাতা বানানোর দুটি দর্শন আছে। প্রথমটি পুরোনো: সবচেয়ে নতুন ব্রাউজারের জন্য পূর্ণ নকশা বানাও, তারপর দেখো পুরোনোতে কতটা ভাঙছে, আর জোড়াতালি দাও। একে বলে graceful degradation. দ্বিতীয়টি উল্টো দিক থেকে শুরু করে: আগে এমন ভিত্তি বানাও যা সবখানে চলে, তারপর যে ব্রাউজার যত বেশি পারে, তার জন্য তত স্তর যোগ করো। এটিই progressive enhancement.

একটি পণ্য-কার্ড দিয়ে চারটি স্তর ধাপে ধাপে দেখুন:

<article class="card">
  <h3>জামদানি শাড়ি</h3>
  <p>৳৪,৫০০</p>
  <form action="/cart" method="post">
    <input type="hidden" name="id" value="j12">
    <button>কার্টে নিন</button>
  </form>
</article>

.card { border: 1px solid #d4d4d8; border-radius: 8px;
        padding: 12px; max-width: 20em; }
.card button { background: #15803d; color: #fff;
               padding: 8px 14px; border: 0; }
.cards { display: flex; flex-wrap: wrap; }

@supports (display: grid) {
  .cards { display: grid; gap: 1rem;
    grid-template-columns: repeat(auto-fill, minmax(14em, 1fr)); }
}
.card:has(.sold-out) { opacity: .6; }  /* না চিনলে নিয়মটিই বাদ */

if ('fetch' in window) {
  form.addEventListener('submit', async (e) => {
    e.preventDefault();
    await fetch(form.action, { method: 'post', body: new FormData(form) });
    // কার্টের সংখ্যা বাড়াও
  });
}
// JS না চললে? form নিজেই জমা হয় — স্তর ১

৪ · CSS-এর নিজস্ব fallback — অচেনা জিনিস বাদ দেওয়ার নিয়ম

পর্ব ১৬-এ দেখেছেন, CSS ভুল পেলে error দেখিয়ে থেমে যায় না। একে বলে forgiving error handling: ব্রাউজার যে declaration বোঝে না — অচেনা property, বা চেনা property-র অচেনা মান — সেটি চুপচাপ বাদ দেয়, আর বাকিগুলো চালিয়ে যায়। এই একটি নিয়মই CSS-এর সবচেয়ে পুরোনো আর সহজ fallback কৌশলের ভিত্তি: একই property দুইবার লিখুন — আগে পুরোনো মান, পরে নতুন মান। নতুন ব্রাউজার দুটিই বোঝে, আর cascade-এ পরেরটি জেতে; পুরোনো ব্রাউজার দ্বিতীয়টি বাদ দেয়, আর প্রথমটি থেকে যায়।

এবার নিজে দেখুন। নিচের বোতামে আগে নীল, পরে oklch()-এর সবুজ; বাক্সে আগে লাল সীমানা, পরে একটি বানানো রঙের নাম যা কোনো ব্রাউজারই চেনে না — পুরোনো ব্রাউজারের চোখে নতুন ফিচার ঠিক এমনই অচেনা দেখায়:

body { font-family: sans-serif; }
.btn {
  display: inline-block;
  padding: 10px 16px;
  border-radius: 8px;
  color: white;
  background: #1d4ed8;                /* ১ · সবাই চেনে — fallback */
  background: oklch(0.55 0.17 145);   /* ২ · চিনলে এটি জেতে */
}
.box {
  padding: 10px;
  border: 3px solid #b91c1c;          /* ১ · fallback */
  border: 3px solid shapla-red;       /* ২ · অচেনা মান — বাদ পড়বে */
  width: 220px;                       /* ১ · পুরোনো ব্রাউজারের জন্য */
  width: fit-content;                 /* ২ · লেখার মাপে বাক্স */
}

সাবধান: selector-এর ভুল পুরো rule ফেলে দেয়

declaration-এর ক্ষমাশীলতা selector-এ নেই। একটি rule-এর selector তালিকায় কমা দিয়ে কয়েকটি selector থাকলে, আর তার একটিও অচেনা হলে, ব্রাউজার পুরো rule বাদ দেয় — চেনা selector-গুলোসহ। পুরোনো দিনে ::-moz-selection, ::selection একসাথে লিখে অনেকে এই ফাঁদে পড়তেন। ব্যতিক্রম পর্ব ১৭-এর forgiving selector list: :is() আর :where()-এর ভেতরে অচেনা অংশটি একা বাদ পড়ে।

p { padding: 8px; font-family: sans-serif; border-radius: 6px; }

/* ক · একটি selector অচেনা → পুরো নিয়মই বাদ */
.a, .a:shapla { background: #fde68a; }

/* খ · :is() ক্ষমাশীল → শুধু অচেনা অংশটি বাদ */
:is(.b, .b:shapla) { background: #bbf7d0; }

/* গ · আলাদা rule → একটির ভুল অন্যটিকে ছোঁয় না */
.c { background: #bfdbfe; }
.c:shapla { background: red; }

৫ · @supports — ব্রাউজারকে সরাসরি জিজ্ঞেস করা

দুইবার declaration লেখার কৌশল একটি property-র জন্য চমৎকার। কিন্তু নতুন লেআউটে প্রায়ই অনেকগুলো property একসাথে বদলাতে হয় — Grid চালু করলে পুরোনো margin সরাতে হয়, কলামের মাপ বদলাতে হয়। তখন লাগে @supports — একে বলে feature query. এটি ব্রাউজারকে জিজ্ঞেস করে, এই property আর মানের জোড়াটি সে চেনে কি না। চিনলে ভেতরের সব নিয়ম খাটে।

@supports (display: grid) { … }                 /* চেনে কি না */
@supports not (display: grid) { … }             /* চেনে না */
@supports (display: grid) and (gap: 1rem) { … } /* দুটিই চেনে */
@supports (height: 100dvh) or (height: 100svh) { … } /* যেকোনো একটি */
@supports selector(:has(img)) { … }             /* selector চেনে কি না */

একটি জিনিস খেয়াল করুন: শর্তে শুধু property-র নাম নয়, নাম আর মান দুটিই লাগে, বন্ধনীর ভেতরে। and, or একসাথে মেশাতে হলে বাড়তি বন্ধনী দিন — (a) and ((b) or (c)). এবার একটি সত্যিকারের ফিচার আর একটি বানানো ফিচারের জন্য একই প্রশ্ন করে দেখি:

<style>
  body { font-family: sans-serif; }
  .msg { padding: 8px 12px; border-radius: 8px; margin: 6px 0; }
  .yes { display: none; background: #dcfce7; }
  .no  { background: #fee2e2; }
  /* ডিফল্টে "না" দেখায়; চিনলে "হ্যাঁ"-তে বদলায় */
  @supports (display: grid) {
    .grid .yes { display: block; }  .grid .no { display: none; }
  }
  @supports (display: shapla) {
    .fake .yes { display: block; }  .fake .no { display: none; }
  }
</style>
<div class="grid">
  <p class="msg yes">✔ display: grid চেনে — নতুন নকশা পাবে</p>
  <p class="msg no">✘ display: grid চেনে না — সরল নকশা পাবে</p>
</div>
<div class="fake">
  <p class="msg yes">✔ display: shapla চেনে</p>
  <p class="msg no">✘ display: shapla চেনে না — fallback দেখাচ্ছে</p>
</div>

selector() — :has()-এর মতো নতুন selector যাচাই

নতুন selector-এর ক্ষেত্রে আগের অংশেই দেখেছেন, অচেনা selector থাকলে rule নিজেই বাদ পড়ে — তাই @supports ছাড়াও “চিনলে খাটে, না চিনলে নয়” ঘটে। তবু @supports selector() কাজে লাগে, যখন selector চিনলে অন্য কিছুও বদলাতে হয় — যেমন :has() চিনলে একটি সাহায্য-লেখা লুকানো, বা পুরোনো কৌশলটি বন্ধ করা:

body { font-family: sans-serif; }
.opt { display: block; padding: 10px; margin: 6px 0;
       border: 2px solid #d4d4d8; border-radius: 8px; }
input { accent-color: #15803d; }   /* সবার জন্য: টিকের রং */

.note::after { content: "এই ব্রাউজার :has() চেনে না — বাক্স একই থাকবে, টিক ঠিকই কাজ করবে।"; }

@supports selector(:has(*)) {
  .opt:has(:checked) { border-color: #15803d; background: #f0fdf4; }
  .note::after { content: "এই ব্রাউজার :has() চেনে — টিক দিলে পুরো বাক্স সবুজ।"; }
}

JavaScript থেকে একই প্রশ্ন — CSS.supports()

@supports-এর JavaScript রূপ হলো CSS.supports(). এটি feature detection-এর সবচেয়ে পরিষ্কার উদাহরণ — ব্রাউজারের নাম নয়, সরাসরি ক্ষমতা যাচাই। নিচের কোডে and, or, not আর selector(), সবগুলো চালিয়ে দেখুন:

const tests = [
  'display: grid',
  'display: shapla',
  '(display: grid) and (gap: 1rem)',
  '(display: shapla) or (display: flex)',
  'not (display: shapla)',
  'selector(:has(img))',
  'height: 100dvh',
  'color: oklch(0.6 0.2 145)',
  'gap: 1rem'
];
for (const t of tests) {
  console.log((CSS.supports(t) ? 'true ' : 'false') + '  ' + t);
}

একটি পূর্ণ উদাহরণ — flex থেকে grid

অংশ ৩-এর স্তর ২ আর স্তর ৩ এবার হাতে-কলমে। পণ্যের তালিকা সবার জন্য flex-wrap, আর Grid চিনলে সমান মাপের কলাম:

.products { list-style: none; padding: 0; margin: 0;
            font-family: sans-serif; }
.products li { padding: 10px; border: 1px solid #d4d4d8;
               border-radius: 8px; }

/* স্তর ২ — সবার জন্য: flex-wrap আর margin দিয়ে ফাঁক */
.products { display: flex; flex-wrap: wrap; }
.products li { flex: 1 1 140px; margin: 0 8px 8px 0; }

/* স্তর ৩ — Grid চিনলে: সমান কলাম, gap দিয়ে ফাঁক */
@supports (display: grid) {
  .products { display: grid; gap: 8px;
    grid-template-columns: repeat(auto-fill, minmax(140px, 1fr)); }
  .products li { margin: 0; }
}

৬ · Vendor prefix, Autoprefixer আর browserslist

২০১০-এর দশকের শুরুর দিকের CSS দেখলে প্রায়ই এমন দৃশ্য পাবেন:

/* ইতিহাস — আজ এভাবে লিখবেন না */
.box {
  -webkit-border-radius: 8px;   /* Safari, পুরোনো Chrome */
     -moz-border-radius: 8px;   /* Firefox */
          border-radius: 8px;   /* মানদণ্ড — সবসময় শেষে */
  -webkit-transition: opacity .3s;
      -ms-transition: opacity .3s;  /* Internet Explorer */
          transition: opacity .3s;
}

এগুলো vendor prefix: -webkit- (Safari, পরে Chrome-ও), -moz- (Firefox), -ms- (Microsoft), -o- (পুরোনো Opera). ধারণাটি ছিল ভালো — একটি ফিচার পরীক্ষামূলক অবস্থায় prefix-সহ চালু হবে, spec স্থির হলে prefix ছাড়া। আর prefix-ছাড়া রূপ সবসময় শেষে, যাতে চূড়ান্ত মানটি জেতে।

কিন্তু বাস্তবে ডেভেলপাররা পরীক্ষামূলক ফিচার আসল সাইটে ব্যবহার করতে শুরু করেন, আর অনেকে শুধু -webkit- লিখতেন — iPhone-ই তখন মোবাইল ওয়েবের প্রধান। ফল: অন্য ব্রাউজারে সাইট ভাঙত, আর তারা বাধ্য হয়ে নিজেরাই -webkit- নামগুলো চিনতে শুরু করে। আজও Firefox অনেক -webkit- property বোঝে শুধু পুরোনো সাইট বাঁচাতে। এই অভিজ্ঞতার পর ব্রাউজারগুলো নীতি বদলায়: নতুন পরীক্ষামূলক ফিচার এখন আসে লুকানো flag বা origin trial-এর মাধ্যমে, prefix দিয়ে নয়।

তাহলে আজ কি prefix একেবারে নেই? কয়েকটি পুরোনো জিনিস ইতিহাসের কারণে prefix-সহই টিকে আছে, আর সবাই সেই রূপটিই চেনে। সবচেয়ে পরিচিত উদাহরণ পর্ব ২৩-এর line-clamp — লেখা কয়েক লাইনে কেটে শেষে “…”:

.card { font-family: sans-serif; max-width: 22em;
        border: 1px solid #d4d4d8; border-radius: 8px; padding: 0 12px; }
.desc {
  display: -webkit-box;          /* পুরোনো flexbox-এর নাম, শুধু এ কাজে */
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 2;         /* দুই লাইন পর “…” */
  overflow: hidden;
}

হাতে নয়, টুলে — Autoprefixer আর browserslist

কোন property-তে কোন ব্রাউজারের জন্য prefix লাগে, তা মনে রাখা মানুষের কাজ নয়। পেশাদার প্রজেক্টে আপনি শুধু মানদণ্ডের CSS লেখেন, আর PostCSS-এর একটি plugin, Autoprefixer, build-এর সময় যেখানে দরকার সেখানে prefix বসায় — আবার যেখানে আর দরকার নেই, পুরোনো prefix মুছেও দেয়। কোন ব্রাউজারকে সমর্থন করবেন, সেটি সে জানে browserslist নামের একটি ছোট তালিকা থেকে, যা Can I use-এর তথ্যের সাথে মিলিয়ে দেখা হয়:

# .browserslistrc — প্রজেক্টের মূল ফোল্ডারে
> 0.5% in BD       # বাংলাদেশে ০.৫%-এর বেশি ব্যবহৃত সব ব্রাউজার
last 2 versions    # প্রতিটি ব্রাউজারের শেষ দুই সংস্করণ
not dead           # যাদের আর আপডেট আসে না, তাদের বাদ

# কোন কোন ব্রাউজার তালিকায় এলো, দেখতে:
npx browserslist

একই তালিকা পড়ে আরও অনেক টুল — যেমন JavaScript-কে পুরোনো রূপে অনুবাদ করার টুল। ফলে পুরো প্রজেক্টে “আমরা কাদের সমর্থন করি” কথাটি এক জায়গায় লেখা থাকে। browserslist-এর সাম্প্রতিক সংস্করণে Baseline-ভিত্তিক তালিকা লেখার সুযোগও যোগ হয়েছে। PostCSS আর Autoprefixer কীভাবে প্রজেক্টে বসাবেন, তা দেখবেন পর্ব ৫০-এ।

৭ · Polyfill — কখন কাজ করে, আর CSS-এ কেন প্রায় অসম্ভব

Polyfill হলো এমন কোড, যা পুরোনো ব্রাউজারে একটি নতুন ফিচারের আচরণ নকল করে। JavaScript-এ এটি খুব কাজের: নতুন কোনো ফাংশন না থাকলে, একই নামে একটি ফাংশন বানিয়ে দেওয়া যায় — আপনার কোড বুঝতেই পারে না পার্থক্য। পর্ব ১১-এর <dialog> যখন নতুন ছিল, তখন এর polyfill অনেক সাইটে ব্যবহার হতো।

CSS-এ সমস্যা মৌলিক। অংশ ৪-এ দেখেছেন, ব্রাউজার অচেনা CSS পড়ার সময়েই ফেলে দেয়। JavaScript যখন চলে, তখন সেই নিয়মটি ব্রাউজারের তৈরি CSS-এর কাঠামো (CSSOM) থেকে আগেই উধাও। তাই একটি CSS polyfill-কে stylesheet ফাইলটি আবার নিজে ডাউনলোড করে, নিজে পড়ে, নিজের মতো হিসাব করে প্রতিটি element-এ inline style বসাতে হয় — আর পাতা স্ক্রল বা মাপ বদলালে বারবার সেটা করতে হয়। এটি ধীর, ভঙ্গুর, আর প্রায়ই আসল আচরণের সাথে মেলে না। container query-র মতো কিছু ফিচারের জন্য এমন polyfill তৈরি হয়েছিল, কিন্তু সেগুলো সাময়িক সেতু মাত্র।

৮ · পরিচিত ক্রস-ব্রাউজার বাগ আর পরীক্ষার পদ্ধতি

সব মানদণ্ড মেনে লিখলেও কিছু জায়গায় ব্রাউজারভেদে পার্থক্য প্রায় নিশ্চিত। সবচেয়ে চোখে পড়ে ফর্মের কন্ট্রোলে, কারণ এগুলো native widget — অনেক সময় অপারেটিং সিস্টেমের নিজের চেহারায় আঁকা। নিচের এডিটরে আপনার ব্রাউজার যা আঁকছে, তা শুধু তার নিজের রূপ:

<style>
  body { font-family: sans-serif; }
  label { display: block; margin: 8px 0; }
</style>
<label>ডেলিভারির তারিখ <input type="date" value="2026-10-25"></label>
<label>সময় <input type="time" value="15:30"></label>
<label>জেলা
  <select><option>ঢাকা</option><option>রাজশাহী</option></select>
</label>
<label>পরিমাণ <input type="range" min="1" max="10" value="3"></label>
<label><input type="checkbox" checked> শর্তে রাজি</label>
<label>আপলোড <progress value="60" max="100"></progress></label>

যেসব জায়গায় পার্থক্য প্রায় নিশ্চিত

/* নাদিয়ার কাটা বোতামের সমাধান — fallback আগে, নতুন একক পরে */
.hero {
  min-height: 100vh;    /* পুরোনো ব্রাউজার */
  min-height: 100svh;   /* ঠিকানার বার দেখা অবস্থাতেও পুরোটা দেখা যায় */
}

কীভাবে পরীক্ষা করবেন

Cross-browser testing মানে প্রতিটি ব্রাউজারে পিক্সেল মিলিয়ে দেখা নয় — মূল কাজগুলো (পড়া, খোঁজা, ফর্ম জমা, কেনা) প্রতিটি লক্ষ্য-ব্রাউজারে চলে কি না, আর চেহারা গ্রহণযোগ্য কি না, সেটা দেখা।

1. অন্তত তিন ইঞ্জিন: কম্পিউটারে Chrome বা Edge (Blink), Firefox (Gecko), আর WebKit-এর একটি রূপ। Mac না থাকলে Linux-এ WebKit-ভিত্তিক GNOME Web, বা স্বয়ংক্রিয় পরীক্ষার টুল Playwright-এর WebKit — যদিও এগুলো iPhone-এর Safari-র হুবহু অনুলিপি নয়।
2. আসল ফোন: DevTools-এর device mode শুধু পর্দার মাপ বদলায়, ইঞ্জিন নয় — Edge-এ “iPhone” বাছলেও আঁকে Blink. পরিবার বা বন্ধুদের একটি পুরোনো Android আর একটি iPhone-এ পাতা খুলুন; ফেসবুকের লিংক থেকেও একবার খুলুন।
3. ফোনকে কম্পিউটারের সাথে জুড়ে: Android ফোন USB-তে জুড়ে Chrome-এর chrome://inspect থেকে ফোনের পাতা DevTools-এ দেখা যায়; iPhone-এর পাতা দেখা যায় Mac-এর Safari Web Inspector-এ।
4. ক্লাউড ডিভাইস ল্যাব: BrowserStack-এর মতো সেবায় ব্রাউজারে বসেই শত শত আসল ফোন আর ব্রাউজার ভাড়ায় চালানো যায় — বড় প্রজেক্ট বা নির্দিষ্ট পুরোনো ডিভাইসের বাগ খুঁজতে কাজের।
5. ধীর নেটওয়ার্ক আর JavaScript বন্ধ করে: DevTools-এ নেটওয়ার্ক ধীর করে, আর JavaScript বন্ধ করে একবার দেখুন — progressive enhancement সত্যিই কাজ করছে কি না।

৯ · প্রজেক্টের support policy ঠিক করা

“সব ব্রাউজারে চলবে” — এমন প্রতিশ্রুতি কেউ রাখতে পারে না। পেশাদার দল তাই লিখিত একটি support policy রাখে: কোন ব্রাউজারে পূর্ণ অভিজ্ঞতা, কোথায় শুধু মূল কাজ, আর কোথায় কোনো প্রতিশ্রুতি নেই। একটি বাংলাদেশি অনলাইন দোকানের জন্য নমুনা:

আর CSS লেখার নিয়ম হিসেবে এক লাইনে: “last 2 versions + Baseline Widely available স্বাধীনভাবে; Newly available-এর সাথে fallback; not yet Baseline শুধু @supports-এর ভেতরে।” সংখ্যাগুলো আপনার সাইটের analytics দেখে বছরে অন্তত একবার নতুন করে ঠিক করুন — পাঠকদের ফোন বদলায়, নীতিও বদলাবে।

১০ · AI-এর যুগে — ব্রাউজার সাপোর্টের প্রশ্ন AI-কে করলে

ব্রাউজার সাপোর্ট এমন একটি বিষয়, যেখানে AI-এর ভুলের সম্ভাবনা সবচেয়ে বেশি — কারণ তথ্যটি প্রতি মাসে বদলায়, আর AI শিখেছে বহু বছরের পুরোনো টিউটোরিয়াল থেকে। সে প্রায়ই আত্মবিশ্বাসের সাথে বলে “এটি সব আধুনিক ব্রাউজারে চলে”, অথচ ফিচারটি হয়তো শুধু Chromium-এ আছে; আবার উল্টোটাও করে — বহু আগে সমাধান হওয়া সমস্যার জন্য পুরোনো hack দেয়।

AI সাধারণত যেসব ভুল করে

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি নতুন property বা selector-এর জন্য MDN-এর Baseline-বাক্স আর caniuse.com-এর Notes নিজে দেখেছি — AI-এর “সব ব্রাউজারে চলে” কথায় ভরসা করিনি
• fallback বাইরে আর নতুনটি @supports-এর ভেতরে কি না দেখেছি; একই property দুইবার থাকলে পুরোনোটি আগে
• @supports-এ gird-এর মতো ইচ্ছাকৃত ভুল বানান লিখে fallback-এর চেহারা DevTools-এ দেখেছি
• অন্তত Blink, Gecko আর WebKit — তিন ইঞ্জিনে, আর একটি আসল পুরোনো ফোনে পাতা খুলেছি; JavaScript বন্ধ করেও মূল কাজ চালিয়েছি
• HTML validator.w3.org-এ আর Lighthouse-এ দিয়েছি; অপ্রয়োজনীয় prefix আর পুরোনো polyfill মুছেছি