-
reset
- preflight styles dari Tailwind awalnya disalin sekitar 200 baris dari
tailwind.css untuk dipakai
- Karena sudah lama terbiasa dengan reset Tailwind, aturan yang menerapkan
box-sizing: border-box ke semua elemen membuat lebar elemen ikut mencakup padding
* { box-sizing: border-box; }
- Ada kemungkinan selama ini juga tanpa sadar bergantung pada aturan reset lain seperti
html {line-height: 1.5;}, dan rasanya akan butuh banyak penyesuaian untuk menulis CSS tanpa aturan seperti ini
-
components
- Sebagian besar CSS disusun dalam file per komponen, mirip dengan cara mengatur komponen Vue atau React
- Setiap komponen punya kelas unik, dan disusun agar CSS satu komponen tidak menimpa CSS komponen lain
- Dalam praktiknya, sekitar 80% CSS yang benar-benar ingin diubah ada di dalam file komponen, jadi saat mengedit komponen 100 baris, cukup memikirkan 100 baris itu saja
- Misalnya, komponen
.zine bisa memiliki HTML seperti berikut
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- CSS mengumpulkan state seperti
.horizontal, .vertical, dan :hover di dalam komponen dengan nested selector
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Tidak sampai memblokir gangguan antarkomponen secara terprogram seperti Web Components atau
@scope, tetapi hanya dengan menetapkan dan menaati konvensi pun rasanya sudah jauh lebih baik
-
colours
colours.css mengumpulkan variabel CSS yang bisa digunakan saat diperlukan- Warna itu sulit, dan karena tidak ingin meninjau ulang penggunaan warna dalam refactor kali ini, pendekatan sebelumnya tetap dipertahankan
- Satu-satunya aturan adalah semua warna yang dipakai di situs harus didaftarkan di file ini
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- Di Tailwind cukup memilih tingkat ukuran seperti
text-lg, xl, atau 2xl, jadi tidak perlu mengingat apakah memakai em, px, atau rem
- Untuk mempertahankan itu juga di CSS vanilla, didefinisikan variabel ukuran yang diambil dari Tailwind
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- Ukuran font ditentukan lewat variabel; memang sedikit lebih bertele-tele dibanding Tailwind, tetapi untuk sekarang terasa memuaskan
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- Elemen seperti tombol yang berulang di banyak komponen diklasifikasikan sebagai utilities
- Beberapa utility class seperti
.sr-only untuk elemen yang hanya perlu terlihat oleh pengguna screen reader disalin dari Tailwind
- Area ini ingin dijaga tetap kecil, dan diubah dengan hati-hati
-
base
- Style “base” adalah style yang diterapkan langsung ke seluruh situs
- Karena belum cukup yakin untuk memaksakan banyak style ke seluruh situs, area ini dijaga sangat kecil
- Saat ini aturan yang terasa oke hanya dua: untuk
<section> dan a, dan aturan <section> bisa saja berubah nanti
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- Untuk style base, pendekatan bottom-up tampaknya paling mudah: mulai dengan hampir kosong, lalu memindahkan hal-hal yang diinginkan bersama dari komponen ke base saat pola umumnya terlihat
-
spacing
- Cara mengelola padding dan margin masih belum sepenuhnya diputuskan
- Saat memakai Tailwind, padding dan margin sering ditambahkan spontan di sana-sini sampai tampilannya terasa pas, dan sekarang sedang mencari pendekatan yang lebih berprinsip
- Untuk saat ini, sebisa mungkin komponen layout luar yang bertanggung jawab atas jarak
- Jika ingin memberi jarak seragam antar anak dalam
<section> yang punya beberapa anak, aturan berikut bisa dipakai
section > *+* {
margin-top: 1rem;
}
-
responsive design
- Di Tailwind, sering digunakan sintaks berbasis media query seperti
md:text-xl untuk menerapkan style text-xl di atas ukuran tertentu
- Sekarang tujuannya adalah membuat layout CSS grid yang lebih fleksibel sehingga tidak perlu banyak breakpoint
- Dengan
auto-fit, layar besar bisa otomatis memakai 2 kolom dan layar kecil 1 kolom
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- Saat pengembangan, tidak diperlukan build system terpisah
- CSS punya pernyataan
@import bawaan untuk memisah dan memuat file
@import "reset.css";
@import "typography.css";
@import "colors.css";
- CSS juga sudah punya nested selector bawaan
.page {
h2 { ...}
}
- Jika ingin menggabungkan file CSS untuk produksi, bisa memakai
esbuild
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- Biasanya berusaha menghindari build system untuk CSS dan JS, tetapi
esbuild dianggap oke karena berbasis web standard dan berupa binary Go statis
- Tentang
esbuild, pernah menulis artikel terkait esbuild dan Vue pada 2021
3 komentar
Bukankah jadi sedikit lebih baik setelah diubah menjadi zero-config?
Opini Hacker News
Saya sudah lama mengajarkan HTML semantik dan markup yang aksesibel, serta banyak menangani situs dan aplikasi untuk screen reader, dan masalah terbesar Tailwind adalah membalik urutan cara kita seharusnya memikirkan HTML dan CSS
HTML seharusnya menjadi titik awal karena fungsinya menandai makna dokumen, lalu setelah itu baru diberi styling dengan CSS. Jika styling membutuhkan elemen tambahan, kita bisa memakai div atau span, tetapi seharusnya terlebih dahulu mempertimbangkan apakah ada elemen yang lebih tepat
Tailwind mendorong developer ke pendekatan yang mendahulukan CSS, sehingga mereka lebih dulu memikirkan kelas Tailwind yang diinginkan lalu menambahkan div lain ke DOM hanya untuk menempelkan kelas tersebut
Kemampuan seorang web developer seharusnya mencakup membuat HTML dan CSS yang tetap mudah dibaca di masa depan, bisa dipakai semua pengguna, dan secara umum selaras dengan spesifikasi HTML/CSS, tetapi Tailwind justru menurunkan kemampuan itu. Bahkan contoh pertama di situs Tailwind hanya berisi div dan span, memberi pendidikan yang buruk bagi developer baru, dan menurut saya juga ikut berkontribusi pada arus LLM yang memuntahkan sup div tanpa instruksi tambahan
Alat apa pun bisa disalahgunakan, dan Tailwind bukan pengecualian. Saya sudah memakai CSS sekitar 20 tahun, juga pernah memakai Less, SASS/SCSS, Stylus, dan PostCSS, tetapi alasan saya menetap dengan Tailwind beberapa tahun terakhir justru karena ia memungkinkan styling aplikasi yang lebih kokoh
Kita tidak perlu membuat abstraksi style/kelas secara berlebihan, beban kognitif berkurang karena style diletakkan langsung pada markup yang terdampak, perubahan style tak sengaja akibat selector yang longgar lebih jarang terjadi, dan debugging jadi lebih mudah. Kecuali untuk situs/aplikasi yang sederhana, codebase Tailwind sering kali lebih tidak rumit dan lebih tidak rapuh dibanding codebase dengan framework CSS kustom
Jika mempertimbangkan skala font/warna/ukuran yang konsisten, bundle yang lebih kecil, konsistensi antardeveloper yang sama-sama paham Tailwind, ekosistem yang matang, dan kedekatannya dengan LLM, ini adalah pilihan yang sangat baik untuk banyak tim. Pada akhirnya, seperti kebanyakan alat, hasilnya bagus atau buruk tergantung siapa yang memakainya
Kekacauan HTML/CSS/JS saya anggap sebagai kejahatan yang perlu saat menargetkan browser, dan bagi saya itu hanya lapisan presentasi. Dalam pekerjaan, saya jauh lebih menekankan ketepatan pada skema database atau logika bisnis backend
Kalau lapisan presentasi yang berantakan bisa dibuat seminimal mungkin namun masih cukup terawat, itu sudah cukup, dan untuk tujuan itu Tailwind sangat cocok. LLM bisa menulisnya dengan baik, developer baru bisa cepat memahaminya, dan nanti juga cukup mudah dibaca dan diperbaiki
Saya sepenuhnya setuju bahwa proyek Tailwind bukan cara terbaik bagi developer baru untuk belajar HTML/CSS, tetapi saya tetap lebih suka jika developer baru fokus pada hal seperti skema database yang baik, API yang intuitif, dan logika bisnis yang bisa diuji
Tidak ada hal dalam Tailwind sendiri yang memaksa penggunaan div dan span sebagai pengganti tag HTML yang tepat
Dokumen dan antarmuka itu berbeda, dan Tailwind jauh lebih masuk akal untuk antarmuka. Kita bisa memakai Tailwind untuk antarmuka dan memakai selector HTML yang dibatasi cakupannya untuk konten lain
Fakta bahwa Tailwind sekitar 4 kali lebih cepat daripada menulis codebase CSS yang kompleks dan praktis nyaris tanpa overhead tetap menjadi kelebihan, apa pun penilaiannya
Singkatnya, ini cara menulis CSS berdasarkan urutan spesifisitas:
/scss/
├── 1-settings. <- pengaturan global
├── 2-design-tokens <- font, warna, spasi, dll.
├── 3-tools <- mixin Sass, fungsi CSS, dll.
├── 4-generic <- reset, box sizing, normalisasi, dll.
├── 5-elements <- style dasar untuk heading, tombol, tautan
├── 6-skeleton <- grid layout, dll.
├── 7-components <- card, carousel, dll.
├── 8-utilities <- utility dan helper class
├── _shame.scss <- hack yang akan diperbaiki nanti
└── main.scss
ITCSS praktis menghilangkan pertarungan spesifisitas dalam codebase CSS. Biasanya satu-satunya tempat
!importantdipakai adalah lapisan utility[1]: https://matthiasott.com/notes/how-i-structure-my-css
Jika melihat library komponennya, atribut
ariajuga sudah disertakan: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...Kecuali untuk hal yang lebih mirip brosur digital seperti landing page, saya selalu mulai dari markup lalu menambahkan kelas CSS di atasnya
Dua hal bagus dari Tailwind adalah data pelatihan AI sudah kaya akan informasi kelasnya, dan tidak ada konflik style
Karena itu, saat AI membuat style baru, ia tidak perlu merujuk stylesheet yang sudah ada, yang bagus untuk pengelolaan konteks
Dalam CSS kustom, AI harus membaca stylesheet yang ada agar konflik atau duplikasi penulisan berkurang, tetapi stylesheet besar bisa memakan banyak ruang memori AI dan itu bisa jadi masalah
Saya sangat menyukai tulisan Julia Evans
Ia menulis dari posisi yang rapuh dan jujur. Banyak orang menulis untuk terlihat pintar, tetapi Julia menulis dengan sikap, “Saya juga tidak tahu semuanya, tetapi ada hal yang saya temukan dan ingin saya bagikan.” Rasanya sampai seperti membagikan sesuatu kepada orang-orang yang dicintainya, meski saya tidak mengenalnya secara pribadi
Di Strange Loop terakhir ia presentasi bersama Randall Munroe, dan meskipun ada orang-orang yang menunggu untuk bicara dengannya setelah presentasi, saya justru menunggu untuk bicara dengan Julia. Saya sungguh minta maaf karena sepertinya dia tidak menangkap lelucon saya tentang menulis ulang skrip bash menjadi Perl
Saya bukan Julia, tetapi saya punya filosofi yang hampir sama soal presentasi publik atau presentasi formal, dan saya juga sudah berusaha menanamkannya kepada rekan kerja yang kesulitan presentasi. Bisa menyampaikan pengetahuan yang sedikit lebih akrab bagi saya, dan mungkin berguna bagi rekan maupun orang-orang yang saya sayangi, adalah sebuah privilese besar
CSS Modules adalah solusi yang lebih sederhana untuk masalah cascading. Ia mencegah konflik kelas dengan membuat nama kelas yang unik [1]
Ia juga tidak punya dua kekurangan besar Tailwind, yaitu keterbacaan [2] dan dukungan alat. Khususnya, saya rasa dukungan alat untuk debugging dan bereksperimen secara interaktif di Chrome dan FireFox DevTools lebih baik
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Hal yang selalu mengesankan saya dari Tailwind adalah hampir semua argumen para pendukungnya pada akhirnya bermuara pada “mereka tidak pernah benar-benar belajar CSS di atas level junior”
Kita sering mendengar hal seperti, “Tanpa Tailwind, akan ada satu file CSS besar dan berantakan yang tumbuh tak terkendali, penuh kode lama dan
!important,” padahal CSS juga merupakan sebuah keterampilan, sama seperti keterampilan teknis lainnyaJika hanya belajar secukupnya untuk membuat tampilan terlihat benar lalu menambal sana-sini, ambisi akan sangat cepat melampaui kemampuan untuk menjaga kode tetap rapi
Sangat membuat frustrasi ketika sedang membicarakan Tailwind dan CSS lalu menyadari lawan bicara bukan hanya tidak tahu arti “cascading”, tetapi bahkan belum pernah mempertimbangkan bahwa konsep itu bisa berguna dalam konteks stylesheet
Saya sudah banyak memakai CSS sejak 90-an, lalu melihat Tailwind, dan setelah memahaminya, saya jadi cenderung menghindari CSS murni. Dalam satu arti, ini memang menukar satu kekacauan dengan kekacauan lain, tetapi secara pribadi saya lebih memilih menghadapi sup kelas yang terlokalisasi daripada cascade yang saling tumpang tindih dan saling bertentangan di banyak file
Keduanya bisa diterapkan dengan rapi, tetapi merapikan kekacauan Tailwind menurut saya jauh lebih baik daripada merapikan kekacauan CSS, dan keseluruhan proses pengembangannya juga terasa lebih menyenangkan
Saya sendiri sudah lebih dari 20 tahun memrogram dan hampir 15 tahun melakukan web development, tetapi sulit menemukan motivasi untuk benar-benar belajar CSS. Ada terlalu banyak keterampilan teknis yang harus diikuti, dan CSS cukup rendah dalam prioritas saya
Saya ingin menyerahkannya kepada ahli, tetapi perusahaan tidak mau merekrut developer frontend khusus
Saya sedang menulis panduan web development yang rapi dengan fokus pada penulisan HTML dan CSS yang bisa diskalakan: https://webdev.bryanhogan.com/
Mungkin ini berguna bagi orang-orang di sini. Untuk styling, saya tidak memakai sesuatu seperti Tailwind, melainkan framework modern seperti Astro atau Svelte plus CSS
Setiap proyek saya memiliki
reset.css,var.css,global.css, danutil.css, lalu style lainnya dibatasi cakupannya ke komponen atau layout terkaitArtikel yang bagus
Saya suka menghilangkan ketergantungan pada library eksternal dan membuat solusi sendiri dari nol, tetapi ada alasan jelas kenapa saya tidak melakukannya untuk Tailwind. Tailwind menyediakan optimasi produksi sehingga hanya CSS minimum yang benar-benar dibutuhkan yang akan dikirimkan
Sekalipun semua pilihan seperti warna, spasi, dan sebagainya didaftarkan di
globals.cssatau tempat lain, kita tidak perlu khawatir apakah semua variasi itu dipakai di production. Jika bekerja di dalam framework seperti Next.js, tahap minimisasi ini bahkan terjadi otomatis saat build, dan itu saja sudah cukup menjadi alasan untuk tidak pindah dari TailwindSaya juga tidak pernah merasa ada batasan yang sulit ditoleransi saat memakai CSS inline di Tailwind, dan tidak pernah punya masalah besar menggunakan alat grid Tailwind untuk membuat grid yang responsif terhadap lebar layar. Semua skenario yang dibahas di artikel sudah pernah saya selesaikan dengan Tailwind atau kombinasi Tailwind dan CSS, dan memang benar
grid-column-areastidak tersedia secara bawaan, tetapi sejauh ini saya belum pernah merasakannya sebagai kendala besar dalam layout grid responsifMasalah terbesar Tailwind adalah butuh waktu lama untuk terbiasa membacanya. Kita dibesarkan dengan gagasan bahwa CSS inline itu buruk dan CSS global itu baik, serta terbiasa dengan HTML yang bersih, jadi kode Tailwind yang nyata, terutama baris yang panjang, pada awalnya memang terlihat sangat sulit dibaca. Setelah lama memakainya, saya benar-benar terbiasa dengan tampilannya, dan pada akhirnya sampai pada kesimpulan bahwa bagi saya Tailwind lebih efisien, lebih mudah dirawat, bahkan lebih mudah dibaca, tetapi memang butuh waktu yang cukup lama
Pendekatan yang belakangan ini sangat saya sukai adalah memakai Tailwind bersama style yang dibatasi cakupannya (di Svelte dan Vue)
Dengan begitu, kenyamanan Tailwind tetap terjaga sambil meminimalkan polusi pada template:
+
{{ count }}
Bagi saya, Svelte dan LLM sepenuhnya menghilangkan kebutuhan akan Tailwind
Ternyata alasan utama saya memakai Tailwind bukanlah pembatasan yang saya tetapkan sendiri, melainkan untuk menghindari konflik CSS dan karena sintaksnya terasa lebih logis bagi saya
Hal terbaik dari Tailwind adalah kita tidak perlu membuat nama kelas sementara. Kita tidak perlu lagi memakai BEM
Pendapat di Lobste.rs
Untuk proyek pribadi, saya hampir tidak lagi memakai framework CSS/JavaScript
Karena kalau tidak ada dependensi, tidak akan ada juga kerentanan rantai pasok. Tentu saja itu bukan satu-satunya jenis kerentanan, tapi tetap membantu
Ini hasil gabungan dari rasa lelah terhadap framework, beban berlebih dari
npm audit, dan fakta bahwa berkat LLM saya jadi tidak terlalu peduli pada penilaian orang lain soal cara implementasi. Misalnya pertanyaan seperti “kenapa tidak pakai React dan Tailwind?”Ini memang hanya cara kerja CSS
Kalau melihat orang memakai Tailwind secara membabi buta tanpa memahami ini, rasanya saya ingin keluar dan berteriak ke awan. Menurut saya, 90% dari Tailwind hanyalah inline style dengan sintaks yang berbeda, dan mungkin cuma setingkat lebih baik daripada tag
<FONT>Tulisan blog ini justru menjelaskan hal-hal yang benar-benar perlu saya ketahui
Tailwind bekerja cukup berbeda dari inline style, dan justru jauh lebih mirip dengan CSS. Seperti yang juga dibahas di tulisan itu, banyak kebiasaan baik yang membuat seseorang mahir memakai Tailwind juga merupakan kebiasaan yang diperlukan untuk menulis CSS yang efektif. Tailwind lebih mendekati CSS yang menempelkan blok CSS dengan scope implisit ke setiap elemen, hanya saja memakai DSL yang unik
Saya paham betul cara kerja CSS, tetapi CSS murni tetap terasa membebani, dan saya juga lemah dalam desain grafis, jadi saya masih memakai Tailwind. Tulisan ini memberi ide untuk menata CSS dengan berangkat dari Tailwind
Dari sudut pandang orang yang belakangan ini kurang mengikuti tren, tulisan ini tampaknya cukup bagus dalam menunjukkan praktik CSS modern
Saya juga suka karena ada banyak tautan ke tulisan-tulisan yang menjadi inspirasinya. Kelihatannya bagus untuk bahan bacaan, dan sejauh ini saya baru membaca "no outer margin"
Meski begitu, saya agak ragu dengan pendekatan menetapkan gaya dasar dari “bawah ke atas”. Saya juga tidak tahu harus melakukan apa sebagai gantinya, dan ini tampak layak dicoba, tetapi gaya dasar pada dasarnya memang rumit
Saya sangat menyukai tulisan ini
Saya juga belajar CSS sedikit demi sedikit sambil membuat banyak situs kecil, dan rasanya akan membantu kalau sejak awal saya lebih banyak berpikir secara sistematis seperti ini. Saya cukup punya resistensi terhadap framework, tetapi karena tidak memakainya, sering kali saya merasa meskipun saya tahu cara membuat sesuatu sesuai keinginan, semuanya seperti melayang tanpa struktur yang jelas
Menyenangkan karena nadanya bukan “Tailwind jelek jadi pakailah CSS saja”, melainkan “Tailwind itu bagus, tetapi sekarang mungkin tidak lagi diperlukan”
Saya selalu kesulitan menata CSS secara manual, dan berkat tulisan ini saya jadi memikirkannya dengan cara yang sangat berbeda
Saat merapikan CSS, teknik penataan ini cukup berguna: https://rstacruz.github.io/rscss/
Secara umum, ini sangat selaras dengan apa yang dijelaskan jvns di tulisan aslinya, lalu menambahkan sedikit lagi struktur dan keteraturan di atasnya