El gran error de consulta de medios CSS

¿Alguna vez te sientes raro cuando todos a tu alrededor están haciendo algo que normalmente pensarías que está mal [o que no es lo ideal por lo menos], pero de alguna manera nadie parece querer decir nada por una razón u otra? Es una sensación muy extraña ver a todos haciendo su mejor impresión de un desafortunado observador. Me recuerda a esa vieja fábula, "El traje nuevo del emperador".

Siempre me he sentido así con respecto a las consultas de medios CSS. ¿Por qué todo el mundo acepta tanto una tecnología que no parece estar haciendo el trabajo? ¿Por qué no nos hemos unido como comunidad y la hemos mejorado de una manera real y significativa? ¿Por qué no hemos encontrado algo mejor?

Hoy en día, las consultas de medios CSS resultan ser la piedra angular funcional del diseño web receptivo. Sin embargo, nunca fue diseñado para lo que todos usan hoy en día, y la prueba está en la práctica. Todavía me tropiezo con frecuencia con sitios web cuando uso un dispositivo de tableta que al principio parecen estar bien diseñados, pero se ven y se sienten francamente raros cuando los pones a prueba.

Hay algo fundamentalmente erróneo con este enfoque del diseño web receptivo que aún no hemos abordado adecuadamente, y me gustaría ser una de las pocas voces que llame al emperador por su desnudez en este caso. Sin embargo, afortunadamente, hoy en día, me alegro de que haya casi cero posibilidades de ser quemado en la hoguera por tener este punto de vista alternativo.

¿Qué hay de malo con las consultas de medios CSS?

Las consultas de medios CSS se diseñaron para algo, pero eso no es un diseño web receptivo. Según mi experiencia, aquí hay siete (7) problemas importantes con los que me he encontrado al intentar usarlos para trabajar con sitios web:

1. No intuitivo:

“Las consultas de medios CSS son intuitivas”, dijo ningún diseñador web nunca. La forma en que define una consulta de medios es bastante sencilla, pero no siempre está exactamente claro cómo se desarrollarán las cosas en navegadores reales, en dispositivos reales y en una miríada de escenarios.

 Pantalla solo @media y (ancho mínimo: 320 px) y (ancho máximo: 480 px) {
    /** Las reglas CSS van aquí **/
}

El código anterior se aplica a la ventana gráfica cuando tiene entre 320 y 480 píxeles. Sin embargo, no es exactamente definitivo [o intuitivo] cuando desea hacer algo más específico, como aplicar una regla de estilo cuando el dispositivo es una tableta en funcionamiento horizontal. No es imposible [más o menos] configurar una consulta de medios para hacer esto, pero definitivamente no es intuitivo ni definitivo.

2. Condicionalidad limitada:

Las consultas de medios CSS son dinámicas y le permiten definir declaraciones condicionales en su CSS. Por ejemplo, si la ventana gráfica está entre esto y aquello, haga lo otro. Sin embargo, está limitado principalmente a las consideraciones de la ventana gráfica, y hay muchos más escenarios condicionales que tendrían sentido en el diseño web moderno.

Digamos que está creando una aplicación web progresiva. Hay momentos en los que sería útil diseñar ciertos elementos de la interfaz de usuario de manera diferente según el sistema operativo. Por ejemplo, es habitual tener la barra de pestañas en la parte inferior para dispositivos iOS, mientras que para Android ocurre lo contrario. Entonces, ¿cómo harías exactamente para que esto funcione con las consultas de medios CSS?

No puede, porque las consultas de medios CSS no se crean con ninguna característica que le permita hacerlo. Además de esto, hay muchas otras personalizaciones que puede necesitar realizar a través de CSS, pero las consultas de medios no son una opción cuando necesita diversos grados de condicionalidad simple a avanzada.

3. No extensible de forma nativa:

Las consultas de medios CSS son funciones integradas en el navegador. Esto significa que no es extensible de forma nativa. En otras palabras, no puede agregar capacidades adicionales y mejoradas a las consultas de medios CSS de forma nativa a través de la interfaz CSS.

Incluso si las nuevas funciones de consulta de medios de CSS son aprobadas por el [sufrido] proceso de estándares web, aún lleva tiempo antes de que estas funciones se puedan utilizar debido a la ubicuidad. Además, no todas las funciones que se agregan pueden ser útiles para usted, por lo que debe encontrar otra forma de resolver su desafío específico si no obtiene lo que desea.

Por supuesto, hay una manera de extender CSS, pero debe conocer JavaScript muy, muy bien, y no es un proceso práctico para la mayoría de los diseñadores web.

4. No apto para reequipamiento:

Algunos pueden encontrar esto difícil de creer, pero antes de que aparecieran los dispositivos móviles, en realidad había muchos sitios web y ninguno de ellos era compatible con dispositivos móviles. Como resultado, estos sitios web de la era de escritorio debían actualizarse.

Desafortunadamente, las consultas de medios CSS no son una muy buena opción para esta tarea. Debido a que estos sitios web se crearon antes de que los dispositivos móviles fueran relevantes, muchos de ellos tienen elementos de diseño que no se prestan a un diseño web receptivo, por ejemplo, barras laterales, diseños basados ​​en tablas, contenido con pestañas, etc. Además, una proporción considerable de estos sitios web son construido sobre un sistema de administración de contenido (CMS) como WordPress, Drupal, Magento, etc., e integrar consultas de medios CSS [front-end] de manera efectiva desde el back-end es extremadamente difícil o casi imposible de coordinar.

Tuve que actualizar sitios web con tecnología de Magento Enterprise, WordPress y uno que usaba un CMS personalizado basado en Coldfusion, y todos los proyectos habrían sido absolutamente imposibles usando consultas de medios CSS [que es lo que todos mis clientes probaron antes de usar nuestra alternativa Acercarse].

5. Código no eficiente:

El uso de consultas de medios CSS para hacer que una página web responda requiere la multiplicación de código en una escala significativa. Debido a la forma en que funcionan estas directivas [con sus puntos de interrupción], debe definir reglas de estilo individuales en todos y cada uno de los bloques de consulta de medios.

 sección {ancho: 960px;}

/* Retrato */
@media solo pantalla y (ancho mínimo del dispositivo: 320 px) y (ancho máximo del dispositivo: 480 px) y (-webkit-min-device-pixel-ratio: 2) y (orientación: retrato) {
    sección {ancho: 100%}
}
/* Paisaje */
@media solo pantalla y (ancho mínimo del dispositivo: 320 px) y (ancho máximo del dispositivo: 480 px) y (-webkit-min-device-pixel-ratio: 2) y (orientación: horizontal) {
    sección {ancho: 100%;}
}

Al escribir el código anterior, mi intención original era hacer que los elementos <section> de mi página fueran fluidos [ancho del 100 %] en todos los dispositivos móviles. Sin embargo, dado que no tengo la capacidad nativa de detección de dispositivos, tengo que comprometerme y definir una regla de estilo en todos y cada uno de los bloques de consulta de medios CSS orientados a dispositivos móviles para asegurarme de que la nueva propiedad se aplicará en todos los escenarios relevantes.

Esto significa que la eficiencia funcional de la cascada de hojas de estilo y los buenos principios de desarrollo de Do-Not-Repeat-Yourself deben quedar en un segundo plano.

6. Aumenta la complejidad del flujo de trabajo:

Las consultas de medios CSS manejan solo un aspecto muy específico del diseño web receptivo que se centra casi por completo en el cambio de tamaño del diseño. Ergo, para hacer algo más que eso, debe confiar en JavaScript para compensar la diferencia. Esto introduce requisitos de aprendizaje adicionales para el código y las herramientas.

Además, la forma no definitiva en que [las consultas de medios] maneja los puntos de interrupción significa que tiene que dedicar más tiempo [y dinero] a probar sus páginas web en numerosos dispositivos virtuales y/o físicos para asegurarse de que las cosas funcionen de la manera que originalmente pretendía. . Y debe volver a probar todo nuevamente cuando realice cambios significativos en su diseño.

Mediante la acción simple y decidida de usar consultas de medios CSS, aumenta significativamente la cantidad de pasos necesarios para crear una página web moderna.

7. Empeora el rendimiento:

Debido a la forma en que funcionan las consultas de medios CSS, terminará necesitando mucho más código CSS que de otra manera para que su sitio web sea receptivo/amigable para dispositivos móviles. Según datos de HTTPArchive.org, el tamaño de los archivos CSS ha aumentado un 114 % en los últimos cinco años. El aumento en el tamaño de los archivos HTML alcanzó un máximo de alrededor del 53 % durante el mismo período.

Esta situación peculiar tiene implicaciones en el rendimiento de su sitio web, ya que después de implementar consultas de medios CSS [en un contexto de diseño web receptivo], seguramente será más lento que antes, especialmente para dispositivos móviles que usan redes de banda ancha móvil menos que ideales.

Y, además del problema del aumento del tamaño de los archivos, no existe un mecanismo interno dentro de las consultas de medios CSS para mejorar realmente el rendimiento de su página web. Para eso, tendrá que aprovechar las técnicas avanzadas de JavaScript para habilitar estas mejoras.

¿Por qué seguimos usando esto?

Si te preguntara qué porcentaje de sitios web usan consultas de medios CSS, ¿cuál sería tu respuesta? Con todo el estrés que los diseñadores web han tenido que soportar a lo largo de los años, uno pensaría que probablemente ya habríamos superado el obstáculo de la adopción, pero estaría muy equivocado.

El porcentaje de sitios web que utilizan consultas de medios CSS en toda la web es de alrededor del 0,2 %. Compare eso con el porcentaje de sitios web que usan jQuery en 18%. Lo que eso significa es que tiene 90 veces más probabilidades de encontrarse con un sitio web que funciona con jQuery que con un sitio web receptivo [sin incluir los que resultan ser ambos].

¿Por qué un conjunto de herramientas basado en una tecnología central [JavaScript] que ciertas personas parecen pensar que es complicada y superflua estaría tan por delante de uno que aparentemente es menos complejo [CSS] y destinado a abordar un problema posiblemente más importante [amigable con dispositivos móviles]? ? Obviamente, hay algo gravemente mal aquí que está obstaculizando la adopción y debe abordarse.

Las consultas de medios CSS encontraron su camino en los navegadores web para manejar un desafío específico, pero luego se redactó para llevar todo el peso del diseño web receptivo sobre sus hombros. Es como practicar para un recital de flauta dulce de tercer grado, solo para ser transportado mágicamente al Royal Albert Hall para interpretar un solo de trombón del Mesías de Handel; ¡No es justo!

Con todos los desafíos del diseño web moderno, es extremadamente sorprendente que todavía estemos en este negocio de consultas de medios. No va lo suficientemente lejos como para tratar algunos problemas heredados importantes, además de algunos nuevos en campos nuevos como el diseño progresivo de aplicaciones web. Como tal, creo que es hora de que encontremos una alternativa. Pero, ¿qué sería eso exactamente?

¿Cuál es la solución?

La solución a todo esto es realmente muy simple: JavaScript. Ahora, antes de que tomes esa horca, dame la oportunidad de explicarte.

JavaScript es el único componente de la trinidad de HTML5 donde la extensibilidad no es una mala palabra. No puede extender el marcado HTML usando más HTML, y seguro que no puede extender CSS de forma nativa con CSS. Sin embargo, puede extender JavaScript de forma nativa usando JavaScript, e incluso puede hacer lo mismo con CSS.

La manipulación de CSS con JavaScript se analiza ampliamente en el plan de estudios de estándares web del W3C. La interfaz DOM document.stylesheets nos permite acceder a las hojas de estilo aplicadas a una página web, incluidas todas las hojas de estilo externas a las que se hace referencia mediante la etiqueta <link> de HTML. No es algo fácil de hacer, pero es posible.

Así que debería ampliar la respuesta inicial: no es simplemente JavaScript, es CSS asistido por JavaScript . JavaScript es una plataforma increíble con una funcionalidad que no creerías, pero CSS es donde trabajan la mayoría de los diseñadores web. Si de alguna manera pudiéramos crear algún tipo de puente funcional entre estos dos donde un diseñador web pudiera escribir un conjunto de reglas CSS para aprovechar la funcionalidad de JavaScript, eso sería un cambio de juego para el diseño web.

