Aturan yang melahirkan bug ini justru datang dari kliennya sendiri. Tanggal 18 Mei 2026 dia menegur bahwa responsif harus didesain mengikuti fungsi dan kegunaan tiap komponen, dan contoh yang dia pakai adalah avatar: di salah satu halaman avatarnya jadi melebar, padahal bentuk avatar seharusnya tetap lingkaran. Teguran itu ada latarnya. Beberapa ronde operasi responsif massal sebelumnya, tiga batch berisi 18, 12, dan 11 operasi, gagal secara visual karena memperlakukan semua anak flex dengan cara yang persis sama, dan dia menyebut hasilnya "jelek".
Dari situ dia menetapkan aturan yang mengikat sisa projek: tidak boleh ada hide_*, tidak boleh ada rotasi, setiap komponen harus terlihat di setiap breakpoint, dan kalau sebuah komponen lebih lebar dari viewport, komponennya diskalakan supaya muat. Aturannya masuk akal dari sisi produk. Konsekuensinya baru terasa di satu section.
Section itu berukuran 1008×395, sebuah diagram radial berisi 12 ikon tool dan 6 garis penghubung, dengan anak-anak yang absolutely positioned di koordinat piksel mati. Catatan resep responsif projek itu menuliskan penyusutan 1008 ke 375 sebagai scale(0.37) yang tampil di 375×147. Yang akhirnya terpasang 0.36. Hitungannya gampang diulang: 1008 × 0.36 = 362.88, jadi lebar visualnya sekitar 363px di viewport 375. Secara visual itu benar. Diagramnya muat, orientasi lanskapnya utuh, tidak ada yang perlu diperbesar dulu supaya terbaca.
Yang tidak benar adalah semua yang berdiri di sebelahnya.
Visualnya menyusut, layoutnya tidak
Diagram itu tinggal di dalam sebuah induk flex bersama dua saudara: satu grup judul dan satu CTA. Di viewport 375, diagramnya kelihatan 363px, tapi induk flex-nya tetap terkunci di lebar 1008px, dan kedua saudaranya terdorong ke kanan sampai keluar layar. Jadi ada dua kebenaran yang berbeda di halaman yang sama: mata melihat 363, layout menghitung 1008.
Tumpukannya CSS di atas Elementor di atas WordPress, tapi tidak satu pun dari ketiganya yang salah di sini. Yang salah adalah asumsi saya bahwa scale() mengubah ukuran elemen.
scale() mengecat, bukan memahat
transform: scale() itu murni visual. Kotak layout elemennya tetap memegang dimensi aslinya, 1008px, jadi flexbox tetap menata saudara-saudaranya melawan lebar yang belum diskalakan. Transform terjadi belakangan, setelah layout selesai dihitung, dan ia tidak pernah mundur untuk memberi tahu flexbox bahwa isinya sekarang cuma sepertiga lebar tadi.
Ini alasan kenapa memaksakan width_mobile yang kecil di diagramnya bukan jalan keluar. Transform-nya justru butuh kotak asli itu untuk menskalakan sesuatu yang benar. Kecilkan kotaknya, dan diagram yang di dalamnya ikut berantakan karena anak-anaknya diposisikan di koordinat absolut yang mengacu ke lebar 1008.
Menahan kotaknya, lalu menggeser kotaknya
Keputusan yang saya ambil adalah membiarkan width_mobile tetap 1008 dan mengompensasi kelebihannya dengan margin kiri negatif yang eksplisit di ketiga anak section, supaya semuanya kembali terpusat di viewport 375.
Angkanya bisa diturunkan sendiri. Kalau kotak selebar 1008 itu mulai dari tepi kiri viewport 375, kelebihannya 1008 - 375 = 633px, dan separuhnya 316.5px per sisi. Yang saya pasang -320, jadi sekitar 3.5px lebih jauh ke kiri dari titik tengah teoretis. Toleransinya ada, karena visual 363px di dalam viewport 375 masih menyisakan 375 - 363 = 12px, enam piksel di tiap sisi.
Satu detail Elementor yang gampang bikin perubahan terasa tidak nyantol: container memakai kunci margin, sedangkan widget memakai kunci _margin. Diagram dan grup judulnya container, CTA-nya widget, jadi kuncinya beda walau maksudnya sama.
radialDiagram.width_mobile = 1008 // kotak asli ditahan untuk transform
radialDiagram.margin_mobile.left = -320
radialTitleGroup.margin_mobile.left = -320
radialCta._margin_mobile.left = -320 // widget pakai _margin
radialCta._margin_mobile.top = 60 // jarak dari diagram yang sudah diskalakan
Trik ini cuma dipasang di breakpoint mobile. Tablet 1024 dan desktop sudah benar tanpa margin negatif sama sekali, dan menambahkannya di sana hanya akan merusak yang sudah jalan.
Verifikasi
Hasil akhirnya saya periksa di empat viewport, 375, 768, 1024, dan 1440, dengan nol overflow. Perbaikan margin negatif ini tercatat di memory projek sebagai sudah terverifikasi, bukan sekadar usulan, dan itu bedanya besar untuk trik yang kelihatan serapuh angka -320.
Prosedur yang saya pegang untuk semua kerja responsif di projek itu memang bukan sekadar cek overflow. Setelah setiap perubahan, ambil screenshot di viewport sasaran lalu periksa keutuhan bentuk tiap jenis elemen satu per satu. Overflow nol tidak berarti avatarnya masih bulat.
Pelajaran
Kasus ini masuk ke catatan resep projek sebagai jebakan nomor 20 dari total akhir 21. Yang saya bawa keluar dari sana ada tiga.
Pertama, transform dan layout hidup di dua lapisan yang berbeda, dan flexbox cuma melihat lapisan bawah. Kalau sebuah elemen diskalakan tapi tetangganya berperilaku seolah elemen itu masih sebesar aslinya, kamu tidak sedang melihat bug flexbox, kamu sedang melihat definisi transform bekerja sesuai spesifikasinya.
Kedua, resep umum untuk container di projek itu adalah desktop pakai px tetap dan mobile atau tablet pakai lebar 100% viewport, dipasangkan dengan _flex_size: none supaya tidak menciut. Tapi resep umum tetap resep umum. Aturan pukul rata "semua container width 100% di mobile" tidak bisa dipercaya, karena itu berlaku untuk container layout, bukan untuk container avatar, ikon, atau dekorasi yang justru harus mempertahankan aspeknya.
Ketiga, dan ini yang paling sering saya lupakan waktu mengerjakan batch besar: menumpuk vertikal lalu mengecilkan saja tidak pernah cukup. Avatar harus tetap lingkaran, ikon harus menjaga aspeknya, pill harus tetap pill, tombol harus tetap bisa disentuh. Kerja responsif itu desain ulang per semantik komponen, dan diagram radial selebar 1008px adalah komponen yang semantiknya menolak dipotong, disembunyikan, atau diputar. Satu-satunya yang boleh dilakukan padanya adalah dikecilkan, lalu diberi tahu di mana harus berdiri.