CSS: Bagian-bagian buruk yang tak terhindarkan

 (matklad.github.io)
2 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Untuk menata gaya halaman web, subhimpunan kecil yang bisa dipelajari sudah cukup untuk blog sederhana atau GUI, tetapi jebakan seperti default browser dan layout bisa berujung pada debugging berhari-hari
  • Jika memakai tag HTML5 yang semantik lebih dulu dan mengurangi wrapper, akan lebih mudah membuat CSS bekerja mengikuti markup yang ada
  • Tidak ada satu algoritme universal untuk layout CSS, sehingga diperlukan pendekatan yang memahami jenis penempatan yang diizinkan oleh tiap sistem
  • box-sizing, margin, font-size, line-height, word-break bekerja tidak sesuai intuisi, sehingga perubahan kecil bisa meluas menjadi masalah tata letak atau keterbacaan secara keseluruhan
  • Untuk halaman sederhana, CSS reset, CSS tanpa class, flexbox, dan aturan responsif yang tidak berlebihan bisa menjadi titik awal yang praktis

Cakupan belajar CSS dan sudut pandang dasarnya

  • CSS, HTML, dan Web API sangat luas dan memerlukan keahlian khusus, tetapi untuk pekerjaan seperti blog pemrograman atau GUI sederhana, subhimpunan modern web yang secukupnya sudah memadai
  • Belum pernah terlihat materi yang hanya mengajarkan subhimpunan yang diperlukan untuk pekerjaan sederhana, tetapi dengan mengikuti MDN kita bisa memahami gambaran umumnya sampai tingkat tertentu
  • Masalahnya adalah jebakan yang keberadaannya tak terduga bisa merusak halaman, dan butuh berhari-hari untuk menemukan penyebabnya
  • Styling situs ini terdiri dari sekitar 200 baris CSS yang mudah dibaca

Bagian yang bagus: HTML semantik dan CSS tanpa class

  • Tag semantik HTML5

    • Layak menelusuri Elements Reference di MDN, dan jumlah elemen HTML sebenarnya tidak terlalu banyak
    • Tag seperti main, article, nav, kbd dapat mempermudah penyusunan struktur halaman
    • ul bisa dipakai untuk berbagai jenis daftar, misalnya bagian-bagian situs di dalam header > nav
    • details bisa dipakai untuk daftar isi, dan sumber MDN bisa dijadikan rujukan
    • dl dan dt bisa digunakan untuk daftar berpasangan

  • Pendekatan mengurangi wrapper

    • Jika melihat source website nyata, ada banyak elemen wrapper berlapis-lapis sehingga bisa tampak seolah masalah layout diselesaikan dengan wrapper
    • Penilaian tentang pengalaman CSS production disisihkan dulu, tetapi membatasi diri hanya pada tag semantik yang bermakna lalu mencari CSS yang cocok untuk markup itu terasa lebih mudah dipahami

  • CSS tanpa class

    • Tidak mungkin menginisialisasi style ke keadaan netral sepenuhnya yaitu “tidak ada apa-apa”; teks putih atau transparan pun tetap sebuah style
    • Setelah reset, dimungkinkan untuk langsung memberi style pada elemen HTML umum
    • Jika memakai tag main, header, footer, nav, layout seluruh halaman bisa diatur tanpa banyak selector CSS
    • Pendekatan ini memang membuat CSS berasumsi tentang struktur HTML, tetapi jika HTML dan CSS itu milik sendiri, kita bisa mengubahnya bila hasilnya tidak memuaskan

Bagian buruk: layout, default browser, selector

  • Layout

    • Masalah layout bukan hanya masalah web; ini juga sulit di berbagai framework GUI
    • Ada banyak cara untuk menempatkan gambar raster berukuran tetap dan paragraf teks yang menjelaskannya ke dalam sebuah persegi panjang layar
    • GUI pada umumnya adalah struktur hierarkis kotak-kotak dengan banyak “kebebasan layout”
    • Layout tiap kotak memengaruhi layout semua kotak lain, dan biasanya semua kotak harus saling menempel tepat tanpa celah dan tanpa tumpang tindih
    • Tidak ada satu algoritme layout universal; dari RectCut hingga constraint solvers, serta wilayah di antaranya, tiap sistem memakai heuristik yang berbeda
    • Lebih baik memikirkan “layout seperti apa yang diizinkan sistem itu” daripada “bagaimana membuat layout dalam sistem itu”

  • Default browser dan CSS reset

    • HTML semantik tanpa CSS pun tetap mendapat style bawaan browser seperti warna, font, ukuran, judul besar, dan tautan bergaris bawah
    • Style bawaan ini membantu, tetapi berbeda-beda antar-browser, sehingga jika bergantung pada default yang tidak kita tulis sendiri, hasilnya bisa berbeda di browser lain
    • Solusi umum adalah CSS reset atau normalisasi, yaitu menimpa default dengan aturan eksplisit di awal CSS
    • Yang buruk bukan default itu sendiri, melainkan ketidakkonsistenannya satu sama lain
    • Untuk mengetahui aturan mana yang perlu ditimpa, lebih baik membandingkan beberapa CSS reset yang sudah ada

  • Perlukah menata style halaman web

    • Di platform web ada dua sudut pandang sekaligus: melihatnya sebagai media visual yang fleksibel dan adaptif, dan melihatnya sebagai sarana penyampaian konten di mana pengguna seharusnya bisa mengustomisasi tampilannya
    • Secara default, halaman tanpa style kurang enak dipakai dan tidak menarik dilihat
    • Dunia di mana halaman tanpa CSS tetap mudah dibaca mungkin akan lebih baik, tetapi dalam kondisi saat ini, menerapkan style pada konten tetap membantu
    • Sebaiknya pengguna tingkat lanjut diizinkan membawa CSS mereka sendiri
    • Markup HTML harus masuk akal, tidak di-overfit ke CSS, dan halaman harus tetap berfungsi dalam reader mode

  • Selector CSS

    • CSS dasar bekerja seperti pewarisan yang kuat, sehingga setiap elemen desain pada halaman web dipengaruhi oleh banyak aturan
    • Dengan menambahkan isi ke file CSS, elemen yang sudah ada bisa sewaktu-waktu di-“monkey patch”
    • Selector CSS dipandang menambah kemampuan abstraksi pada sumbu yang keliru, sehingga pendekatan dengan CSS tanpa class dan inline style bisa dipakai
    • Alat seperti Tailwind bisa mengurangi ketidaknyamanan penulisan inline, dan JSX atau template engine yang mendukung komposisi bisa mengurangi pengulangan HTML
    • Dengan memakai CSS nesting, selector yang menjangkau terlalu jauh bisa dikurangi dan styling bisa dilakukan per komponen

Model kotak dan penempatan: box-sizing, margin, flow dasar, flexbox

  • box-sizing

    • UI adalah persegi panjang yang bersifat rekursif, dan layout adalah proses menentukan di mana tiap persegi panjang ditempatkan
    • Dalam default HTML, width dan height elemen tidak mencakup border dan padding, sehingga terasa tidak intuitif
    • Jika padding di satu tempat diperbesar, seluruh layout yang awalnya tampak sempurna bisa terdorong secara tak terduga
    • * { box-sizing: border-box; } layak menjadi baris pertama CSS reset, karena membuat penambahan border menjadi perubahan lokal

  • margin collapsing

    • Jika kita ingin jarak 8px di sekitar suatu elemen lalu memakai padding, jarak antara dua elemen bertetangga bisa menjadi 16px
    • margin bekerja dengan menggabungkan dua margin yang bertetangga bukan dengan penjumlahan, melainkan dengan max
    • Margin collapsing sangat berguna, tetapi bisa menghasilkan perilaku yang mengejutkan
    • Bisa dianggap bahwa margin anak dapat menyembul keluar dari parent, tetapi pemahaman intuitif tentang margin sendiri dirasa belum cukup
    • Tulisan Julia Evans Moving away from Tailwind, and learning to structure my CSS membahas pendekatan owl selector, di mana parent mengendalikan margin antar-anak alih-alih memberi margin pada elemen itu sendiri
    • Menambahkan margin pada semua anak section kecuali anak pertama dipahami sebagai ide untuk mengurangi masalah margin
    • Tidak nyamannya, pengetahuan seperti ini sulit dipelajari kecuali menjadi web developer profesional atau melakukan reverse engineering framework CSS lain

  • Layout flow dasar

    • Algoritme layout dasar terkait dengan asal HTML sebagai bahasa dokumen, dan tampaknya disesuaikan untuk kasus pembuatan dokumen mirip kertas yang berpusat pada teks dan gambar
    • Untuk teks isi, flow dasar memang bekerja cukup dekat dengan perilaku yang diinginkan
    • Jika ingin mengendalikan langsung penempatan ruang elemen halaman, diperlukan pendekatan selain flow dasar

  • flexbox

    • flexbox adalah layout untuk menempatkan serangkaian elemen secara vertikal atau horizontal, lalu menyesuaikannya dengan ruang yang tersedia
    • Dulu, penempatan seperti “ini di kiri, ini di kanan” membutuhkan pengetahuan CSS yang dalam atau framework CSS yang tidak transparan
    • Flexbox cukup rumit sehingga MDN perlu terus dirujuk, tetapi secara umum pekerjaan yang diinginkan bisa diselesaikan dengannya

  • Desain responsif

    • CSS modern dapat melakukan query terhadap ukuran layar dan menerapkan logika kondisional sesuai batasan user agent
    • HTML pada dasarnya bersifat responsif; tidak seperti PostScript atau PDF, paragraf akan otomatis mengalir ulang saat ukuran jendela berubah
    • Lebih baik menghindari aturan responsif yang eksplisit dan membiarkan layout bekerja secara wajar
    • Blog ini terlihat cukup baik di ponsel, tablet, dan desktop tanpa query @media yang eksplisit
    • Cukup dengan selalu menetapkan max-width pada kolom utama teks isi

