Prácticamente todos los sitios ahora se construyen con al menos un guiño al diseño web responsivo. La forma en que estructuramos estos estilos responsivos tiene una relación directa con la complejidad de mantener y editar el proyecto en el futuro a medida que se realicen actualizaciones y el proyecto crezca en tamaño.
A pesar de esto, parece que los desarrolladores aún no han adoptado de manera consistente un enfoque ampliamente aceptado sobre cómo y dónde estructurar estos estilos responsivos. Aunque no es tan malo como “los viejos tiempos” de CSS, antes de los preprocesadores y las metodologías de nombres, esto está provocando un enfoque inconsistente y a menudo desordenado para estructurar los estilos responsivos de los elementos.
¿Acabas de empezar con tu sitio? Elija un creador de sitios web y un servicio de alojamiento web de primer nivel. ¿Trabajando con un equipo grande? Asegúrese de que su almacenamiento en la nube mantenga a todos actualizados con su sistema de diseño.
CSS en el pasado
Para entender el problema al que nos enfrentamos, volvamos al principio. Una de las razones por las que se crearon preprocesadores de CSS como Sass o LESS en primer lugar es porque CSS puede volverse extremadamente complicado y es muy difícil de mantener. Solíamos descubrir que, después de un tiempo, incluso los sitios web pequeños tenían líneas y líneas de estilos CSS que se dejaban en su lugar simplemente porque el desarrollador no estaba seguro de si era necesario o los restos de una característica eliminada o un elemento desactualizado que podían eliminarse.
Tome el siguiente escenario como ejemplo:
.encabezado {fondo: #000000; }; .título {tamaño de fuente: 16px; }; .title_small { tamaño de fuente: 14px; } .title_alt { familia de fuentes: sans-serif; }
Aunque puede pensar que es seguro asumir que el elemento .title es el título del elemento .heading en este contexto, en realidad no puede estar completamente seguro de que no se utilice para diseñar ningún otro elemento de título en el sitio. . Además, ¿dónde se usa la clase .title_alt y todavía es necesaria o está en uso? Puede ver cómo incluso con un ejemplo tan simple puede convertirse en un ejercicio que requiere mucho tiempo verificar todo esto antes de realizar cambios.
Debido a esto, muchos desarrolladores ahorrarían tiempo agregando una nueva clase al elemento o usando un selector CSS más complejo para realizar los cambios que deseaban, lo que a su vez aumentaría la complejidad del CSS para la próxima vez que fuera necesario un cambio. .
Preprocesadores, convenciones de nomenclatura y CSS modular
Gracias a la capacidad de anidar estilos, usar variables, ampliar otras clases y más, los preprocesadores revolucionaron la forma en que creamos y mantenemos CSS. Desafortunadamente, no resuelven completamente el problema de los estilos obsoletos y desordenados que se propagan y crecen a lo largo de un proyecto a medida que envejece como una infección.
Surgieron las convenciones de nomenclatura y las metodologías CSS como BEM, que cuando se aplican dan un nivel mucho mayor de contexto a los estilos.
Cuando se combina con la realización de variaciones, modificaciones y estilos de elementos anidados autónomos mediante el uso de módulos CSS, nació una forma realmente sólida de estructurar sus estilos.
A continuación puede ver cómo estas mejoras pueden resolver los problemas que encontramos con nuestro ejemplo de código anterior:
.encabezado { fondo: $negro; } .heading__title { tamaño de fuente: 16px; &.heading__title–small { tamaño de fuente: 14px; } } .post__title–alt { font-family: sans-serif; }
Queda claro al instante que los estilos de título aquí están contenidos específicamente dentro del elemento de encabezado. Puede eliminarlos/editarlos de forma segura sin preocuparse de afectar otros elementos. También puedes ver que el título pequeño era una variación del título del encabezado, pero que el estilo del título alternativo era para otro elemento.
En mi opinión, al seguir esta combinación de estructura y metodología de nomenclatura, es bastante fácil crear estilos CSS limpios y fáciles de mantener. Se puede obtener contexto rápidamente y los módulos independientes de CSS se pueden copiar y pegar en otros proyectos, o modificarlos y eliminarlos con facilidad.
Puede parecer que el problema del código desordenado e imposible de mantener se resolvió. Pero a medida que el diseño responsivo se volvió cada vez más relevante, se hizo evidente que estábamos repitiendo muchos de nuestros errores y generando enfoques demasiado complejos y mal estructurados para crear sitios web responsivos.
Resolver este problema es donde entra en juego la difusión de consultas de medios.
Ubicaciones de estilo responsivo
Gracias a las mejoras mencionadas en nuestro enfoque para crear CSS, cada vez que heredo o colaboro en un proyecto en estos días, rara vez experimento el temor o la preocupación de que me estaba abriendo a caer en un infierno de especificidad o desorganización estructural que solía usar. tener en esas situaciones. Ahora sé que puedo encontrar y comprender rápidamente clases y estilos relevantes gracias a las metodologías de nomenclatura y realizar cambios sin consecuencias inimaginables para otros elementos, gracias a Modular CSS.
Desafortunadamente, una de las principales causas de frustración que encuentro es que los estilos responsivos todavía están ubicados de manera inconsistente en todo el proyecto. Es posible que estén contenidos dentro de una estructura modular y nombrados apropiadamente en una metodología de nomenclatura, pero proyecto por proyecto veo muchas formas diferentes en que los desarrolladores eligen incluir sus estilos responsivos.
Algunos crean un parcial Sass separado llamado _mobile.scss o _tablet.scss, por ejemplo. Algunos colocan consultas de medios en la parte inferior del archivo relevante en orden ascendente o descendente y otros simplemente las colocan aleatoriamente entre estilos de otros elementos. Con este enfoque, me encuentro tabulando entre archivos y desplazándome hacia la parte superior e inferior de los archivos solo para obtener una comprensión completa de los estilos de un elemento en diferentes puntos de interrupción.
Como puede ver, hay muchos problemas con esto que se combinan para hacer que el desarrollador dedique más tiempo a trabajar en cambios/enmiendas del que realmente es necesario.
Duplica estilos y dificulta el proceso de mantener y encontrar todos los estilos relevantes para un componente. Debe buscar en varias ubicaciones o archivos para obtener una imagen completa de los estilos de un elemento. El elemento ya no es autónomo. No puede reutilizarlo fácilmente en otro proyecto o eliminarlo/modificarlo con confianza sin efectos adversos o sin que quede código persistente. Para cada nuevo proyecto, se pierde tiempo descubriendo cómo ese proyecto aborda los estilos responsivos. Cambiar entre proyectos se vuelve más difícil porque tiene que cambiar entre se acerca en tu cabeza. Esto puede llevar a que los proyectos tengan accidentalmente una combinación de enfoques, lo que nuevamente conduce a un CSS desordenado.
La solución que me gusta implementar para solucionar este problema se llama Media Query Bubbling. La forma más sencilla de explicarlo es considerar que las consultas de medios son como cualquier otra variación de su elemento modular. Lo mismo que una clase de variación BEM de .heading__title es .heading__title (variación, por ejemplo). Esto significa que la consulta de medios debe estar anidada, al igual que las clases de modificación. Vea el siguiente código como ejemplo de esto:
.encabezado { fondo: $negro; Pantalla solo @media y (ancho mínimo: 640 px) { fondo: $blanco; } }
En este ejemplo, puede ver claramente en una ubicación que el fondo del encabezado cambia a blanco a 640 px o más. Al contener la consulta de medios junto con los estilos del elemento, una vez más ha creado un módulo totalmente autónomo que se puede reutilizar o editar con confianza. No es necesario verificar un archivo _mobile.scss ni buscar en el proyecto otras menciones de la clase para asegurarse de haber cubierto todos los puntos de interrupción.
Nuevamente, he visto muchas variaciones de cómo los desarrolladores eligen estructurar los estilos responsivos de sus elementos. Esto no debe considerarse diferente al diseño del elemento principal y todas las consultas y estilos de medios deben ser independientes. Vea el siguiente ejemplo:
.heading__title { tamaño de fuente: 16px; @pantalla solo de medios y (ancho mínimo: 640 px) { tamaño de fuente: 18 px; } &.heading__title–small { tamaño de fuente: 14px; @pantalla solo de medios y (ancho mínimo: 640 px) { tamaño de fuente: 16 px; } } }
Puede ver que el tamaño de fuente del encabezado__título aumenta cuando la ventana gráfica es de 640 píxeles o más y cómo la variación más pequeña del título del encabezado también se amplía, pero se define como más pequeña que el estándar. Al utilizar esta técnica, es muy importante aplicar firmemente la metodología BEM para asegurarse de no terminar anidando varios niveles de profundidad. Por ejemplo, asegúrese de que el elemento .heading__title sea un módulo CSS autónomo que no esté innecesariamente anidado dentro del elemento .heading.
Estilos de respuesta más limpios
Al tomar lo que aprendimos de los beneficios proporcionados por BEM y Modular CSS y aplicarlo a consultas de medios dentro de la misma estructura, evitamos repetir los errores de nuestro pasado.
Al trabajar con consultas de medios de esta manera, no es necesario aprender una metodología o estructura totalmente nueva para sus estilos. Básicamente, estamos tomando el enfoque CSS modular y aplicándolo a nuestras consultas de medios, lo que debería resultar bastante natural.
También estamos creando CSS más limpio con menos duplicación de clases de CSS entre archivos y ahorrando tiempo de desarrollo al eliminar la necesidad de verificar múltiples ubicaciones al realizar modificaciones.
Este artículo fue publicado originalmente en netola revista para diseñadores y desarrolladores web profesionales. Suscríbete a la red aquí.
Artículos relacionados:
