Komposer Chat Desktop Ramping dengan Varian sm: Tailwind

Komposer chat di panel Tanya AI proyek saya dulu terlihat gendut di layar desktop. Satu baris textarea setinggi minimal 40 piksel, padding vertikal tambahan, ditambah dua tombol melingkar 44 piksel. Semua ukuran itu pas untuk ponsel karena jari butuh area sentuh yang lega. Tetapi di desktop, tempat kursor mouse bergerak presisi, baris input itu memakan ruang vertikal yang sebenarnya tidak perlu.

Dugaan pertama saya: perlu komponen terpisah untuk desktop, atau skrip kecil yang mendeteksi lebar layar lalu mengganti ukuran tombol. Padahal masalahnya sebatas padding dan ukuran ikon. Komponen kedua berarti dua tempat yang harus dirawat setiap kali behavior input berubah. Jawabannya ternyata cuma empat kelas responsif Tailwind di satu file, tanpa komponen baru dan tanpa JavaScript.

Empat Kelas Responsif di Satu File

Perubahan ada di file ChatInputBar.tsx. Setiap utility yang mengatur ukuran diberi pasangan prefix sm:, artinya berlaku mulai lebar layar 640 piksel ke atas. Ringkasannya seperti ini:

// wrapper field: padding rapat mulai lebar 640px
px-3 py-2 sm:py-1.5
// textarea: tinggi minimal 40px hanya untuk ponsel
min-h-[40px] sm:min-h-0 sm:py-1
// tombol kirim dan berhenti: 44px ponsel, 32px desktop
size-11 sm:size-8
// ikon panah ikut mengecil
size-5 sm:size-4

Detailnya per kelas: wrapper field mendapat varian padding rapat di desktop. Textarea menyimpan tinggi minimal 40 piksel untuk ponsel, lalu dilepaskan di layar besar lewat min-height nol dan padding kecil. Tombol kirim dan berhenti turun dari size-11 ke sm:size-8, dari 44 ke 32 piksel. Ikon panah ikut mengecil satu tingkat. Total diff empat baris, satu file.

Alasan kompleksitas terasa menggoda: komponen desktop versi ramping terdengar lebih "rapi" karena masing-masing layar punya bentuk sendiri. Pengalaman di commit lain pada panel yang sama menunjukkan sebaliknya. Setiap komponen kembaran menambah kontrak yang harus dijaga: dua tempat untuk mengubah placeholder, dua tempat untuk logika kirim, dua tempat untuk menguji. Varian breakpoint justru menaruh dua keadaan berdampingan dalam satu baris kelas, sehingga perbandingan visual antar ukuran cukup dilakukan dengan membaca kode.

Kenapa Base Class Justru untuk Mobile

Urutan ini mengikuti prinsip mobile-first Tailwind. Utility tanpa prefix berlaku di semua ukuran layar, sedangkan varian bertanda sm: baru aktif pada breakpoint small dan di atasnya [1]. Jadi kelas dasar adalah gaya ponsel, dan prefix menjadi pengecualian untuk layar lebih besar. Pembacaan yang keliru justru umum terjadi: banyak orang menganggap sm: berarti layar kecil, padahal artinya mulai dari ukuran kecil ke atas.

Ukuran dasar yang dipertahankan juga bukan angka sembarangan. size-11 menghasilkan tombol 44 x 44 piksel, sama dengan minimum yang dianjurkan kriteria WCAG 2.5.5 tentang target sentuh [2]. Panduan web.dev bahkan menyarankan sekitar 48 piksel independen perangkat karena kira-kira seukuran bantalan jari [3]. Mengorbankan angka itu di ponsel demi tampilan rapat berarti memindahkan masalah ke tempat yang salah: jari butuh target besar, mouse tidak.

Satu trade-off perlu diakui. Pendekatan ini memakai breakpoint lebar viewport, bukan media query jenis input seperti any-pointer: coarse yang direkomendasikan web.dev untuk membedakan sentuhan dan mouse [3]. Akibatnya, layar sentuh laptop dengan viewport di atas 640 piksel juga mendapat tombol 32 piksel. Untuk panel chat ini mayoritas pengguna desktop memakai mouse, jadi pilihan itu cukup. Bila kelak perlu membedakan berdasarkan jenis input, varian breakpoint tinggal ditukar media query pointer.

Hasil akhirnya: rapat di desktop, tetap aman disentuh di ponsel, dan tanpa JavaScript tambahan. Untuk sisi ukuran target sentuhnya, saya pernah menulis soal angka standar 44 piksel dan font 16 piksel di panel chat mobile: Tombol 44px, Font 16px: Angka Standar di Panel Chat Mobile.

Ujiannya juga murah. Lepaskan sementara semua varian sm: di file itu, dan tampilan desktop langsung kembali gendut; pasangkan kembali, dan desktop langsung rapat. Tidak ada state yang perlu disimulasikan, tidak ada mode debug. Perilaku lapangan menegaskan pilihan ini: di lebar penuh layar 27 inci, tinggi area input menyusut sekitar seperempatnya, cukup untuk menampilkan satu baris jawaban tambahan sebelum halaman perlu digulir.

Sumber

• [1] Tailwind CSS Docs: Responsive Design, diakses 2026-09-08
• [2] W3C WAI: Understanding SC 2.5.5 Target Size, diakses 2026-09-08
• [3] web.dev: Accessible Tap Targets, diakses 2026-09-08