Fitur-fitur Modern HTML/CSS yang Kurang Dikenal

• Penyebab utama penurunan performa situs web belakangan ini adalah penggunaan JavaScript yang berlebihan dan skrip pelacakan, padahal dalam banyak kasus hal itu bisa cukup digantikan dengan HTML/CSS saja
• Fitur-fitur yang baru ditambahkan seperti CSS nesting, relative colors, unit viewport baru (lvh, svh, dvh) memungkinkan penyelesaian sederhana untuk hal-hal yang dulu bergantung pada JS atau preprocessor
• CSS bukan sekadar alat styling, melainkan bahasa yang kuat yang mampu mewujudkan animasi, validasi input, tema dark mode, hingga menu accordion
• Dari sisi performa, CSS berjalan dengan akselerasi GPU dan di thread terpisah sehingga lebih mulus dan efisien daripada JS untuk animasi dan efek transisi
• Penulis menekankan CSS bukan hanya alat praktis, tetapi juga sarana ekspresi dan seni, serta mendorong para web developer untuk lebih memanfaatkan potensi CSS modern

---

Pendahuluan: Kompleksitas web, dan upaya baru

• Banyak situs web mengalami penurunan performa dan kompleksitas akibat penggunaan framework JavaScript yang berlebihan
  • Aplikasi React membutuhkan beberapa detik untuk memuat, dan NextJS memunculkan hydration error
  • Folder node_modules dapat memakan ukuran hingga beberapa gigabita
• Bahkan tanpa JavaScript, HTML dan CSS saja sudah bisa mewujudkan fitur yang kuat
  • Selain keranjang belanja e-commerce yang kompleks atau dashboard, JavaScript mungkin tidak selalu wajib
• Tulisan ini memperkenalkan fitur-fitur terbaru CSS dan mendorong developer mengeksplorasi berbagai kemungkinan tanpa hanya bergantung pada JavaScript

Kesalahpahaman dan persepsi tentang CSS

Apakah CSS benar-benar sulit dan tidak nyaman digunakan?

• Persepsi negatif terhadap CSS berasal dari kurangnya pembelajaran dasar
  • Banyak developer melewati dasar-dasar CSS dan fokus pada JavaScript atau TypeScript
  • CSS bukan sekadar alat styling, melainkan bahasa khusus domain yang menyediakan kemampuan kuat
• CSS memungkinkan pembuatan layout kompleks dengan mudah lewat alat seperti flexbox
  • Contoh: memusatkan div cukup mudah dengan display: flex dan justify-content: center
  • Developer tools di browser menyediakan widget untuk menyesuaikan properti flexbox secara visual
• Jika hanya mendalami satu sisi saja (misalnya JS) dan mengabaikan CSS, wajar bila CSS terasa berat

Susahnya menulis CSS, dan perubahannya

• Dulu CSS memang tidak terlalu nyaman, sehingga lahirlah alat seperti Sass dan Tailwind
  • Contoh: harus mengelola rantai selector panjang seperti .post > .buttons .like:hover
• Belakangan ini ditambahkan fitur peningkatan kualitas (seperti nesting), sehingga pengembangan dengan CSS murni menjadi jauh lebih nyaman
  • CSS nesting mengumpulkan style yang saling terkait di satu tempat sehingga keterbacaan meningkat
    • Contoh: .post { & > .buttons { .like { &:hover { ... } } } }
    • Hubungan parent-child jadi lebih jelas, sehingga nama class bisa dibuat lebih pendek dan sederhana
