CSS Custom Reset

Este es el enésimo artículo sobre hojas de estilo para unificar etiquetas HTML entre navegadores, es decir, para intentar que los diferentes navegadores web las representen visualmente de la misma forma.

Un artículo que no hacía falta escribir porque puedes encontrar de sobra alternativas con una simple búsqueda, pero quería compartir contigo mi visión y mi opinión más que una hoja de estilos, aunque ésta va a ser por donde vamos a empezar.

/* Modelo de caja más intuitivo y tamaño de fuente según las preferencias del usuario */
html {
  box-sizing: border-box;
  font-size: 100%;
}

/* Fuerza la herencia */
*,
*::before,
*::after {
  box-sizing: inherit;
}

/* Mejora la legibilidad del texto */
body {
  text-rendering: optimizeSpeed;
  line-height: 1.5;
  -webkit-font-smoothing: antialiased;
}

/* Elimina márgenes */
body,
h1,
h2,
h3,
h4,
h5,
h6,
p,
figure,
blockquote {
  margin: 0;
}

/* Facilita estilarlos */
img,
picture,
video {
  display: block;
  max-width: 100%;
}

/* Fuerza la herencia de la fuente */
input,
button,
textarea,
select {
  font: inherit;
}

/* Corta palabras muy largas e indivisibles */
a,
p,
h1,
h2,
h3,
h4,
h5,
h6 {
  overflow-wrap: break-word;
}

/* Elimina animaciones según las preferencias del usuario */
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Como verás no hay nada especial, ningún salvavidas. Estamos lejos de los tiempos en los que las etiquetas HTML5 había que declararlas como display: block para que se renderizasen bien, y a día de hoy los navegadores están más alineados que nunca.

¿Sabías por qué?

La propiedad display para cualquier etiqueta tiene por defecto el valor inline, pero los navegadores son los que se encargan en un primer estilado de aplicar el tipo block a etiquetas como header, pero no siempre fue así.

Haz tu propia hoja de estilos y evoluciónala

No cuesta nada. Cada vez que empieces un proyecto, en lugar de buscar una hoja de estilos de terceros, empieza tú mismo la tuya con los ajustes básicos que creas que vas a necesitar, y a medida que avances en el proyecto, como seguro que irás comprobando en diferentes navegadores a la vez, podrás ver cuándo algo se renderiza de manera diferente y podrás actuar, añadiendo o corrigiendo cosas y haciéndola crecer.

/* Una primera aproximación */
* { 
	box-sizing: border-box; 
	margin: 0; 
	padding: 0; 
}

Añade cosas cuando las necesites

¿Por qué deberíamos cargar más CSS del necesario? Cuando iniciamos un proyecto lo hacemos con las dependencias justas que sabemos que vamos a utilizar, y lo mismo debería ser con el CSS. No maquetamos módulos que no han sido diseñados, ¿verdad?

No es una cuestión de ahorrar KB, no va a haber diferencia, sino una cuestión de disciplina y limpieza de código.

Algunos casos

Los navegadores añaden a la etiqueta address por defecto un estilo itálica, algo que probablemente no encaje con el visual de nuestra interfaz.

¿Deberíamos corregirlo y añadirlo a nuestro reset?

address { 
  font-style: normal;
}

Puede que sí, porque pocos sitios web no tienen una sección con una dirección o datos de contacto, así que en ese caso, sí, podríamos añadirla porque parece algo que se va a repetir en el futuro.

Por otro lado, Safari estila el indicador de details > summary diferente a Chrome o Firefox, lo cual es un poco molesto.

De modo que si queremos eliminarlo, tenemos que ser más explícitos.

/*
NOTE: remove webkit-details-marker is not recommended
but in this case we need to do it because of Safaridetails 
*/

summary::-webkit-details-marker,
details summary::marker {  
  display: none;  
  content: "";
}

¿Debería esto ir a nuestra hoja de reset?. Probablemente no porque no en todos los proyectos usaremos estas etiquetas, pero lo bueno es que ya hemos aprendido que esto es así, así que cuando lo volvamos a utilizar sabremos lo que va a ocurrir. De todas formas puede que en el futuro se unifiquen y este ajuste ya no sea necesario.

Otro ejemplo, ¿merece la pena añadir en todos tus proyectos un scroll suavizado para la navegación con anclas dentro de una misma página?. Porque parece atractivo, pero no a todo el mundo le convence, además, hay que tener en cuenta a los usuarios que tienen entre sus preferencias la eliminación de efectos, animaciones y transiciones, así que si decides añadirla, hazlo así:

html:focus-within {
  scroll-behavior: smooth;
}

@media (prefers-reduced-motion: reduce) {
  html:focus-within {
   scroll-behavior: auto;
  }
}

¿Tiene sentido hacer un ajuste general del foco para los elementos interactivos?. Parece una práctica orientada a accesibilidad bastante correcta, pero a lo mejor no coincide con las especificaciones de tu proyecto, así que nuevamente, depende.

:is(a, button, input, textarea):focus-visible {  
  outline-offset: 2rem;
  outline-color: #f06;
}

Como verás, hay muchas preguntas de este estilo que podemos hacernos, y creo que la solución correcta es, a fin de cuentas, dar forma a tu proprio criterio y tomar tus propias decisiones basadas en tu conocimiento y experiencia.

Aprende por el camino

Tal y como lo veo, el “problema” de usar soluciones de terceros es precisamente que son soluciones de terceros, creadas para solucionar problemas de terceros, pero no los tuyos.

Si hablamos de hojas de reset, muchas van a lo básico, dan detalles muy útiles de gran ayuda y pueden encajar en cualquier proyecto. Consúltalas, aprende de ellas, pero haz la tuya propia, porque hacer la tuya tiene una ventaja añadida, y es que aprendes por el camino, porque tienes que validar qué vas a añadir, por qué lo necesitas y qué problema resuelve, o sea que el aprendizaje está garantizado.

¿Recuerdas el ejemplo de las etiquetas HTML5 de arriba? Piensa en ello. Puedes mecánicamente copiar/pegar una hoja de estilos de terceros y problema resuleto. O puedes, utilizando la tuya, darte cuenta que algo no va bien, inspeccionar tus estilos y detectar que display tiene un valor inesperado, seguir explorando y entender el motivo y resolverlo, lo que te llevará a concocer alguno de los oscuros recovecos de CSS.

Falta de tiempo

Pregúntate si de verdad no tienes tiempo para este ejercicio. Si la respuesta es “no”, algo está mal en tu proceso. Además, sólo necesitas un mínimo de dedicación la primera vez, porque cuando arranques un segundo proyecto podrás partir de la anterior, revisitarla, borrar lo que no necesites y añadir algo que hayas aprendido en tu experiencia anterior.

Conclusión

No perder nunca el control de nuestro código es clave para un producto de calidad, obviamente no digo que no podamos apoyarnos en el trabajo desarrollado por terceros o librerías, pero sí que sepamos lo que estamos haciendo, de modo que nada se convierta en cajas negras o mágicas. De hecho, me parece muy inteligente buscar y leer qué hacen otros desarrolladores, compartir opiniones y experiencias con otros compañeros.

Las especificaciones de CSS y los navegadores cambian con el tiempo, por eso me parece importante hacerlas a mano, para evitar el automatismo y arrastrar cosas superfluas, que ya no aplican. Estas hojas de normalización entre navegadores son, al mismo tiempo, la primera y más importante piedra sobre la que construimos nuestra interfaz y la más olvidada.

Tanto si tu hoja de estilos incluye algo más como si prefieres usar alguna solución ya escrita, ¡deja tu comentario debajo!