Cómo escribir CSS realmente terrible

Todo el mundo habla de "consejos" y "consejos profesionales" para escribir un CSS excelente.

Eso está bien, pero tal vez ver cómo se ve un CSS incorrecto le dará una perspectiva diferente. Demonios, ¡incluso puede hacerte un bien!

Déjame llevarte a través de un viaje sobre cómo escribir CSS realmente malo.

Listo?

Nota: incluso si juras por CSS-in-JS y no amas el CSS vainilla, todos estamos de acuerdo en algo: todavía tenemos que saber algo de CSS ...

Entonces, ya sea que escriba CSS, o algún superconjunto como SASS, o simplemente CSS-in-JS, aún se beneficiará de saber exactamente cómo es el CSS malo.

¿Quién escribe los comentarios? Ninguno.

Es tan fácil deslizarse aquí que no lo notará muy rápidamente.

Todos lo sabemos. Eres tan inteligente que todos los demás no se acercan. Aunque CSS no es el más expresivo de los “lenguajes”, puede hacer suposiciones sobre las peculiaridades del navegador, corregirlas y asumir que comprenderá lo que ha hecho unas semanas después.

Qué inteligente, ¿eh?

Deje a un lado su orgullo y ahórrese el estrés a usted mismo y a otros compañeros de equipo.

Si está utilizando una técnica no tan obvia, o ha solucionado alguna peculiaridad del navegador, o cualquier cosa que crea que no es lo suficientemente expresiva, ¡escriba ese comentario! No duele.

La tierra de los selectores complejos

¡Si! Acabas de aprender CSS y te sientes en la cima del mundo. Entonces, es hora de mostrar algunos músculos selectores.

Mal movimiento.

Al hacer selecciones con demasiados selectores de CSS, es posible que haya logrado que su CSS sea extremadamente inmantenible. Ahora depende en gran medida de la estructura HTML de su aplicación.

Si la estructura del marcado cambia ligeramente, también debes refactorizar tu CSS. No es el flujo de trabajo más sencillo.

¡Simplemente agregue una clase al elemento y continúe con su vida!

Incluso en escenarios donde necesite calificar selectores con múltiples clases, siempre favorezca la simplicidad.

¡Lo simple es bueno, casi siempre!

¿Actuación? ¡Deshazte de eso!

Entonces, lo entiendo. Simplemente no te importa el rendimiento. No te preocupas por el negocio, claramente. Si lo hiciera, no molestaría a sus usuarios con sus terribles selectores que no funcionan.

Pero espera…

Entiendo que las computadoras han crecido más rápido y los navegadores continúan optimizándose. Independientemente, siempre se deben preferir los selectores simples, ¡y comprender cómo el navegador atraviesa el DOM para encontrar su selector todavía es una cosa!

Lo más probable es que lea sus selectores de izquierda a derecha.

Sin embargo, el navegador hace coincidir los selectores de derecha a izquierda, por lo que puede eliminar los elementos que no coinciden lo más rápido posible.

Si supiera esto, probablemente sería más indulgente con los navegadores. Se merecen tu amor.

Teniendo en cuenta el gráfico de ejemplo anterior, el navegador coincidirá con todos los elementos (*) y también comprobará si son descendientes de body.

body * { ... } 

¿Pero por qué? Casi todos los elementos visibles son idealmente descendientes deldy> 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.