Ukuran dan teks: piksel, font, line height, line break

  • Piksel

    • 1px melakukan hal yang diinginkan, tetapi bukan berarti satu piksel fisik pada layar
    • 1px dalam CSS adalah satuan sudut pandang visual, dirancang agar tampak mirip secara perseptual di layar mana pun
    • Nilai ini dikonversi menjadi jumlah piksel fisik yang berbeda tergantung ukuran layar, kerapatan piksel, dan jarak pandang yang umum
    • Karena itu, semua ukuran bisa ditentukan dalam piksel tanpa perlu memikirkan terpisah kerapatan piksel dari display yang berbeda-beda
    • Satuan “nyata” seperti sentimeter dan inci dalam CSS juga didefinisikan berdasarkan piksel, sehingga pada praktiknya bekerja seperti sudut

  • font-size

    • Dalam font-size: 16px, 16px bukan ukuran glif tertentu, melainkan ukuran kotak virtual di sekitar glif
    • Kotak ini tidak pas membungkus glif, dan ukuran glif yang sebenarnya berbeda-beda tergantung font
    • font-size-adjust dapat membuat font-size lebih konsisten antar-font
    • Saat ini font-size-adjust tampak seperti fitur yang sangat niche; secara pribadi rasanya ingin menaruh font-size-adjust: ex-height 0.53; di samping box-sizing, tetapi sedikit halaman yang melakukannya
    • Default font-size relatif konsisten antar-browser, dan 16px adalah default yang sangat dominan
    • Tergantung font-nya, 16px bisa tampak kecil, dan beberapa font default memang terlihat sangat kecil
    • Di Apple, font-family: serif tampak jauh lebih kecil daripada sans-serif, dan pada 16px hampir tidak nyaman dibaca
    • Menetapkan font-size di CSS menonaktifkan mekanisme perubahan ukuran font default milik browser
    • Jangan mengasumsikan teks akan mudah dibaca secara default; perlu dicek dalam pengaturan lain
    • Jika dengan font-size-adjust kebebasan sudah dikurangi dan makna font-size sudah dibuat tetap, lalu hasilnya baik pada ukuran font default 16px, maka selesai
    • Jika tidak, atur font-size ke angka yang lebih besar, lalu periksa juga apakah tetap mudah dibaca dalam reader mode

  • line-height

    • Berlawanan dengan namanya, line-height tidak mengatur tinggi satu baris
    • line-height adalah tinggi sekumpulan glif yang diatur dengan font yang sama
    • Jika semua teks memakai font yang sama, tinggi baris dan tinggi sekumpulan glif itu akan bertepatan
    • Jika beberapa kata diatur dengan font monospace, hasilnya bisa berbeda dari perkiraan
    • font-size-adjust memperbaiki ukuran glif di dalam kotak, tetapi tidak menentukan posisi relatifnya juga
    • Ketika kumpulan teks dari font yang berbeda disejajarkan secara vertikal agar berbagi baseline, line-box line-height masing-masing menjadi tidak sejajar
    • Tinggi keseluruhan baris bisa tersusun seperti gabungan himpunan dan menjadi lebih besar dari perkiraan
    • Efek ini dibahas rinci dalam Deep dive CSS: font metrics, line-height and vertical-align

  • vertical rhythm

    • Vertical rhythm adalah gagasan agar posisi baris di antara paragraf tetap berada pada posisi relatif yang sama, meskipun ada judul, gambar, dan sebagainya
    • Ini dijelaskan sebagai cara menyelaraskan halaman web seolah ada kertas bergaris tak terlihat di belakangnya
    • Untuk layout satu kolom, ini dinilai tidak terlalu berguna
    • Dalam layout dua kolom, mungkin ada keinginan agar baris di kedua sisi sejajar
    • Tidak masuk akal mengeluarkan usaha rumit untuk ini pada satu kolom

  • word-break

    • Keunggulan layout flow adalah perilaku dinamis di mana teks terbagi rapi menjadi baris saat jendela menyempit
    • Baris hanya bisa diputus pada spasi atau titik penyisipan tanda hubung
    • Bagian panjang seperti inline code atau URL bisa jadi tidak terputus
    • Masalah ini menyebabkan overflow horizontal di perangkat mobile, dan biasanya baru disadari setelah dipublikasikan
    • Tidak ada satu resep tunggal untuk memperbaikinya, tetapi Against Horizontal Scroll memiliki beberapa tips

