Apa Itu CSS Container Queries? Panduan Lengkap untuk Desain Responsif Berbasis Komponen

Masalah yang Diciptakan untuk Dipecahkan oleh Container Queries

Untuk memahami mengapa container queries penting, ada baiknya kita memahami keterbatasan spesifik dari media queries yang membuatnya diperlukan. Media query hanya mengetahui satu hal, yaitu seperti ukuran viewport, atau karakteristik tertentu dari perangkat dan preferensi pengguna, seperti apakah seseorang telah meminta pengurangan gerakan atau skema warna gelap. Media query sama sekali tidak mengetahui seberapa besar atau kecil setiap elemen individual di halaman tersebut. Ini berfungsi dengan baik selama setiap komponen di halaman diharapkan berperilaku sama di setiap titik dalam tata letak — tetapi antarmuka nyata jarang dibangun seperti itu.

Pertimbangkan komponen kartu produk yang digunakan di seluruh situs e-commerce. Di grid utama, mungkin ada banyak ruang dan dapat menampilkan gambar besar, deskripsi lengkap, dan harga berdampingan. Ditempatkan di sidebar "produk terkait" yang sempit, kartu yang sama perlu menumpuk kontennya secara vertikal dan mengecilkan gambarnya, karena sidebar tersebut tidak selebar kolom grid utama, meskipun viewport browser itu sendiri tidak berubah sama sekali. Solusi berbasis media query murni tidak memiliki cara untuk mengekspresikan perbedaan ini dengan jelas — viewport memiliki lebar yang sama dalam kedua kasus, sehingga breakpoint media query akan aktif (atau tidak aktif) secara identik untuk kedua penempatan, terlepas dari berapa banyak ruang sebenarnya yang tersedia untuk setiap instance kartu. Secara historis, developer mengatasi hal ini dengan class CSS duplikat untuk konteks yang berbeda, pengamat perubahan ukuran JavaScript yang rapuh, atau hanya menerima bahwa komponen tertentu akan terlihat salah di tempat tertentu. Container query ada khusus untuk menghilangkan seluruh kategori solusi sementara tersebut.

Apa Sebenarnya Itu Container Queries

Container query adalah aturan CSS yang menerapkan gaya pada suatu elemen berdasarkan ukuran — atau, baru-baru ini, karakteristik lain — dari elemen induk yang menampungnya, bukan berdasarkan ukuran viewport browser. Sintaksnya sengaja meniru media query dengan sangat mirip, karena logika dasarnya secara konseptual identik, yaitu definisikan suatu kondisi, dan terapkan serangkaian gaya hanya ketika kondisi tersebut benar. Perbedaannya hanyalah apa yang diukur — dimensi kontainer, bukan viewport.

Menggunakan container query membutuhkan dua langkah berbeda, dan melewatkan langkah pertama adalah alasan paling umum mengapa container query baru gagal berfungsi tanpa melakukan apa pun. Pertama, kita harus secara eksplisit menyatakan bahwa suatu elemen adalah kontainer, menggunakan properti container-type, yang paling umum diatur ke inline-size, yang memberi tahu browser untuk menetapkan konteks penampungan berdasarkan lebar elemen. Kita dapat secara opsional memberi nama pada kontainer tersebut dengan container-name, yang menjadi berguna setelah kita menumpuk beberapa kontainer dan membutuhkan query untuk menargetkan kontainer tertentu daripada kontainer mana pun yang kebetulan terdekat. Kedua, setelah sebuah kontainer ada di suatu tempat dalam rantai leluhur, kita menulis aturan @container yang menargetkan keturunannya, menggunakan sintaks perbandingan lebar dan tinggi yang sama seperti yang dikenal dari @media — @container (min-width: 400px) { ... } — dan gaya di dalam blok tersebut hanya berlaku ketika kontainer yang disebutkan atau terdekat benar-benar memenuhi kondisi tersebut.

Penting untuk menjelaskan satu detail yang membingungkan banyak orang yang pertama kali menemui hal ini: aturan @container hanya dapat memberi gaya pada keturunan kontainer, tidak pernah pada elemen kontainer itu sendiri. Jika kita membutuhkan elemen untuk merespons ukurannya sendiri, pola standarnya adalah membungkusnya dalam elemen tambahan, menjadikan pembungkus luar tersebut sebagai kontainer sebenarnya, dan menerapkan gaya responsif ukuran ke elemen dalam sebagai gantinya.

Unit Kueri Kontainer: Ukuran Fleksibel Tanpa Ketergantungan Viewport

