Cross-browser Testing

Halaman yang tampak sempurna di satu browser belum selesai — pengguna datang melalui Chrome, Firefox, Safari, dan Edge, di desktop maupun ponsel, dan setiap perawatan browser menafsirkan CSS dengan detail yang bisa berbeda. Kabar baiknya, perbedaan besar semakin jarang: sebagian besar fitur modern kini berstatus Baseline, artinya tersedia di seluruh browser utama. Tugas pengujian lintas browser pun bergeser — dari menebak dukungan menjadi sistematis: menetapkan target, memeriksa fitur sebelum dipakai, dan menyusun fallback untuk yang belum merata. Peta status dukungan telah kita pelajari pada Chapter CSS Specifications dan Browser Support .

Menetapkan Target dan Memeriksa Dukungan #

Pengujian tanpa target akan tak berujung. Mulailah dari data, bukan tebakan: statistik pengguna proyek (misalnya dari alat analitik) menentukan browser dan versi yang layak didukung penuh. Dari sana, setiap fitur CSS yang hendak dipakai diperiksa dahulu di caniuse :

1. Buka caniuse.com dan cari nama fitur, misalnya container queries.
2. Baca baris dukungan: hijau berarti didukung, merah tidak, dan angka versi menunjukkan sejak kapan — bandingkan dengan target browser proyek.
3. Perhatikan catatan di bawah tabel; beberapa fitur didukung sebagian, misalnya tanpa nilai tertentu.
4. Bila dukungan belum penuh pada target, tulis fallback terlebih dahulu, baru peningkatan utamanya.

Kebiasaan kecil ini mengubah keputusan teknis dari “semoga jalan” menjadi keputusan terdokumentasi. Untuk fitur yang statusnya masih berkembang, pertahankan pola yang sama pada Chapter Progressive Enhancement : nilai dasar dulu, peningkatan kemudian.

Fallback dengan @supports #

Alat utama menulis fallback adalah at-rule @supports : bloknya diterapkan hanya bila browser mengenali kondisi yang dites. Nilai dasar ditulis di luar, peningkatannya di dalam:

/* Pola fallback untuk Chapter Cross-browser Testing.
   Nilai dasar berlaku di semua browser; blok @supports menambahkan
   peningkatan hanya bila fitur pendukungnya tersedia. */
.kartu {
  padding: 16px;
  background-color: rgb(226, 232, 240);
  border-radius: 8px;
}

@supports (content-visibility: auto) {
  .kartu {
    padding: 24px;
    background-color: rgb(2, 132, 199);
  }
}

Mari kita telaah kontraknya:

1. Aturan .kartu di luar blok: nilai dasar yang tidak menuntut fitur apa pun — padding 16px dan latar abu-abu terang. Semua browser, seberapa pun usianya, menerapkannya.
2. Kondisi @supports (content-visibility: auto): browser menjawab sendiri apakah ia mengenali properti tersebut — tanpa kita mendaftar nama atau versi browser.
3. Blok di dalamnya: peningkatan visual (padding 24px, latar biru) yang hanya menyala bila kondisi terpenuhi. Pada browser yang tidak mendukung, blok ini seluruhnya diabaikan dan nilai dasar tetap berlaku.

Hasil di Browser:

Kartu dasar tampil dengan padding 16px dan latar rgb(226, 232, 240).
Kartu modern membawa padding 24px dan latar biru rgb(2, 132, 199) —
bukti kondisi @supports terpenuhi di browser penguji (Chromium), karena
content-visibility didukung. Badge berstatus inline-block. Pada browser
tanpa dukungan content-visibility, kartu modern tetap tampil dengan
nilai dasarnya — tidak ada bagian halaman yang hilang.

Perlu diingat keterbatasannya: @supports menguji pengenalan sintaks, bukan kebenaran perilaku. Fitur yang “dikenali tetapi berperilaku berbeda” tetap lolos kondisi — untuk kasus seperti itu, uji perilakunya secara langsung.

Emulator dan Daftar Uji #

Setelah fallback tertata, sisa pekerjaannya adalah verifikasi nyata. Browser modern menyediakan emulator perangkat di DevTools (mode device pada Chrome, responsive design mode pada Firefox) yang berguna untuk memeriksa breakpoint dan ukuran sentuh dengan cepat — tetapi emulator meniru ukuran layar, bukan seluruh kelakukan perangkat, sehingga pengujian perangkat asli tetap diperlukan untuk fitur interaktif seperti hover dan gestur. Layanan uji lintas browser daring memperluas jangkauan tanpa memasang setiap browser.

Untuk menjaga pengujian tetap konsisten, pegang daftar periksa ringkas:

• Tampilan awal utuh pada semua browser target — tidak ada blok konten yang hilang.
• Layout pada lebar paling sempit dan paling lebar dari target.
• Font alternatif tampil wajar sebelum web font selesai dimuat.
• Semua state interaksi: :hover, :focus-visible, dan :disabled.
• Bila memakai fitur berkembang: matikan dukungannya (misalnya via konfigurasi perbrowser) dan pastikan fallback menyalakan pengalaman yang layak.

Dengan target yang jelas, fallback yang teruji, dan daftar periksa yang bisa diulang, pengujian lintas browser berhenti menjadi momok menjelang rilis — dan menjadi rutinitas yang pendek dan terkendali.

/* Pola fallback untuk Chapter Cross-browser Testing.
   Nilai dasar berlaku di semua browser; blok @supports menambahkan
   peningkatan hanya bila fitur pendukungnya tersedia. */
.kartu {
  padding: 16px;
  background-color: rgb(226, 232, 240);
  border-radius: 8px;
}

@supports (content-visibility: auto) {
  .kartu {
    padding: 24px;
    background-color: rgb(2, 132, 199);
  }
}