Kā uzrakstīt patiesi briesmīgu CSS

Visi runā par “padomiem” un “ieteikumiem” lieliskas CSS rakstīšanai.

Tas ir labi, bet varbūt, redzot, kā izskatās slikti CSS, jūs iegūsit citu skatījumu. Heck, tas var pat dot jums kaut ko labu!

Ļaujiet man jūs iepazīt ceļojumā, kā uzrakstīt patiešām sliktu CSS.

Gatavs?

Piezīme: pat ja jūs zvērat CSS-in-JS un nemīlat vaniļas CSS, mēs visi esam vienisprātis: mums visiem joprojām ir jāzina daži CSS ...

Tātad, neatkarīgi no tā, vai rakstāt CSS, vai kādu virsgrupu, piemēram, SASS, vai vienkārši CSS-in-JS, jums joprojām būs noderīgi, ja precīzi zināt, kā izskatās sliktā CSS.

Kas raksta komentārus? Neviens.

Šeit ir tik viegli paslīdēt, ka nepamanīsit ļoti ātri.

Mēs visi to zinām. Tu esi tik gudrs, ka visi pārējie netuvojas. Lai gan CSS nav izteiksmīgākā “valodās”, jūs varat izteikt pieņēmumus par pārlūkprogrammas dīvainībām, tos labot un pieņemt, ka sapratīsit, ko esat paveicis dažas nedēļas.

Cik gudrs, ja?

Atlieciet lepnumu malā un ietaupiet sevi un citus komandas biedrus.

Ja izmantojat ne tik acīmredzamu paņēmienu vai esat izlabojis kādu pārlūkprogrammas dīvainību vai visu, kas, jūsuprāt, nav pietiekami izteiksmīgs, uzrakstiet šo komentāru! Tas nesāp.

Komplekso atlasītāju zeme

Jā! Jūs tikko iemācījāties CSS un jūtaties pasaules virsotnē. Tātad, laiks parādīt dažus selektora muskuļus.

Slikta kustība.

Veicot atlasi ar pārāk daudziem CSS atlasītājiem, iespējams, esat veiksmīgi padarījis savu CSS ārkārtīgi neuzturamu. Tagad tas ir ļoti atkarīgs no jūsu lietotnes HTML struktūras.

Ja uzcenojuma struktūra nedaudz mainās, jums ir jāpārstrādā arī CSS. Nav vieglākā darbplūsma.

Vienkārši pievienojiet elementam klasi un turpiniet dzīvi!

Pat gadījumos, kad jums ir nepieciešams kvalificēt atlasītājus ar vairākām klasēm, vienmēr dodiet priekšroku vienkāršībai.

Vienkārši ir labi, gandrīz vienmēr!

Izrāde? Grāvi to!

Tātad, es to saprotu. Jums vienkārši nav vienalga par sniegumu. Jums viennozīmīgi ir vienalga par biznesu. Ja jūs to izdarītu, jūs nekaitinātu savus lietotājus ar saviem briesmīgajiem atlasītājiem, kas nav izpildīti.

Bet pagaidi…

Es saprotu, ka datori ir pieauguši ātrāk un pārlūkprogrammas turpina optimizēt. Neatkarīgi no tā, priekšroka vienmēr jādod vienkāršiem atlasītājiem, un izpratne par to, kā pārlūks šķērso DOM, lai atrastu jūsu atlasītāju, joprojām ir lieta!

Iespējams, jūs lasāt atlasītājus no kreisās uz labo pusi.

Tomēr pārlūkprogramma atbilst atlasītājiem no labās uz kreiso pusi, tāpēc tā var pēc iespējas ātrāk novērst elementus, kas nesakrīt.

Ja jūs to zinātu, iespējams, pārlūkprogrammās izturētos daudz saudzīgāk. Viņi ir pelnījuši jūsu mīlestību.

Ņemot vērā iepriekš redzamo grafikas piemēru, pārlūks saskaņos visus elementus (*) un pārbaudīs, vai tie ir pēcnācēji body.

body * { ... } 

Bet kāpēc? Gandrīz katrs redzamais elements ideālā gadījumā ir dy> element. That’s just a needless inefficient check.

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

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.