Svi govore o "savjetima" i "pro-savjetima" za pisanje izvrsnog CSS-a.
To je u redu, ali možda ćete vidjeti kako izgleda loš CSS dati drugu perspektivu. Dovraga, možda ti čak i dobro dođe!
Dopustite mi da vas vodim kroz putovanje kako napisati jako loš CSS.
Spreman?
Napomena: čak i ako se zaklinjete u CSS-in-JS i ne volite CSS od vanilije, svi se slažemo u nečemu: svi još uvijek moramo znati neki CSS ...
Dakle, bez obzira pišete li CSS, ili neki superset kao što je SASS, ili samo CSS-in-JS, i dalje ćete imati koristi ako znate točno kako loš CSS izgleda.
Tko piše komentare? Nitko.
Ovdje je tako lako skliznuti da to nećete primijetiti vrlo brzo.
Svi to znamo. Tako si pametan, svi ostali se ne približavaju. Iako CSS nije najizražajniji od "jezika", možete pretpostaviti o hirovima preglednika, popraviti ih i pretpostaviti da ćete razumjeti što ste učinili nekoliko tjedana.
Kako pametno, ha?
Stavite svoj ponos na stranu i spasite sebe i ostale suigrače od stresa.
Ako se služite ne baš očitom tehnikom ili ste popravili neku neobičnost preglednika ili nešto što smatrate nedovoljno izražajnim, napišite komentar! Ne boli.
Zemlja složenih selektora
Da! Upravo ste naučili CSS i osjećate se na vrhu svijeta. Dakle, vrijeme je da pokažemo neke selektorske mišiće.
Loš potez.
Odabirom s previše CSS birača, možda ste uspješno učinili svoj CSS izuzetno neodrživim. Sada je jako ovisan o HTML strukturi vaše aplikacije.
Ako se struktura oznaka malo promijeni, trebate refaktorirati i svoj CSS. Nije najlakši tijek rada.
Samo dodajte predavanje elementu i nastavite sa životom!
Čak i u scenarijima u kojima trebate kvalificirati selektore s više klasa, uvijek favorizirajte jednostavnost.
Jednostavno je dobro, gotovo uvijek!
Izvođenje? Baci to!
Dakle, shvaćam. Jednostavno vas nije briga za izvedbu. Ne zanima vas posao, jasno. Da jeste, ne biste živcirali svoje korisnike svojim užasnim nenamjenskim selektorima.
Ali čekaj…
Razumijem da su računala rasla brže, a preglednici se i dalje optimiziraju. Bez obzira na to, uvijek bi trebalo davati prednost jednostavnim selektorima, a razumijevanje načina na koji preglednik prelazi DOM da bi pronašao vaš selektor još uvijek je stvar!
Vjerojatno čitate svoje selektore slijeva udesno.
Međutim, preglednik se podudara s biračima zdesna nalijevo, tako da može što brže eliminirati elemente koji se ne podudaraju.
Da to znate, vjerojatno biste bili blaži prema preglednicima. Zaslužuju vašu ljubav.
Uzimajući u obzir gornji primjer grafike, preglednik će se podudarati sa svim elementima (*) i provjeriti jesu li oni potomci body.
body * { ... } Ali zašto? Gotovo svaki vidljivi element idealno je potomak
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.
