Cara menulis CSS yang sungguh mengerikan

Semua orang bercakap mengenai 'petua' dan 'petua pro' untuk menulis CSS yang hebat.

Tidak apa-apa, tetapi mungkin melihat CSS yang buruk akan memberi anda perspektif yang berbeza. Ya, ia mungkin memberi kebaikan kepada anda!

Izinkan saya membawa anda dalam perjalanan bagaimana menulis CSS yang sangat buruk.

Sedia?

Catatan: walaupun anda bersumpah dengan CSS-in-JS dan tidak menyukai CSS vanila, kita semua bersetuju dengan perkara itu: kita semua masih harus mengetahui beberapa CSS ...

Oleh itu, sama ada anda menulis CSS, atau beberapa superset seperti SASS, atau hanya CSS-in-JS, anda masih akan mendapat manfaat daripada mengetahui sebenarnya bentuk CSS yang tidak baik.

Siapa yang Menulis Komen? Tiada sesiapa.

Sangat mudah tergelincir di sini sehingga anda tidak akan melihat dengan cepat.

Kita semua mengetahuinya. Anda begitu pintar, orang lain tidak dekat. Walaupun CSS bukan "bahasa" yang paling ekspresif, anda boleh membuat andaian mengenai kebiasaan penyemak imbas, memperbaikinya, dan menganggap anda akan memahami apa yang telah anda lakukan beberapa minggu.

Bagaimana pintar, ya?

Ketepikan harga diri anda, dan selamatkan diri anda dan rakan sepasukan yang lain dari tekanan.

Sekiranya anda menggunakan teknik yang tidak begitu jelas, atau telah memperbaiki beberapa pelik penyemak imbas, atau apa sahaja yang anda fikir tidak cukup ekspresif, tulis komen itu! Ia tidak menyakitkan.

Tanah Pemilih Kompleks

Yeah! Anda baru belajar CSS dan merasa berada di puncak dunia. Jadi, masa untuk memamerkan beberapa otot pemilih.

Pergerakan yang tidak baik.

Dengan membuat pilihan dengan terlalu banyak pemilih CSS, anda mungkin berjaya menjadikan CSS anda sangat tidak dapat dicapai. Sekarang sangat bergantung pada struktur HTML aplikasi anda.

Sekiranya struktur markup berubah sedikit, anda juga perlu mengubah semula CSS anda. Bukan aliran kerja yang paling mudah.

Cukup tambahkan kelas ke elemen dan teruskan kehidupan!

Walaupun dalam senario di mana anda perlu melayakkan pemilih dengan pelbagai kelas, selalu pilih kesederhanaan.

Sederhana itu bagus, hampir selalu!

Persembahan? Ditch Itu!

Jadi, saya faham. Anda tidak mementingkan persembahan. Anda tidak peduli dengan perniagaan ini. Sekiranya anda melakukannya, anda tidak akan mengganggu pengguna anda dengan pemilih yang tidak berperforma buruk.

Tapi tunggu…

Saya faham bahawa komputer berkembang dengan lebih pantas dan penyemak imbas terus dioptimumkan. Walau apa pun, pemilih sederhana harus selalu disukai, dan memahami bagaimana penyemak imbas melintasi DOM untuk mencari pemilih anda masih menjadi perkara!

Kemungkinannya, anda membaca pemilih anda dari kiri ke kanan.

Walau bagaimanapun, penyemak imbas sesuai dengan pemilih dari kanan ke kiri, sehingga dapat menghilangkan elemen yang tidak sepadan secepat mungkin.

Sekiranya anda mengetahui perkara ini, anda mungkin lebih berhati-hati pada penyemak imbas. Mereka layak mendapat cinta anda.

Dengan mengambil kira contoh grafik di atas, penyemak imbas akan memadankan semua elemen (*) dan juga memeriksa sama ada keturunan tersebut body.

body * { ... } 

Tapi kenapa? Hampir setiap elemen yang dapat dilihat adalah keturunandy> element. That’s just a needless inefficient check.

I Suck at Naming Things, so I don’t even bother.

Original text


There are only 2 hard things in computer science. Naming things and …

Yeah, I think you already heard that somewhere. Naming things can be hard, but that doesn’t mean you shouldn’t give them some thought, or go completely cryptic.

I doubt there’s any situation where it makes sense to use single letters as class names.

.u { font-size: 60rem;}

And what about super-specific class names?

.former-black-now-red-paragraph { color: red;}

Those don’t do any good, either.

While the name may seem to convey some meaning, you very likely have broken a huge part of the class’s re-usability. Which, by the way, is the primary reason for having classes.

Now, if you wanted to style a regular red the paragraph, the previous name is just so specific, it wouldn’t make sense.

Use meaningful names, but just don’t overdo it.

I Heard Classes were Great. Overuse them!

Classes are great, and everyone loves them. But, as with everything else, too much of something is generally a bad idea.

You see, if a group of classes will mostly be used together, just group them into one class.

When you choose to group these classes is perhaps subjective. If you’re building an atomic library of some sort, you may tend towards this.

If you’re writing a large app, you’re likely better off grouping classes in a meaningful way, as opposed to having a ton of classes on a single element.

When possible, avoid over modularised classes.

I am a CSS Purist. I don’t do SASS, LESS, etc.

You’re a CSS purist, I’m a CSS purist, we’re both purists. Let’s get that out of the way.

Now, to the bone of contention.

There are definitely use cases where just writing vanilla CSS is great! For example, if I’m not using a CSS-in-JS solution for my React projects, I could decide to go the pure CSS route. It doesn’t hurt.

However, if you’re writing a large app with a ton of vanilla CSS flying around, I bet introducing a CSS preprocessor will make your development more interesting and contribute towards a more maintainable CSS codebase.

Again, I’m not saying use preprocessors every single time. I’m saying don’t just close out that option. It could save you!

You’ve got a lot of Important Style there!

I hate CSS. It just never works. So, what’s the fix?

Have a ton of !important all over the place when I need to override any declarations. Haha!

While this sounds like a decent plan to your lazy self, over-using the !important rule will only result in a grossly unmaintainable CSS document.

The next time you need to use !important, be sure you’re not doing so because you’re too lazy to fix your cascade issues.

CSS isn’t that bad. Embrace it.

Want to write Better CSS?

I have created a free CSS guide to get your CSS skills blazing, immediately. Get the free ebook.