Muéstrame algo de código

Durante los últimos dos años, he estado trabajando en un nuevo kit de herramientas CSS asistido por JavaScript llamado rKit. La idea general era crear una herramienta fácil de diseñar para no solo reemplazar las consultas de medios CSS por un diseño web receptivo, sino para abordar algunos de los desafíos conocidos [y desconocidos] que enfrentan los diseñadores/desarrolladores web al crear sitios web y aplicaciones web modernos.

Hay mucho en el concepto, pero aquí hay un fragmento de código rápido de CSS para explicarlo:

 #my-element[rk="if @viewport.width entre 320 y 480"]{background-color: #0000ff;}

Con rKit, las reglas de CSS parecen selectores de valor de atributo modificados. A continuación, puede definir una expresión dentro de la sección de valor. La sintaxis de esta expresión está diseñada para ser simple e intuitiva.

Nota : rk es un identificador de atributo constante.

El código anterior es funcionalmente equivalente a la consulta de medios CSS a continuación:

 Pantalla solo @media y (ancho mínimo del dispositivo: 320 px) y (ancho máximo del dispositivo: 480 px) {
    #mi-elemento {color-de-fondo:#0000ff;}
}

Sin embargo, hay mucho más que puede hacer con rKit. Aquí hay otro ejemplo rápido:

 #my-element[rk="if @self.width between 320 and 480"]{background-color: #00ff00;}

Simplemente cambiando la referencia de la entidad de @viewport a @self , esencialmente hemos configurado lo que comúnmente se conoce como una consulta de elementos. Entonces, lo que sucede ahora es que cuando el ancho de #my-element está entre 320 y 480 píxeles, se aplicará la declaración dada [ background-color: #00ff00 ].

También puede usar clases en lugar de declaraciones puras:

 #my-element[rk="if @self.width entre 320 y 480 entonces addClass(c_mobile_320)"]{}
.c_mobile_320 {color de fondo: #00ff00;}

Sin embargo, esto es solo la punta del iceberg. Con rKit, puede hacer cosas increíbles como gestión de eventos, observación de mutaciones, consultas de cantidad, enrutamiento, enlace de datos [hasta 7 vías] y muchas otras cosas geniales, todo usando código CSS puro y sin escribir. una sola línea de JavaScript.

rKit será gratuito y de código abierto cuando se lance. Y también tendrá un paquete de rendimiento especial que puede instalar de una manera que garantiza cero bloqueos de procesamiento, por lo que la página web se carga como un cohete sobre rieles.

Me tomó bastante tiempo armar esto, pero estará aquí pronto [definitivamente antes que Godot], y estoy realmente interesado en ver qué pueden hacer los diseñadores web [y desarrolladores] con él.

Conclusión

Espero que no salgas de esta publicación pensando que estoy criticando las consultas de medios CSS solo porque sí. No soy. Sería como machacar un tomate por terminar en una ensalada de frutas. Como dije antes, las consultas de medios CSS nunca se diseñaron para un diseño web receptivo. Fue cooptado por conveniencia, y todos cometimos el paso en falso de tratar de usarlo para resolver todos los problemas.

Lamentablemente, nosotros, como comunidad web, nunca logramos corregir ese error inicial mejorándolo de manera significativa o presentando una alternativa mejor. Pero, por desgracia, los espectáculos deben continuar, los sitios web deben construirse y el progreso debe prevalecer. Es tiempo de un cambio.

rKit es simplemente una opción y una respuesta. No es el primero, y definitivamente no será el último. Pero, al menos, es un paso correcto en la dirección correcta. Una oportunidad para solucionar algunos problemas del pasado y luego iterar para solucionarlos en el presente y en el futuro. Sería interesante ver cómo se compara con el statu quo.

A fin de cuentas, cometer un error no es un fin en sí mismo; debe ser una experiencia de aprendizaje. Con un poco de suerte, aprenderemos a usar la herramienta correcta para el trabajo correcto la próxima vez. Quiero decir, el hecho de que puedas andar en bicicleta en una carretera pavimentada no significa que debas llevar una a Nurburgring. ¡Trae un Porsche!