• Relative colors memudahkan penyesuaian warna
  • Kecerahan dapat diatur dengan hsl(from #123456 h s calc(l + 10))
  • Menghasilkan warna dinamis dengan mencampur dua warna lewat color-mix()
• Sintaks rentang media query memungkinkan penetapan kondisi yang intuitif seperti (width <= 768px)
• Unit lh mendukung styling yang menyesuaikan tinggi baris
• Properti scrollbar-gutter menyelesaikan masalah pergeseran layout akibat scrollbar
• Baseline menjamin kompatibilitas fitur di browser utama
  • newly available berarti berfungsi di browser modern
  • widely available berarti didukung hingga browser dari 2,5 tahun lalu
  • Contoh: CSS nesting didukung di semua browser sejak Desember 2023

Mengapa membangun hanya dengan CSS/HTML?

• Sebagian pengguna menonaktifkan JavaScript secara default karena alasan keamanan, privasi, dan sebagainya
• Jika situs disajikan hanya dengan CSS/HTML murni, kemungkinan besar pengguna seperti ini tetap bisa memakainya
• Dari sudut pandang developer maupun pengguna, penggunaan CSS/HTML saja memberi keuntungan besar dalam hal kecepatan, aksesibilitas, serta penggunaan CPU/baterai
  • Animasi CSS berjalan di compositor thread, sehingga mengurangi beban CPU
  • JavaScript berjalan melalui event loop dan dapat menimbulkan sedikit latensi
• Aksesibilitas dan kemudahan penggunaan juga meningkat
  • Efek hover pada tombol, animasi toast, dan validasi input bisa dibuat dengan mudah memakai CSS

Contoh nyata dan fitur-fitur utama CSS

Membuat animasi awal yang natural dengan @starting-style

• Dulu animasi kemunculan elemen memerlukan struktur rumit seperti keyframes dan trigger JS
• Dengan hadirnya @starting-style, penentuan state awal menjadi sederhana. Animasi state awal elemen (misalnya fade-in) bisa dibuat dengan mudah
  • Diatur dengan transition: opacity 1s; @starting-style { opacity: 0; }
  • Berfungsi tanpa @keyframes atau JavaScript tambahan
• Cukup nyatakan state awal bersama transition agar animasi diterapkan secara natural
  • Contoh: menangani perubahan opacity dan posisi pesan toast dengan mulus

Pengaturan tema dark/light mode yang mudah

• color-scheme: light dark mengalihkan tema secara otomatis sesuai preferensi pengguna
• Fungsi light-dark(#000, #FFF) menentukan warna yang sesuai untuk mode terang/gelap
• Pemilihan tema oleh pengguna bisa didukung lewat radio button dan selector :has
  • Pergantian tema bisa dilakukan hanya dengan CSS tanpa JavaScript
  • Penyimpanan/pemuatan tema dengan JavaScript dapat ditambahkan secara opsional

Membuat UI kustom dengan radio/checkbox dan :has, :checked, dll.

• Interaksi kompleks seperti tab, accordion, dan toggle juga bisa dibuat tanpa JavaScript
• Radio button dapat diberi styling kustom dengan :checked dan :has
  • Contoh: menetapkan style tombol yang dipilih dengan label:has(input:checked)
  • Elemen input disembunyikan dengan opacity: 0, tetapi aksesibilitas screen reader tetap terjaga
• Elemen details cocok untuk membuat menu accordion seperti FAQ
  • Status buka tunggal dapat dikendalikan dengan atribut name
  • Animasi dapat ditambahkan berdasarkan state [open]

Validasi input dan refleksi state

• Dengan menggabungkan atribut HTML seperti pattern dan required serta pseudo-class CSS (:valid, :invalid, :user-valid, dll.), kita bisa memberi validasi real-time dan umpan balik visual
• Pengalaman pengguna meningkat lewat perubahan style seperti outline/border pada field input
• Atribut pattern di HTML memvalidasi isian field input
  • Contoh: \w{3,16} mengizinkan 3–16 huruf, angka, atau underscore
• :valid dan :invalid di CSS memberi styling sesuai validitas
  • :user-valid dan :user-invalid hanya menerapkan style setelah pengguna melakukan input
• Selector :has memungkinkan styling elemen lain berdasarkan state input
• Dalam beberapa kasus (misalnya syarat input yang kompleks), JS memang dibutuhkan, tetapi untuk kebanyakan hal CSS/HTML sudah cukup

Cara yang benar menggunakan unit viewport

• Unit vw/vh memiliki masalah akurasi di mobile karena address bar (navigation bar) dapat muncul dan menghilang
• Disarankan memakai unit viewport baru seperti lvh/svh/dvh (largest/smallest/dynamic viewport height)
  • lvh: untuk layar penuh (misalnya background penuh)
  • svh: untuk tombol, tautan, dan elemen lain yang harus selalu terlihat di layar
  • dvh: untuk mengalokasikan ukuran secara dinamis sesuai perubahan seperti scroll
• Overlay keyboard ditangani dengan properti interactive-widget atau VirtualKeyboard API
  • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
  • Di browser berbasis Chromium, gunakan navigator.virtualKeyboard.overlaysContent = true

Wishlist CSS (fitur yang masih kurang atau diharapkan)

• Blok yang dapat digunakan ulang: menerapkan class lain di dalam class (misalnya @apply border)
• Selector media query gabungan: menggabungkan @media dengan selector class
• Variabel nth-child: styling dinamis dengan span { --nth: nth-child(); }
• Selector nth-letter: styling huruf tertentu (misalnya p::nth-letter(2))
• Menghapus unit: membuat nilai tanpa unit dengan calc(100vw / 1px)
• Fungsi image(): mendukung warna fallback dan potongan gambar
• Tag style di dalam body: dukungan standar resmi untuk mengurangi masalah FOUC

Penutup: CSS, dan sisi artistik web

• CSS bukan sekadar alat, melainkan sarana ekspresi kreatif
• Alat AI atau build chain (linter, alat minifikasi) dapat membatasi kreativitas
• CSS memenuhi performa, aksesibilitas, dan ekspresi artistik sekaligus
• Tulisan ini dibuat dengan HTML/CSS tanpa JavaScript berukuran sekitar 49kB
  • Semua widget interaktif dan elemen visual dibuat secara manual
  • Contoh: CSS click game membuktikan kemungkinan CSS sebagai bahasa pemrograman

[duqduqduq]

Saya dulu full-stack, tetapi makin naik dalam karier rasanya makin tidak ada kesempatan mengerjakan FE, jadi selama sekitar 10 tahun saya nyaris tidak menyentuhnya. Belakangan saya sempat perlu memberi kuliah singkat di sebuah perusahaan dan mencoba melihatnya lagi sekalian untuk pengenalan singkat, dan ternyata perubahannya benar-benar mengejutkan. Kalau digabung dengan SCSS malah terasa lebih mantap. Tapi ranah CSS ini memang cukup unik. Mempelajarinya mudah, tetapi untuk menggunakannya sampai diakui benar-benar bagus menurut saya sangat ditentukan oleh selera estetika dan kreativitas masing-masing. Di era web yang makin mementingkan kegunaan dan desain, saya merasa sayang sekali nilai para publisher/front-end markup specialist belum mendapat apresiasi yang lebih tinggi.

[ahwjdekf]

Kali ini, sebagai kegiatan hobi mencicipi teknologi pengembangan web, saya mencoba membuat papan buletin dasar dari nol tanpa pengetahuan dasar sama sekali dengan menggunakan nextjs, authjs, tailwind, dan shadcn ... dan ternyata tingkat kesulitan belajar tertinggi ada di CSS.

[GN⁺]

Komentar Hacker News

• Saya bersyukur CSS kini punya fitur nesting, tetapi secara keseluruhan CSS benar-benar aneh, dan menurut saya pribadi ini bahasa yang buruk, mungkin karena saya tidak bisa memakainya dengan benar, tetapi terlalu rumit dan berantakan sampai rasanya seperti memindahkan rune tak dikenal ke sana-sini, sistem styling dan layout bercampur, tetapi relasi pewarisan dan inklusinya berbeda sehingga makin membingungkan, menurut saya menggabungkan styling dan layout adalah kesalahan, dan rasanya menambahkan fitur ke sistem yang dari dasarnya sudah rusak tidak mungkin menjadi solusi

  • Saya juga sudah mencari nafkah dengan CSS selama 10 tahun terakhir, tetapi CSS terasa seperti bukan bahasa yang benar-benar didesain, melainkan diperluas sedikit demi sedikit sesuai kebutuhan saat itu, modul baru hanya ditempel di atas properti lama sehingga saling bentrok atau sedikit berbeda, akibatnya debugging jadi sulit, contohnya box model dan layout flex yang bekerja berbeda, atau properti gap yang berperilaku berbeda di flex dan grid (tautan), sekali sebuah layout dibuat, secara praktis ia hampir jadi tetap, dan tanpa enkapsulasi kompleks berbasis native atau JS, sulit mengubahnya secara fleksibel, lalu muncullah masalah seperti ketebalan font yang berubah tak terduga atau menu mobile yang muncul juga di desktop
  • Saya tidak setuju, menurut saya alasan orang sering punya pandangan negatif tentang CSS adalah karena mereka tidak mempelajarinya dengan benar atau khususnya tidak memahami cascade dengan baik, saya dulu pernah mendalami spesifikasi CSS, dan itu membuat saya merasa CSS sebenarnya bahasa yang cukup dirancang dengan baik untuk tujuan memisahkan makna markup dari style
  • Saya rasa memisahkan styling dan layout itu mustahil, siapa pun yang pernah mengembangkan UI pasti merasakan bahwa keduanya pada dasarnya saling terikat dan saling bergantung, misalnya panjang atau ukuran teks, overflow, margin, padding, semuanya saling memengaruhi, mengubah border atau spacing suatu elemen juga mengubah ruang untuk konten di dalamnya, keduanya tidak bisa dipisahkan sepenuhnya
  • Menurut saya masalah sebenarnya pada CSS adalah cascading, dan kebanyakan pengembangan frontend modern justru berputar untuk mencegah cascade ini, komponenisasi UI adalah contohnya, layout adalah persoalan terpisah lagi, tetapi jadi lebih rumit karena kompatibilitas, kalau semua layout pada dasarnya hanya bekerja dengan flexbox atau grid, dan inline serta non-inline tidak dicampur dalam satu container, hasilnya akan jauh lebih baik, React Native bekerja persis seperti itu, dan di React Native style tidak melakukan cascade sehingga jauh lebih mudah dikelola
  • Semua itu benar, tetapi inilah yang kita punya sekarang, saya pernah berpikir apakah kita bisa membuat model yang lebih konsisten secara konseptual lalu mentranspilasikannya ke CSS, mungkin juga sistem layout yang lebih rapi bisa diimplementasikan secara matematis dengan container queries atau calc, bahasa preprocessor saat ini justru terasa seperti hanya menempelkan fitur yang juga belum matang di atas konsep CSS yang memang sudah belum tuntas, sehingga malah makin membingungkan

• Hal terburuk dari CSS menurut saya adalah banyak orang bahkan tidak benar-benar mempelajarinya, cuma dipaksa memakainya sehari atau sekitar itu lalu langsung punya opini yang sangat kuat

  • Saya juga pernah mengalami "satu hari" itu, saat membuat aplikasi podcast saya ingin membuat footer mengambang yang (1) selalu berada di bawah, (2) selalu terlihat, (3) tidak menutupi konten, dan (4) bisa dibuat tanpa hack terpisah, lalu saya sadar itu tidak mungkin di CSS, benar-benar sistem yang hebat
  • Saya belajar CSS 20 tahun lalu, dan kesimpulan saya adalah karena Cascading, CSS seharusnya diganti namanya menjadi Crappy Style Sheets, ketika banyak orang berkolaborasi, fenomena "mengubah sesuatu di sini lalu sesuatu aneh rusak di sana" adalah keadaan default, ciri khasnya adalah aturan rumit untuk meng-override aturan lain, dan itu bukan fondasi yang bagus, cara menargetkan secara rumit juga makin lama makin rumit sampai akhirnya jadi kode seperti .foo > .bar:nth-child(2n) ~ .baz, lalu itu merusak kode rekan kerja juga, membuat satu layout sederhana saja bisa bikin pusing, memang belakangan ini jauh membaik, tetapi sejak awal struktur yang berpusat pada cascade inilah masalahnya, kritik lain seperti sintaks itu relatif sepele, kalau praktis dan mudah dipakai sintaks biasanya masih bisa diterima, tetapi CSS tidak begitu, saya rasa membuat layout web seharusnya tidak menjadi profesi tersendiri
  • Soal pernyataan "banyak orang memakai CSS tanpa mempelajarinya", pendekatan bahwa orang harus mempelajari semua 20+ spesifikasi dulu baru layak memakainya terasa berlebihan, kalau orang mengalami masalah saat memakai suatu alat, kita seharusnya melihat apakah ada masalah pada alat itu, bukan menyalahkan penggunanya, alih-alih memaksa orang berhati-hati memakai gergaji, lebih masuk akal memasang fitur pengamannya

• Saya tidak terlalu tersentuh oleh argumen dalam tulisan ini bahwa "sebagian pengguna tidak menginginkan JavaScript", saya juga pengguna Arch dan sangat antusias dengan berbagai scripting dan crawling, tetapi fokus pada lingkungan "NoScript" tidak terasa terlalu penting, menurut saya itu preferensi kelompok yang sangat kecil sehingga pada umumnya bisa diabaikan, rasanya mirip era ketika orang bilang "10% masih memakai IE6", meskipun begitu saya tetap merasa ada banyak alasan lain yang jauh lebih kuat mengapa CSS lebih unggul, bagaimanapun ini bukan isu utama, hanya saja alur besarnya terasa seperti itu

  • Hal yang bisa saya lakukan secara deklaratif dalam beberapa baris CSS akan menjadi puluhan baris jika dilakukan secara imperatif di JS, plus lebih banyak perilaku aneh, masalah kompatibilitas framework, dan keterlambatan time-to-interactive, lingkungan NoScript hanya bonus, sejujurnya dalam hati saya justru merindukan DSSSL
  • Dalam artikel itu, pengguna yang enggan pada JavaScript hanya disebut sepintas, sementara sebagian besar tulisan berfokus menunjukkan kemampuan CSS itu sendiri, performa memang salah satu motivasinya, tetapi menurut saya memperkenalkan teknik CSS adalah pendekatan yang jauh lebih produktif
  • Saya memang menggunakan internet sehari-hari dalam lingkungan NoScript, dan hanya memberi pengecualian pada situs yang benar-benar butuh JS, ini juga cukup baik untuk performa, baterai, dan keamanan, pernahkah Anda benar-benar hidup dengan NoScript selama lebih dari seminggu? Sebelum saya mencobanya, saya juga punya pendapat yang sama, sebagai catatan, saya adalah penulis posting blog ini
  • Saya tidak merasa basis pengguna NoScript cukup signifikan atau perlu dijadikan target, tetapi meskipun penulis tidak mengatakannya di bagian singkat yang disebut itu, saya rasa ada nilai yang sangat besar dalam menulis lebih sedikit kode dan lebih banyak mengandalkan platform browser, membiarkan browser melakukan sebanyak mungkin pekerjaan itu efisiensinya memang besar
  • Saya rasa untuk klaim "sebagian pengguna tidak menginginkan JavaScript", sebenarnya hampir semua pengguna tidak menginginkannya

• Saya tidak tahu bahwa nesting kini sudah menjadi standar resmi, sampai belum lama ini saya kira masih tahap proposal, CSS memang punya banyak keanehan, tetapi saya juga merasakan arus bahwa ia berkembang menjadi bahasa yang makin layak seperti JavaScript, berkat Flexbox, selector :has, dan nesting, banyak titik sakit yang dulu sering saya alami kini sudah jauh berkurang

• Dua fitur CSS yang ada di wishlist ternyata sudah ada dalam spesifikasi

  • Variabel n-th child bisa diimplementasikan dengan sibling-index() dan sibling-count() (penjelasan MDN)
  • Blok yang bisa dipakai ulang ada dalam draf spesifikasi @function dan @mixin (draf spesifikasi, penjelasan CSS Tricks)
  • Keduanya sudah diimplementasikan di Chrome dan bisa dipakai

• Saya rasa sintaks CSS buruk, saya bekerja dengan 10~15 bahasa tetapi CSS adalah yang paling sulit dibaca dan dipahami, bahkan lebih rumit daripada assembly x86, CSS adalah input yang sudah ditokenisasi terlebih dulu untuk renderer, tetapi juga bukan token, dan terasa aneh untuk ditulis manusia, seperti ASN.1 di RFC, rasanya cocok dijadikan contoh buruk "jangan melakukan ini"

  • Saya penasaran, dari bahasa-bahasa itu berapa banyak yang deklaratif atau domain-specific language, membandingkan CSS dengan assembly tidak cocok, CSS bersifat deklaratif sedangkan assembly kebalikannya, mayoritas developer frontend juga awalnya kesulitan saat berpindah dari bahasa imperatif ke CSS, tetapi membaik setelah terbiasa, istilah dan konsep CSS sebagian besar berakar pada industri desain/penerbitan, bukan komputer, banyak developer mendekati CSS seolah-olah itu kumpulan instruksi eksplisit, padahal CSS bekerja dengan cara unik di mana properti saling memengaruhi, bahkan satu properti bisa mengubah keseluruhan algoritma layout (pengantar algoritma layout CSS)
  • Meski seseorang berkata "saya bekerja dengan 15 bahasa", menurut saya CSS tetap sangat sulit untuk benar-benar dipahami, bahasa pemrograman walau sering dipakai pun perlu pengalaman praktik yang sangat besar sebelum bisa dibilang benar-benar "paham" (wiki ilusi kedalaman penjelasan), cara terbaik memahami CSS adalah langsung melihat dan mengevaluasi hasil render-nya, saya sudah memakainya seperti itu selama puluhan tahun
  • Saya juga merasa CSS adalah yang paling buruk di antara trio HTML/CSS/JS
  • Saya ingin mendengar lebih spesifik apa maksud dari "CSS adalah input yang sudah ditokenisasi terlebih dulu"
  • Kode seperti "font-size: 12px" rasanya cukup mudah dibaca manusia, jadi saya tidak mengerti kenapa itu terasa sulit, bagi saya justru sangat sederhana

• Saya penasaran apakah contoh tab radio itu baik dari sudut pandang aksesibilitas, setahu saya menurut pedoman WAI-ARIA, atribut aria-selected, tabindex, dan aria-controls harus diperbarui oleh JS saat tab berubah, meski saya tidak sepenuhnya yakin, aksesibilitas sering kali jadi urusan belakangan, dan ada juga kesalahpahaman bahwa memakai HTML/CSS saja otomatis menjamin aksesibilitas, ini hal yang perlu dipertimbangkan sekali lagi saat memilih pendekatan

  • Setahu saya tab radio ini juga bekerja baik untuk navigasi keyboard dan screen reader, serta mengikuti alur perpindahan tab-ke-konten dari contoh WAI-ARIA (contoh WAI-ARIA), saya memang tidak punya latar belakang khusus di aksesibilitas, tetapi saya berusaha memverifikasinya semaksimal mungkin, dan juga mengujinya sendiri dengan berbagai alat aksesibilitas
  • Dalam tulisan aslinya, penulis beberapa kali menyebut soal aksesibilitas, bahkan berusaha menangani bug browser dengan solusi workaround (catatan kaki terkait)
  • Aksesibilitas blog post ini sendiri, terutama kontrasnya, terlalu buruk, jadi dari sudut pandang saya yang bekerja sebagai developer web di organisasi disabilitas, sulit menjadikannya referensi

• Efek interaktif seperti ini juga bisa dibuat tanpa JS (halaman contoh)

  • • Animasi konfeti yang berjatuhan
  • • Kotak notifikasi yang bisa ditutup
  • • Saat notifikasi ditutup, konfetinya juga ikut hilang
  • • Perilaku tab juga berfungsi (tetapi pada contoh itu perlu reload server)
  • • Jika ditambah JS, animasinya bisa jadi lebih halus dan kaya

• Sebagai web developer dengan pengalaman 10 tahun, saya merasa tulisan seperti ini memang perlu mengguncang keyakinan kita, judulnya kurang bagus sampai saya hampir melewatkannya, sebagai catatan, rendering peta tidak bisa dilakukan hanya dengan CSS

  • Dengan memanfaatkan CSS+SVG, rendering peta bisa dilakukan, tentu fitur tambahan seperti navigasi tetap perlu diimplementasikan terpisah

• Mungkin ada prasangka karena nama Vega, tetapi saya benar-benar suka situs ini, desain keseluruhannya bagus, dan isi halaman ini juga sangat hebat, ke depannya saya pasti akan membagikan tautan ini kepada orang-orang yang membuat web, saya juga sangat menyukai arrupted, yang dulu pernah menghasilkan karya keren, jadi menyenangkan melihat domain yang familiar ini muncul di halaman utama