Bersamaan dengan aturan @container itu sendiri, kueri kontainer memperkenalkan keluarga baru unit panjang CSS yang skalanya relatif terhadap dimensi kontainer, bukan viewport. cqw dan cqh masing-masing mewakili persentase lebar dan tinggi kontainer, sedangkan cqi dan cqb mewakili dimensi inline dan blok kontainer — perbedaan yang penting untuk mode penulisan dan bahasa yang tidak mengalir secara ketat dari kiri ke kanan, atas ke bawah. cqmin dan cqmax akan menghasilkan nilai mana pun dari lebar atau tinggi kontainer yang lebih kecil atau lebih besar, memberi kita satu unit yang beradaptasi secara masuk akal terlepas dari rasio aspek spesifik kontainer.

Unit-unit ini membuka desain komponen yang benar-benar fleksibel dengan cara yang sebelumnya sulit dicapai dengan rapi. Judul di dalam komponen kartu dapat diatur ukurannya dalam satuan cqi sehingga ukuran font-nya berskala secara proporsional dengan lebar kartu itu sendiri — kartu yang ditampilkan sempit di sidebar secara otomatis mendapatkan teks yang lebih kecil, dan kartu yang sama yang ditampilkan lebar di grid konten utama secara otomatis mendapatkan teks yang lebih besar, tanpa breakpoint, tanpa kelas tambahan, dan tanpa JavaScript sama sekali. Ini adalah pendekatan yang berbeda secara signifikan dan jauh lebih elegan daripada teknik lama yang menggabungkan satuan viewport dengan clamp() untuk mendekati tipografi fluid, karena satuan query kontainer terikat pada konteks lokal aktual tempat komponen ditampilkan, bukan pada proxy tidak langsung berdasarkan ukuran jendela secara keseluruhan.

Style Query: Menanggapi Lebih dari Sekadar Ukuran

Ukuran adalah kondisi yang paling umum dan paling banyak didukung untuk container query, tetapi bukan satu-satunya. Style query, yang ditulis menggunakan fungsi style() di dalam aturan @container, memungkinkan kita menerapkan gaya berdasarkan nilai properti kustom CSS yang ditetapkan pada kontainer, bukan dimensinya. Ini membuka kasus penggunaan yang benar-benar berbeda, yaitu theming. Sebuah kontainer dapat mendeklarasikan properti kustom seperti --theme: dark, dan setiap turunannya kemudian dapat diberi gaya secara kondisional dengan @container style(--theme: dark) { ... }, sehingga memungkinkan seluruh bagian halaman untuk mengubah tema visualnya dengan mengubah satu variabel pada elemen pembungkus, dengan setiap detail bertema secara otomatis mengalir ke komponen apa pun yang ada di dalamnya.

Satu detail yang membedakan style query dari size query perlu diperhatikan: setiap elemen secara implisit merupakan target yang valid untuk style query, tanpa perlu secara eksplisit mendeklarasikan container-type seperti yang dibutuhkan oleh size query — karena style query sama sekali tidak mengukur dimensi, tidak perlu menetapkan konteks containment ukuran terlebih dahulu. Mulai tahun 2026, style query untuk properti kustom didukung di Chrome, Edge, dan Safari, dengan dukungan Firefox hadir sebagai bagian dari inisiatif standardisasi lintas browser Interop 2026 yang lebih luas — artinya fitur ini hampir lengkap, tetapi belum universal, dan saat ini harus diperlakukan sebagai peningkatan bertahap daripada ketergantungan mutlak untuk apa pun yang perlu berfungsi dengan andal di mana pun saat ini.

Penambahan Terbaru: Scroll-State Query dan Anchored Query

Selain ukuran dan gaya, spesifikasi container query terus berkembang ke wilayah yang lebih khusus. Scroll-state query memungkinkan gaya diterapkan pada turunan kontainer berdasarkan posisi gulir atau status snap gulir kontainer tersebut — misalnya, menata elemen secara berbeda tergantung pada apakah elemen tersebut saat ini terlihat dalam carousel yang bergulir secara horizontal, atau apakah kontainer telah digulirkan menjauh dari posisi awalnya. Anchored container query, kemampuan yang lebih khusus lagi, memungkinkan untuk menanyakan apakah sebuah kontainer diposisikan sebagai jangkar dan saat ini memiliki fallback position-try yang diterapkan padanya, yang penting untuk sistem pemosisian jangkar CSS yang lebih baru yang digunakan untuk menambatkan elemen mengambang seperti tooltip dan popover ke titik referensi tertentu di halaman.

