Petunjuk dan konteks
Tim produk menginginkan dinding gambar masonry: kartu memiliki tinggi yang bervariasi, desktop menggunakan banyak kolom, ponsel menggunakan satu kolom, dan konten harus berfungsi untuk pengguna keyboard serta pembaca layar (screen reader). CSS Grid Level 3 sedang mendefinisikan tata letak masonry, tetapi sintaksis dan dukungan browser masih memerlukan verifikasi. Bandingkan pendekatan native CSS, columns, dan skrip, lalu rancang rencana fallback dan pengujian.
Apa yang sedang diuji oleh pewawancara
- Memisahkan penataan visual dari DOM, urutan membaca, dan urutan fokus.
- Menggunakan deteksi fitur dan matriks dukungan alih-alih asumsi berbasis nama browser.
- Menangani dimensi gambar, CLS, jumlah kolom responsif, virtualisasi, dan biaya reflow.
- Menyertakan kriteria penerimaan untuk kondisi no-script, keyboard, pembaca layar, zoom, dan cetak.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah kartu harus mengikuti waktu publikasi dan prioritas, atau bolehkah urutan visual kolom berubah?
- Apakah masonry hanya bersifat dekoratif, atau pengguna harus membaca dan mengoperasikan konten secara berurutan?
- Batasan browser, no-script, dan SEO apa saja yang berlaku?
- Apakah daftarnya cukup besar sehingga membutuhkan virtualisasi, penomoran halaman (pagination), atau lazy loading?
- Apakah fitur drag-and-drop, penyisipan, tinggi dinamis, dan pencetakan diperlukan?
Kerangka jawaban 30 detik
Saya akan mempertahankan urutan DOM semantik tetap dan menggunakan CSS hanya untuk peningkatan visual. Gunakan @supports dan matriks browser nyata untuk memilih masonry jika didukung; jika tidak, beralihlah ke Grid biasa atau columns dan terima perbedaan ruang kosong (whitespace). Reservasikan dimensi gambar untuk mengurangi layout shift, dan jangan pernah menjadikan JavaScript sebagai satu-satunya jalur aksesibilitas. Uji keyboard, pembaca layar, zoom, cetak, skrip yang dinonaktifkan, dan daftar panjang untuk memastikan urutan konten yang konsisten.
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan pertukaran (trade-off) masonry
Masonry menata item di sepanjang satu sumbu ke dalam track grid sambil merapatkan sumbu lainnya. Ini mengurangi ruang kosong dan meningkatkan kepadatan visual; cara ini tidak secara otomatis menyelesaikan urutan membaca, pergerakan fokus, atau pagination yang dapat diprediksi. Ubah batasan produk tersebut menjadi kriteria penerimaan sebelum memilih implementasi.
Langkah 2: Pertahankan semantik dan urutan fokus
Render tautan, tombol, dan judul asli sesuai urutan bisnis. Jangan memindahkan node dengan skrip atau memperbaiki urutan visual dengan tabindex positif. Jika kolom visual berbeda dari urutan DOM, terima hal itu secara eksplisit atau gunakan Grid normal untuk mempertahankan pembacaan baris demi baris.
Langkah 3: Deteksi fitur dan lakukan fallback
Tempatkan sintaksis eksperimental di balik @supports dan uji dalam matriks target. Gunakan sintaksis masonry yang didukung spesifikasi saat tersedia; jika tidak, beralihlah ke display: grid, track tetap, atau columns. Pertahankan DOM, konten, dan interaksi yang sama pada fallback; hanya ruang kosong dan kepadatan penataan yang boleh berbeda.
Langkah 4: Tangani gambar dan tinggi dinamis
Kirimkan dimensi gambar atau aspect-ratio dari server dan gabungkan dengan lazy loading serta object-fit yang sesuai untuk mengurangi CLS. Pemuatan gambar, pertukaran font, dan pembaruan konten memicu reflow, jadi gunakan pagination atau virtualisasi untuk daftar yang panjang. Batasi frekuensi pengukuran skrip (throttle) dan hindari mencampur pembacaan serta penulisan tata letak yang memicu synchronous layout.
Langkah 5: Evaluasi performa dan pemeliharaan
Ukur first paint, scroll frame rate, waktu tata letak, memori, dan penyisipan daftar panjang secara terpisah untuk CSS, columns, dan skrip. Dokumentasikan perbedaan visual terkecil dan hindari menduplikasi aturan untuk setiap breakpoint. Aktifkan skrip hanya jika fitur drag-and-drop, animasi lintas kolom yang kompleks, atau persyaratan sistem lama (legacy) secara eksplisit benar-benar membutuhkannya.
Langkah 6: Cakup aksesibilitas dan penggunaan nonvisual
Lakukan navigasi tab melalui setiap item dan pastikan fokus tidak melompat secara acak. Gunakan pembaca layar untuk mengonfirmasi bahwa judul, tautan, dan teks alternatif mengikuti urutan DOM. Uji zoom 200%, kontras tinggi, reduced motion, cetak, dan skrip yang dinonaktifkan. Masonry tidak boleh menjadi satu-satunya cara untuk mengakses konten.
Langkah 7: Rilis dan pantau
Catat versi spesifikasi, matriks browser, dan kebijakan fallback. Pantau CLS, LCP, kesalahan skrip, overflow, dan penyelesaian interaksi kartu berdasarkan browser. Saat dukungan sintaksis berubah, putar ulang tangkapan layar dan kasus aksesibilitas dalam suatu eksperimen sebelum memperluas peluncuran.
Contoh jawaban berkualitas tinggi
Saya akan mempertahankan urutan DOM semantik dan memperlakukan masonry sebagai peningkatan visual. Gunakan @supports dan pengujian browser nyata untuk sintaksis spesifikasi; beralih ke Grid biasa atau columns dengan konten dan interaksi yang sama. Reservasikan dimensi gambar atau aspect-ratio untuk mengurangi CLS, dan gunakan pagination atau virtualisasi alih-alih pengukuran sinkron yang sering untuk daftar panjang. Pengujian keyboard, pembaca layar, zoom, cetak, dan no-script harus dapat mengakses konten dalam urutan DOM. Pantau CLS, kesalahan tata letak, dan penyelesaian interaksi berdasarkan browser, serta jadikan hasil replay dan aksesibilitas sebagai syarat sebelum memperbarui spesifikasi.
Kesalahan umum
- Mengoptimalkan kepadatan visual tetapi mengabaikan urutan DOM, fokus, dan pembaca layar.
- Mengasumsikan setiap browser modern mendukung sintaksis masonry yang sama tanpa
@supportsdan pengujian. - Memindahkan node dengan skrip atau
tabindexpositif untuk memperbaiki urutan. - Menghilangkan dimensi gambar sehingga menciptakan CLS dan reflow setelah pemuatan.
- Menambahkan skrip yang selalu aktif untuk kompatibilitas tanpa mengukur biaya tata letak dan memori.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa tidak menggunakan columns?
Columns dapat terlihat seperti masonry, tetapi konten dibagi berdasarkan kolom dan urutan membaca atau fokus mungkin berbeda dari urutan bisnis. Jika urutan itu penting, lebih baik gunakan Grid biasa atau terima adanya ruang kosong.
Pertanyaan lanjutan 2: Bagaimana cara mendeteksi dukungan masonry?
Gunakan @supports dan pengujian otomatis dalam matriks browser target, catat properti dan nilai persis yang lolos pengujian. Jangan menyimpulkan dukungan dari User-Agent atau label "browser modern".
Pertanyaan lanjutan 3: Bagaimana dengan menyisipkan kartu secara dinamis?
Pertahankan urutan penyisipan, reservasikan dimensi gambar, kelompokkan pembaruan dalam batch, dan hindari tata letak paksa (forced layout) per item. Daftar besar memerlukan pagination, virtualisasi, dan fokus yang dapat dipulihkan.
Pertanyaan lanjutan 4: Kapan fallback skrip dapat dibenarkan?
Ketika fitur drag-and-drop, animasi lintas kolom yang kompleks, atau persyaratan sistem lama yang eksplisit tidak dapat dipenuhi oleh CSS. Skrip tetap berfungsi sebagai peningkatan (enhancement) dan konten semantik harus tetap dapat diakses jika skrip gagal.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa tata letak visual tidak merusak aksesibilitas?
Operasikan setiap item dengan keyboard dan pembaca layar dalam urutan DOM, lalu uji zoom 200%, reduced motion, cetak, dan skrip yang dinonaktifkan. Jadikan hasilnya sebagai syarat kelulusan rilis (release gate).