Validasi CSS

DevTools membantu kita memahami CSS yang sudah termuat, tetapi tidak mencegah kesalahan masuk ke stylesheet sejak awal. Di sinilah validasi dan linting bekerja: alat yang membaca kode kita sebelum browser, mencari typo, sintaks yang tidak valid, dan kebiasaan yang menimbulkan konflik. Chapter ini menjelaskan dulu perbedaan penting antara kode valid dan kode yang sekadar bekerja, lalu mengulas tiga lapis alat pemeriksa — validator W3C, linter Stylelint, dan pemeriksaan bawaan editor — beserta situasi di mana masing-masing benar-benar diperlukan.

Valid Belum Tentu Sama dengan Bekerja #

Browser dirancang untuk tidak berhenti pada kesalahan. Parser CSS melewati deklarasi yang tidak valid dan melanjutkan ke baris berikutnya, sehingga halaman tetap tampil meskipun ada typo. Sifat ramah ini punya sisi buruk: kesalahan tidak pernah bersuara, dan kita baru menyadarinya ketika sebuah gaya tidak muncul. Bandingkan tiga status berikut:

.kartu-profil {
  colr: #14503a;     /* typo property: dilewati tanpa peringatan */
  color: #14503a;    /* valid dan bekerja */
  margin: 12 px;     /* spasi sebelum unit: deklarasi dilewati */
  padding: 16px;     /* valid dan bekerja */
}

Dua kesalahan di atas adalah contoh nyata yang dilaporkan alat pemeriksa dalam hitungan detik.

Validator W3C: Manfaat dan Batasnya #

Validator CSS dari W3C memeriksa stylesheet terhadap tata bahasa spesifikasi. Manfaat utamanya: menangkap typo property dan nilai, kurung kurawal yang tidak seimbang, dan kesalahan struktural lain pada berkas yang panjang — pemeriksaan yang melelahkan bila dilakukan manual. Untuk stylesheet kecil, satu kali cek sebelum publikasi sudah cukup.

Batasnya juga perlu dipahami agar hasilnya tidak dinilai terlalu harfiah. Validator menandai sintaks modern yang belum masuk profil pemeriksaannya, misalnya nesting native atau fitur yang baru beberapa bulan masuk daftar Baseline — padahal kode tersebut valid dan didukung browser modern. Karena itu, bacalah hasil validator dengan kepala dingin: error pada sintaks yang memang sudah Baseline boleh diabaikan setelah kita memastikan statusnya, sedangkan error pada typo klasik selalu layak diperbaiki. Ketika ragu, rujuk kembali status fitur seperti yang dipakai sepanjang course ini.

Linting dengan Stylelint #

Linter bekerja di sisi yang berbeda: bukan menilai kevalidan semata, melainkan menegakkan konsistensi dan mencegah pola yang rawan konflik. Stylelint adalah alat yang paling banyak dipakai untuk CSS. Yang ditangkapnya antara lain:

• Property duplikat dalam satu blok — konflik urutan seperti yang dibahas pada chapter Debugging Specificity.
• Property atau unit yang tidak dikenal — typo seperti colr tertangkap sebelum browser melewatinya diam-diam.
• Pemakaian !important yang bisa dilarang lewat aturan, menjaga stylesheet bebas dari jalan pintas berantai.
• Urutan dan format deklarasi yang disepakati tim, sehingga berkas dari dua penulis terlihat seperti satu tangan.

Konfigurasinya berupa berkas JSON yang mewarisi konfigurasi standar lalu menambahkan aturan tim:

{
  "extends": "stylelint-config-standard",
  "rules": {
    "declaration-block-no-duplicate-properties": true,
    "declaration-no-important": true,
    "max-empty-lines": 1
  }
}

Hasil pemakaiannya berupa daftar temuan per baris, sehingga perbaikannya langsung ke alamatnya:

src/styles.css
  12:3   ✖  Unexpected unknown property "colr"      (property-no-unknown)
  14:3   ⚠  Unexpected duplicate property "margin"  (declaration-block-no-duplicate-properties)
  41:3   ✖  Unexpected !important                   (declaration-no-important)

Pemeriksaan Bawaan Editor #

Editor modern membawa lapisan ketiga yang paling dekat dengan kebiasaan menulis: VS Code dan sejenisnya menandai property yang tidak dikenal dan kurung yang tidak seimbang saat kita mengetik, lengkap dengan garis bawah pada bagian yang bermasalah. Pemformat otomatis seperti Prettier bukan alat validasi — ia merapikan tata letak kode tanpa menilai kebenarannya — tetapi format yang konsisten membuat kesalahan struktural lebih mudah terlihat mata. Untuk pekerjaan sehari-hari, kombinasi editor plus linter sudah menutup sebagian besar kesalahan klasik.

Kapan Validasi Diberatkan #

Tingkat kewajiban validasi mengikuti skala proyek:

Kata kuncinya adalah otomatisasi: aturan yang bergantung pada ingatan manusia akan terlewat tepat pada minggu yang sibuk, sedangkan alat yang berjalan di CI tetap konsisten tanpa kecuali.

Ringkasan #

Browser melewati deklarasi yang tidak valid tanpa suara, sehingga kode yang bekerja belum tentu kode yang bersih — dan alat pemeriksa mengisi kekosongan itu dalam tiga lapis: validator W3C untuk tata bahasa (dengan catatan: hasilnya pada sintaks modern perlu dinilai ulang), Stylelint untuk duplikat, typo, !important, dan konsistensi tim, serta pemeriksaan bawaan editor yang bekerja sejak baris pertama diketik. Pilih tingkat kewajibannya sesuai skala proyek, dan utamakan otomatisasi bila ada tim yang terlibat. Lapisan terakhir dari section ini kini tinggal satu: menyatukan seluruh kebiasaan aksesibilitas dan debugging menjadi checklist sebelum publikasi.