Kedua hal ini mewakili konsep kueri kontainer yang meluas jauh melampaui titik awalnya yang berbasis ukuran, dan keduanya menggambarkan pola yang lebih luas, yaitu begitu mekanisme dasar "biarkan elemen merespons sesuatu tentang kontainernya, bukan viewport" ditetapkan, ternyata itu menjadi fondasi yang benar-benar berguna untuk membangun beberapa kemampuan berbeda yang terkait di atasnya, bukan hanya fitur sekali pakai untuk tata letak kartu.

Container Queries vs. Media Queries: Bukan Pengganti

Begitu kita memahami apa yang ditawarkan container queries, kita mungkin tergoda untuk menganggapnya sebagai pengganti media queries sepenuhnya. Itu adalah kesalahan, dan perlu dijelaskan secara langsung mengapa. Media queries dan container queries menjawab pertanyaan yang benar-benar berbeda, dan stylesheet modern yang dibangun dengan baik menggunakan keduanya, secara sengaja, untuk pekerjaan spesifik yang sesuai untuk masing-masingnya.

Media queries tetap menjadi alat yang tepat untuk keputusan tata letak tingkat halaman dan untuk menanggapi karakteristik yang hanya ada di tingkat perangkat atau browser secara keseluruhan — apakah seluruh halaman harus beralih dari tata letak sidebar ke bilah navigasi bawah, apakah seluruh situs harus menghormati preferensi pengguna untuk pengurangan gerakan atau skema warna gelap, apakah gaya cetak harus diterapkan. Ini adalah pertanyaan global, di seluruh halaman, atau yang didorong oleh preferensi pengguna yang tidak ada hubungannya dengan ukuran lokal komponen individual mana pun, dan container queries tidak memiliki kemampuan untuk menjawabnya, karena container query tidak memiliki visibilitas ke apa pun di luar konteks penampungannya sendiri. Container query adalah alat yang tepat khusus untuk responsivitas tingkat komponen — apakah kartu tertentu, elemen navigasi tertentu, atau widget tertentu harus mengubah tata letak internalnya berdasarkan seberapa banyak ruang yang sebenarnya diberikan dalam konteksnya saat ini. Panduan praktis yang muncul dengan jelas saat ini cukup mudah, yaitu jika pertanyaannya adalah "apakah tata letak internal komponen ini harus berubah berdasarkan di mana ia ditempatkan," gunakan container query; jika pertanyaannya adalah "apakah struktur keseluruhan halaman harus berubah," gunakan media query.

Dukungan Browser

Kueri ukuran kontainer telah mencapai apa yang biasanya digambarkan sebagai dukungan dasar, artinya kueri tersebut telah tersedia secara andal di Chrome, Firefox, Safari, dan Edge sejak tahun 2023, dengan cakupan browser global saat ini melebihi 93 hingga 96 persen tergantung pada pengukuran spesifiknya. Tingkat dukungan ini umumnya dianggap siap produksi tanpa perlu polyfill atau mekanisme fallback di sebagian besar proyek, dan unit panjang kueri kontainer memiliki tingkat dukungan lintas browser yang solid yang sama.

Style query masih agak tertinggal dalam kurva adopsi. Saat ini, kueri tersebut berfungsi dengan andal di Chrome, Edge, dan Safari, dengan dukungan Firefox yang hadir sebagai bagian dari inisiatif Interop 2026 — artinya kesamaan lintas browser universal penuh untuk kueri gaya khususnya sudah dekat tetapi belum sepenuhnya selesai pada saat penulisan ini. Untuk proyek apa pun yang perlu mendukung sebagian kecil browser lama yang sama sekali tidak mendukung kueri kontainer, pendekatan standarnya adalah menggunakan pemeriksaan fitur @supports (container-type: inline-size), yang menyediakan default yang masuk akal, biasanya tata letak bertumpuk yang lebih sederhana, yang diterapkan secara otomatis ketika kueri kontainer tidak tersedia, dengan gaya responsif kontainer yang disempurnakan ditambahkan di atasnya hanya ketika browser benar-benar mendukungnya. Ini menghasilkan jalur degradasi yang benar-benar elegan — tidak ada yang rusak bagi pengguna di browser lama, mereka hanya tidak menerima perilaku adaptif yang lebih canggih.

Pertimbangan Kinerja dan Praktik Terbaik

Container query tidak bebas dari perspektif kinerja, dan ada baiknya memahami panduan praktis yang muncul seputar penggunaannya secara bertanggung jawab. Setiap elemen yang dideklarasikan sebagai kontainer menetapkan konteks penampungan yang harus dievaluasi oleh browser, dan membungkus setiap elemen dalam kontainer "hanya untuk berjaga-jaga" menciptakan beban tambahan yang tidak perlu tanpa manfaat yang sesuai. Aturan yang masuk akal yang telah menjadi praktik standar, yaitu hanya deklarasikan container-type pada elemen yang anak-anaknya benar-benar memiliki aturan @container yang menargetkannya. Jika tidak ada apa pun di dalam elemen yang benar-benar menanyakan ukurannya, tidak ada alasan bagi elemen tersebut untuk menjadi kontainer sama sekali.

