Mis errores más tontos de CSS

Reeditado por Platón

seguidores: 0

Todos cometemos errores en nuestro código. ¡Sucede! Sé que si tuviera uno de esos carteles de "Días desde el último error" colgado sobre mi escritorio, un gran huevo de gallina estaría flotando sobre mí todo el tiempo. Tampoco tiene que haber grandes errores. Mi torpe yo ha cometido pequeños errores en repositorios que van desde errores tipográficos hasta directorios completos de módulos npm.

Whooooops.

Esa es una de las cosas que realmente amo de CSS: perdona muchísimo. Si no entiende un error tipográfico, sigue buscando en la cascada en busca de una coincidencia. Nada de eso donde un personaje fuera de lugar rompe un sitio y no toma prisioneros. ¡Pero sigue siendo vergonzoso cuando aparecen errores de CSS!

Como este, me encuentro haciendo muchas más veces de las que me gustaría admitir:

.element {
  display: flexbox; /* 🤦‍♂️ */
}

O cuando trato de establecer un degradado sin un background propiedad:

.gradient {
  linear-gradient(45deg, rgb(50% 100% 90%), rgb(62% 85% 93%));
}

Odio lo cerca X y C están en un teclado porque no puedo contar cuántas veces estoy repasando algo y me equivoco px para pc unidades.

.element {
  font-size: 16pc; /* I meant pixels! */
}

Otro error de CSS que detecto de vez en cuando es uno que sé que cometen muchas otras personas porque lo veo con demasiada frecuencia en publicaciones de blog con fragmentos de código:

// This is not a CSS comment.
.element {
  /* This is a CSS comment. */
}

¿Alguna vez has olvidado usar var() alrededor de una variable CSS? seguro que tengo

.element {
  color: --primary-color;
}

Hablando de variables CSS, nombrarlas es difícil (como todo lo demás) ¡y a menudo uso alguna versión incorrecta de una variable que nombré!

:root {
  --color-primary: #FF5722;
  --color-secondary: #3E2723;
}

/* Much later on... */

.element {
  color: var(--primary-color); /* 🙃 */
}

Sí, de hecho, he copiado un fragmento de CSS antes solo para tener citas elegantes que se interponen en el camino para que funcione:

.element::before {
  content: “”; /* Should be "" */
}

Y sí, he pasado demasiado tiempo averiguando que esas citas eran las culpables.

Mirar ese último me recuerda que a veces me olvido de configurar el content propiedad cuando estoy trabajando con ::before or ::after. Lo que me recuerda cómo me olvidé de configurar un elemento position antes de intentar compensarlo o cambiar su z-index. ¡En serio, estas cosas pasan!

Es difícil hablar de errores

¿Alguna vez has terminado de leer una publicación de blog que comparte algún truco increíble y sentiste algún tipo de Síndrome del impostor? Creo que eso se debe en gran parte a que las publicaciones de blog a menudo enmascaran el trabajo real, y los fracasos, que se convierten en trucos increíbles. Como alguien que lee publicaciones como esa para ganarse la vida, puedo decirle que muchos, si no la gran mayoría, pasan por muchas rondas de edición donde los errores potencialmente vergonzosos se eliminan y suavizan.

Incluso esos artículos ridículamente asombrosos tienen que fallar antes de obtener todos esos ooooo y ahhhhhs.

Lo mismo se aplica a cualquier aplicación, sitio web, demostración o lo que sea que encuentres. Las posibilidades de que alguno de ellos saliera perfecto la primera vez son casi nulas.

Pero si te soy totalmente honesto, a menudo estoy más asombrado (e interesado) en el se necesita para lograr algo, con verrugas y todo. El viaje es un vistazo a lo que es pensar como un desarrollador front-end. Ahí es donde ocurre el aprendizaje real (y más valioso).

Y todo esto simplemente se está acumulando para lo que realmente quiero preguntar...