Hogyan kell igazán szörnyű CSS-t írni

Mindenki „tippekről” és „pro-tippekről” beszél a nagyszerű CSS megírásához.

Ez rendben van, de talán látva, hogy milyen a rossz CSS, más perspektívát kap. A fene, ez még jót is jelenthet neked!

Engedje meg, hogy végigvigyen egy olyan utat, amely valóban rossz CSS-t ír.

Kész?

Megjegyzés: Még akkor is, ha esküszöl a CSS-in-JS-re, és nem szereted a vanília CSS-t, mindannyian egyetértünk a dologban: mindannyiunknak ismernie kell néhány CSS-t ...

Tehát, függetlenül attól, hogy CSS-t ír, vagy valami szuperhalmazt, például SASS-ot, vagy csak CSS-in-JS-t, akkor is hasznot húz, ha pontosan tudja, hogy néz ki a rossz CSS.

Ki ír megjegyzéseket? Senki.

Olyan könnyű ide csúszni, hogy nem veszi észre nagyon gyorsan.

Mindannyian tudjuk. Olyan okos vagy, hogy mindenki más nem jön közel. Annak ellenére, hogy a CSS nem a legkifejezőbb a „nyelvekben”, feltételezheti a böngésző furcsait, kijavíthatja azokat, és feltételezheti, hogy meg fogja érteni, mit tett néhány hete a sorban.

Milyen okos, mi?

Tegye félre büszkeségét, és mentse meg magát és más csapattársait a stressztől.

Ha nem túl nyilvánvaló technikát használ, vagy javított valamilyen böngésző-furcsaságot, vagy egyáltalán bármi, ami úgy gondolja, hogy nem elég kifejező, írja meg ezt a megjegyzést! Nem árt.

A komplex választók földje

Igen! Most tanultad meg a CSS-t, és érzed magad a világ tetején. Szóval, ideje megmutatni néhány szelektív izmot.

Rossz mozdulat.

Túl sok CSS-választóval történő kiválasztással sikeresen rendkívül fenntarthatatlanná tette a CSS-t. Most nagyban függ az alkalmazás HTML-szerkezetétől.

Ha a jelölés szerkezete kissé megváltozik, akkor a CSS-t is át kell alakítania. Nem a legkönnyebb munkafolyamat.

Csak adjon hozzá egy osztályt az elemhez, és folytassa az életet!

Még mindig olyan esetekben, amikor több osztályú szelektort kell minősítenie, mindig támogassa az egyszerűséget.

Az egyszerű jó, szinte mindig!

Teljesítmény? Ditch That!

Szóval, értem. Csak nem érdekel a teljesítmény. Nem érdekel az üzlet, egyértelműen. Ha megtennéd, nem bosszantanád a felhasználókat a szörnyű, nem teljesítő szelektoraiddal.

De várj…

Megértem, hogy a számítógépek gyorsabban növekedtek, és a böngészők továbbra is optimalizálódnak. Ettől függetlenül mindig az egyszerű választókat kell előnyben részesíteni, és még mindig meg kell érteni, hogy a böngésző hogyan halad át a DOM-on, hogy megtalálja a választót!

Valószínű, hogy balról jobbra olvassa végig a választóit.

A böngésző azonban jobbról balra illeszti a választókat, így a lehető leggyorsabban kiküszöböli azokat az elemeket, amelyek nem egyeznek.

Ha tudná ezt, valószínűleg engedékenyebb lenne a böngészőkkel szemben. Megérdemlik a szerelmedet.

Figyelembe véve a fenti grafikus példát, a böngésző minden elemnek megfelel (*), és azt is ellenőrzi, hogy ezek leszármazottai-e body.

body * { ... } 

De miért? Szinte minden látható elem ideális esetben ady> 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.