Kontainer yang bersarang dalam membutuhkan kehati-hatian yang serupa. Beberapa tingkat penampungan bersarang sangat wajar dan umum dalam hierarki komponen nyata, tetapi membungkus setiap lapisan pohon komponen yang bersarang dalam dalam kontainernya sendiri, masing-masing dengan batas penampungannya sendiri untuk dilacak dan dievaluasi oleh browser, akan menambah beban tambahan yang nyata dan dapat dihindari dalam skala besar. Unit kueri kontainer itu sendiri secara komputasi tidak mahal untuk digunakan, jadi tidak ada biaya kinerja yang berarti secara khusus dari penggunaan cqw atau cqi dibandingkan unit yang lebih tradisional — biaya, jika ada, secara khusus berasal dari penerapan container-type yang berlebihan pada elemen yang tidak membutuhkannya, bukan dari mekanisme kueri itu sendiri.

Container-First Design: Pergeseran Nyata dalam Praktik

Ketersediaan container query telah menghasilkan pergeseran nyata dalam cara developer frontend berpengalaman mendekati desain komponen, yang sering digambarkan sebagai pemikiran "container-first". Alih-alih mendesain komponen dengan mempertimbangkan breakpoint tampilan halaman secara keseluruhan, praktik ini semakin melibatkan desain komponen secara terisolasi, dan mendefinisikan breakpoint internalnya sendiri berdasarkan titik di mana desain spesifiknya benar-benar mulai rusak — teks kartu yang terbungkus dengan canggung, ikon dan label yang tumpang tindih — daripada meminjam breakpoint tingkat halaman yang sewenang-wenang seperti 768px atau 1024px yang tidak memiliki hubungan nyata dengan konten komponen spesifik tersebut.

Pergeseran ini telah menghasilkan manfaat yang terukur dan nyata dalam basis kode nyata. Tim yang telah memigrasikan komponen yang ada dari sistem override berbasis viewport yang rumit ke container query telah melaporkan pengurangan substansial dalam kompleksitas CSS secara keseluruhan — salah satu contoh yang banyak dikutip melibatkan proyek produksi yang menghapus sekitar 600 baris CSS setelah beralih ke container query, bukan melalui penulisan ulang besar-besaran, tetapi hanya dengan menghapus override media query berlapis dan saling bersaing yang telah terakumulasi selama bertahun-tahun khusus untuk menangani komponen yang muncul dalam berbagai konteks yang berbeda. Ketika sebuah komponen memiliki logika responsifnya sendiri sepenuhnya, daripada bergantung pada pengetahuan tentang halaman tempat komponen tersebut ditempatkan, stylesheet yang dihasilkan menjadi jauh lebih mudah dibaca, dipelihara, dan diserahkan di seluruh tim, karena perilaku komponen sepenuhnya mandiri daripada tersebar di berbagai aturan override tingkat halaman yang ditulis oleh siapa pun yang kebetulan membutuhkan perbaikan pada saat itu.

Framework CSS modern yang mengutamakan utilitas telah merangkul pergeseran ini secara langsung — Tailwind CSS, mulai dari versi 3.4 dan seterusnya, menyertakan dukungan container query asli melalui utilitas @container khusus dan varian bergaya breakpoint seperti @md: dan @lg: yang berfungsi persis seperti awalan responsif Tailwind yang sudah dikenal, kecuali mengkueri kontainer terdekat alih-alih viewport, yang mencerminkan betapa menyeluruhnya pola ini telah bergeser dari kemampuan baru menjadi praktik standar yang diharapkan.

Jadi, CSS container queries memecahkan masalah yang pada dasarnya tidak pernah dirancang untuk diatasi oleh media queries, yaitu membuat komponen individual benar-benar menyadari, dan responsif terhadap, ruang aktual yang diberikan kepadanya, terlepas dari di mana pun di halaman atau di berapa banyak konteks berbeda komponen tersebut muncul. Dengan container-type yang menetapkan konteks penampungan, aturan @container yang menerapkan gaya bersyarat berdasarkan ukuran konteks tersebut atau nilai properti kustom, dan unit container query seperti cqw dan cqi yang memungkinkan ukuran fluid yang terkait dengan konteks lokal daripada viewport keseluruhan, fitur ini memberi developer frontend alat yang benar-benar baru dan lebih tepat untuk membangun komponen yang benar-benar modular dan mandiri.