Kesimpulan praktis

  • Untuk membuat blog sederhana, dibutuhkan materi yang menjelaskan secukupnya bagian HTML dan CSS yang benar-benar diperlukan secara singkat
  • Ditutup dengan permintaan akan sebuah buku pendek 100 halaman yang menjelaskan HTML dan CSS secukupnya untuk membuat blog sederhana tanpa tumbang oleh masalah seperti margin collapsing

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Pendapat di Lobste.rs

  • Koreksi kecil, tetapi definisi responsive design adalah “membuatnya terender dengan baik di berbagai perangkat dan ukuran jendela/layar sehingga kegunaan dan kepuasan tetap terjamin”
    Media query atau container query hanyalah salah satu alat untuk mewujudkannya, dan responsive design lebih dekat ke cara berpikir daripada “mari pakai media query untuk semua hal”
    Jadi yang tampaknya lebih tepat disebut “buruk” bukan responsive design itu sendiri, melainkan media query atau penggunaan breakpoint yang berlebihan

  • Bagian “Browser defaults” cukup menyesatkan. Reset stylesheet dan normalize stylesheet sangat berbeda tujuan dan cara kerjanya, tetapi tulisan itu mencampuradukkan keduanya
    Reset bukan sekadar menghilangkan perbedaan antar-browser, melainkan juga menghapus perbedaan bawaan antarelemen seperti padding-inline-start pada ol atau tampilan default button, sehingga style bisa dibuat dari kertas kosong alih-alih di atas user agent stylesheet
    Normalize adalah pendekatan yang mencoba bekerja bersama user agent stylesheet, dan isinya campuran antara penyamaan perbedaan antar-browser dan penggantian ke nilai default yang dianggap “lebih masuk akal”
    Sekarang ini kasus ketika nilai bawaan browser berbeda secara berarti sudah tidak banyak, jadi penulis konten web biasa hampir bisa mengabaikannya. Pengecualiannya antara lain Chromium has the wrong table border-color, WebKit fixed theirs 1½ years ago, perbedaan margin/ukuran pada beberapa elemen formulir, appearance, dan styling ::marker pada <summary> di WebKit
    Saya juga cenderung menentang box-sizing: border-box. border-box berpusat pada layout, sedangkan content-box berpusat pada konten, jadi menurut saya lebih baik orang tua menangani layout sementara desain dibuat berdasarkan konten. Saat menangani rasio, content-box diperlukan, dan kasus ketika border-box benar-benar berguna pada praktiknya kira-kira sebatas membuat body memenuhi viewport
    Saya juga skeptis terhadap font-size-adjust. Ia menukar masalah yang sudah dikenal luas dengan masalah yang lebih sedikit tervalidasi; bagi sebagian orang mungkin sedikit lebih baik, bagi yang lain sedikit lebih buruk. Masalah dasarnya tidak bisa diselesaikan, dan itu memaksa kita membuat asumsi yang tidak berdasar tentang rasio dan metrik font milik pengguna
    line-height dan ungkapan “diatur ke font yang sama” juga kurang presisi. Pada kenyataannya ukuran font, pergantian bahasa, font-family: monospace, vertical-align, <sup>, <sub>, dan metrik font semuanya saling terkait, jadi sulit menganggap ini sekadar masalah font yang sama
    Margin collapsing memang lebih rumit daripada yang digambarkan tulisan itu, tetapi juga cukup praktis. Jika memakai flex atau grid untuk konten biasa, kita jadi harus terus mengutak-atik gap atau margin sehingga mudah rapuh. Dengan display: flow-root, kita bisa mencegah margin anak bergabung dengan margin induk
    Saya tidak sepakat dengan kerangka besar soal responsive design, tetapi arah untuk mengurangi media query yang tidak perlu dan tidak melawan browser itu benar. Jika perubahan layout bisa diekspresikan berdasarkan konten, biasanya itu pilihan yang lebih baik
    Belakangan saya sering memakai interpolasi linear clamp dengan satuan viewport: margin-inline: --vw-lerp(1rem at 20rem, 2.5rem at 60rem); diekspansi menjadi margin-inline: clamp(1rem,1rem + ((2.5 - 1)/(60 - 20)*(100vw - 20rem)),2.5rem);
    Tahun lalu saya mengimplementasikan ini sebagai visitor LightningCSS, dan hasilnya adalah 1rem saat viewport 20rem atau kurang, lalu naik mulus hingga 2.5rem pada 60rem dan berhenti di sana, sehingga terasa enak karena tanpa breakpoint dan tetap menyesuaikan ukuran font pengguna

    • Saya kurang yakin font-size-adjust bekerja seperti itu. Namanya memang membingungkan, tetapi pemahaman saya adalah font-size mengubah ukuran kotak em, sedangkan font-size-adjust mengubah ukuran glif di dalam kotak em
      Jadi em dan rem tetap sama, sedangkan ch berubah. Namun ch memang dari awal bergantung pada font, jadi wajar jika berubah
      Saya ingin ada tulisan tentang font-size-adjust. Saya bukan ahli jadi tingkat keyakinan saya rendah, tetapi sejauh ini ini tampak seperti peningkatan besar yang hampir tidak dikenal orang. Memang tidak mungkin menyelaraskan dua font apa pun secara otomatis dalam semua konteks, tetapi hanya dengan menyamakan ukuran x alih-alih kotak em, menurut saya 90% kasus font/konteks sudah tercakup

  • Arah tulisan ini bagus, dan sudut pandang orang yang tidak sepenuhnya tenggelam dalam HTML/CSS juga penting, tetapi cukup banyak hal yang disebut “buruk” justru bisa bagus tergantung konteks
    Selector CSS mudah disalahgunakan, tetapi pada dasarnya tidak buruk. Daripada dipaksa menyimpulkan A atau B, kita bisa punya aturan/selector umum lalu menaburkan class berbasis pengecualian atau utility class saat diperlukan
    Bahkan di dalam tulisan itu sendiri ada contoh selector yang bagus:

    section > *+* {  
  margin-top: 1rem;  
}

    Media query juga bisa jadi tidak diperlukan jika bisa diselesaikan dengan container queries
    Permukaan CSS bisa terasa sangat luas, tetapi karena ia dipakai secara luas dan mampu melakukan banyak hal, benturan pendapat juga sering terjadi. Meski begitu, kita juga perlu melihat seberapa jauh CSS telah berkembang, dan betapa sedikit kode yang dibutuhkan untuk melakukan banyak hal jika konsep-konsepnya sudah dipahami
    Kalau ingin belajar lebih jauh, https://every-layout.dev/ cukup membantu saya memahami bagaimana berbagai elemen saling terkait di CSS

    • Saya juga ikut merekomendasikan Every Layout. Saya masih tidak suka CSS, dan secara pribadi merasa cascade secara mendasar kurang bagus sebagai model layout, tetapi sekarang setidaknya kita bisa membuatnya terlihat cukup masuk akal dan responsif di desktop maupun mobile
      Saya mulai memahami web layout ketika sadar bahwa situs web yang baik pada dasarnya dirancang secara vertikal. Elemen secara default seharusnya ditumpuk dari atas ke bawah, lalu layar mobile dirancang lebih dulu dan pada layar besar tinggal dibentangkan sebagai bonus

  • Sulit untuk setuju dengan klaim ini. CSS nesting hanyalah gula sintaks, dan tidak benar-benar membantu menghindari masalah selector yang terlalu spesifik secara berarti
    Bahkan 15 tahun lalu orang sudah banyak memakai nesting selector lewat Sass, dan satu per satu sampai pada kesimpulan bahwa itu justru membelenggu diri sendiri dengan mengikat selector CSS terlalu erat ke struktur HTML
    Jebakan nesting tidak terlalu terlihat di awal proyek. Pada tahap greenfield saat yang utama adalah membuat fitur baru, menulis CSS seperti ini terlihat sangat bagus
    Beberapa bulan kemudian, saat mulai melakukan perubahan layout besar dan redesign, elemen wrapper di HTML berpindah-pindah tempat, dan menyesuaikan CSS dengannya terasa seperti memecahkan Rubik's Cube sambil memakai LSD
    Menurut saya puncaknya adalah menjaga spesifisitas selector tetap rendah untuk sebagian besar kasus, yaitu dengan selector sederhana berupa satu class, dan hanya memakai sedikit selector gabungan serta selector kombinasi seperti a:hover. Ini jalur seperti BEM dan OOCSS, lalu setelah itu perhatian cepat bergeser ke alat yang berpusat pada JS

  • Tulisan yang menarik, tetapi penulis tampaknya memakai nested selector di posisi yang tidak memberi efek apa pun

    header { /* Site Header */  
  margin-bottom: 2rem;  
  & nav { /* ampersand redundant here? */  
    /* Styles, specific to nav in the Header. */  
  }  
}
    • Ada juga orang yang menganggap keputusan untuk membolehkan penghilangan & itu sebuah kesalahan, dan karena itu selalu menuliskan &. Menurut saya itu sikap yang cukup masuk akal
      Secara pribadi saya masih setengah-setengah. Awalnya saya juga mengira itu kesalahan, tetapi cukup praktis ketika setelah menulis banyak style kita bisa langsung mempersempit cakupannya hanya dengan membungkusnya dalam header { … }. Akan bagus juga kalau at-rule yang bukan berbasis selector seperti @keyframes bisa dipakai di dalamnya

  • Ini terus terang nasihat yang sangat buruk. Saya suka tulisan Maklad, tetapi ini jelas terlihat ditulis oleh orang yang belum pernah memakai CSS secara profesional
    Hampir semuanya adalah kebiasaan buruk ala amatir yang dihindari dalam penulisan CSS profesional

    • Lebih spesifiknya, bagi amatir objek desain utama adalah kotak konten. CMS mengeluarkan paragraf, penekanan, tautan, dan daftar, lalu sebagian besar waktu dihabiskan untuk menatanya
      Karena menatanya tanpa class selector, akhirnya <main> atau <nav> pun didandani tanpa selector
      Sebaliknya, di lingkungan profesional waktu untuk merancang kotak konten sangat sedikit. Biasanya dibuat sekali di awal proyek, lalu setelah itu hanya bug kecil yang diperbaiki perlahan
      Sebagian besar waktu justru dihabiskan untuk membuat komponen kustom atau komponen yang dapat dipakai ulang. Komponen reusable lebih sulit, dan pada dasarnya ujung-ujungnya membuat klon Bootstrap khusus untuk situs itu sendiri
      Komponen kustom lebih mudah, tetapi jumlah kodenya membengkak, dan agar tidak tanpa sengaja mengganggu komponen lain dibutuhkan strategi seperti BEM, OOCSS, atau utility class seperti Tailwind
      Kesimpulannya, tiap teknik punya skala yang berbeda-beda. Jika cara menulis CSS profesional terlihat tidak berguna, kemungkinan besar itu karena Anda sedang memecahkan masalah pada skala yang berbeda
    • Di tulisannya juga secara eksplisit disebutkan bahwa dia “belum pernah menulis production CSS”
      Meski begitu, saya setuju dengan Bad: Wrappers. Saya pernah melihat pakar CSS menulis seluruh situs dalam satu atau dua file, dan juga pernah melihat orang yang memakai CSS dalam jumlah sangat besar
      Jalur yang terakhir ini pada akhirnya mudah mengarah ke pendekatan yang keliru seperti BEM demi mengelola CSS yang begitu banyak

  • Di dalam tulisan itu tampaknya ada nasihat yang saling bertabrakan
    Good: Classless CSS dan Bad: CSS selectors muncul bersamaan, padahal untuk memakai classless CSS justru harus lebih bergantung pada selector CSS
    Referensi: https://www.keithcirkel.co.uk/css-classes-considered-harmful/

  • Vertical rhythm seperti “seolah ada buku tulis bergaris tak terlihat di belakang halaman web” sepenuhnya bisa dilakukan dengan nilai EM
    Kalau mencampur font yang berbeda mungkin akan sedikit goyah karena perbedaan metrik, tetapi bahkan saat itu Anda bisa memakai align-items: baseline dari flex