CSS Media Queries

El lenguaje CSS (“Cascading Style Sheets” en español “hojas de estilo en cascada”), junto con HTML y Ja­va­S­cri­pt, forman la es­tru­c­tu­ra básica para el de­sa­rro­llo de las páginas web modernas. El CSS es un lenguaje de pro­gra­ma­ción, pero no describe los pasos in­di­vi­dua­les para resolver un problema. En lugar de ello, define un objetivo que se debe alcanzar. Esto convierte a CSS en un lenguaje de­cla­ra­ti­vo similar a SQL.

Parte del lenguaje CSS son las llamadas Media Queries, que consultan las ca­ra­c­te­rí­s­ti­cas técnicas del di­s­po­si­ti­vo de salida. Se utilizan para el diseño web re­s­po­n­si­vo (también diseño re­s­po­n­si­vo o re­s­po­n­si­ve web design). ¿Cómo funciona exac­ta­me­n­te?

Las CSS Media Queries se in­tro­du­je­ron con la es­pe­ci­fi­ca­ción CSS3. Una Media Query vincula la asi­g­na­ción de pro­pie­da­des CSS que tiene un elemento a una o varias co­n­di­cio­nes de medios. En el caso más sencillo, se distingue la in­fo­r­ma­ción que se muestra en cada medio: en una pantalla, en una página impresa (esto incluye también la salida como PDF) o en forma de texto leído en voz alta:

Un CSS Media Query se define dentro de un bloque de código CSS mediante una regla especial: ‘@media’. Las reglas y se­le­c­to­res CSS co­n­te­ni­dos en el bloque de código solo se activan bajo las co­n­di­cio­nes que se hayan es­pe­ci­fi­ca­do. Por ejemplo, los elementos que no deben ser mostrados pueden ser ocultados a la hora de im­pri­mi­r­se en una página:

Además del medio utilizado, se pueden utilizar CSS Media Queries para solicitar es­pe­cí­fi­ca­me­n­te las ca­ra­c­te­rí­s­ti­cas del medio re­s­pe­c­ti­vo. Las CSS Media Queries son, por tanto, la ca­ra­c­te­rí­s­ti­ca técnica principal que ha permitido que surja el re­s­po­n­si­ve webdesign.

El diseño re­s­po­n­si­vo tiene como objetivo adaptar la vi­sua­li­za­ción de una página web a cada di­s­po­si­ti­vo de la mejor manera posible. Las Media Queries se utilizan para obtener las ca­ra­c­te­rí­s­ti­cas técnicas del di­s­po­si­ti­vo que solicita la vi­sua­li­za­ción de la página web. Las obtiene so­li­ci­ta­n­do al di­s­po­si­ti­vo las llamadas Media Features. De esta manera, es posible definir reglas de estilo para di­fe­re­n­tes di­me­n­sio­nes de pantalla. Es más, se pueden definir reglas de estilo op­ti­mi­za­das para cuando se inclina el di­s­po­si­ti­vo móvil.

A co­n­ti­nua­ción, un resumen de las ca­ra­c­te­rí­s­ti­cas de los Media Features que se utilizan ac­tua­l­me­n­te con más fre­cue­n­cia para el diseño re­s­po­n­si­vo:

Veamos algunos ejemplos. Ima­gi­ne­mos el título principal de una página web. HTML pro­po­r­cio­na el elemento ‘h1’ para el título. En primer lugar, es­ta­ble­ce­re­mos las reglas de estilo para el elemento h1 in­de­pe­n­die­n­te­me­n­te del di­s­po­si­ti­vo que lo visualice:

A co­n­ti­nua­ción, definimos una Media Query que solicita el ancho de la pantalla. Dentro de la solicitud, definimos las reglas de estilo que deben aplicarse al título en función del ancho que tenga. En este ejemplo en concreto, au­me­n­ta­mos el tamaño de la fuente del título h1 en las pantallas que tienen al menos 1024 píxeles de ancho:

Ten en cuenta que aquí solo ajustamos la propiedad ‘font-size’ del título h1. El in­te­r­li­nea­do se define como una unidad relativa mediante la propiedad ‘line-height’ y su valor se hereda hasta que una nueva línea de código lo so­bre­s­cri­ba. En este ejemplo concreto, el in­te­r­li­nea­do del elemento h1 es por defecto de 24px * 1.25 = 30px. En pantallas con una anchura de 1024 píxeles o más, el in­te­r­li­nea­do aumenta pro­po­r­cio­na­l­me­n­te, por ejemplo: 36px * 1.25 = 45px.

Esta mezcla de reglas de estilo exi­s­te­n­tes y recién definidas se expresa en el lenguaje CSS con la palabra “cascading”: un elemento hereda las reglas de estilo de sus elementos padre o de las reglas generales ya definidas. No­r­ma­l­me­n­te, se es­ta­ble­cen unas pro­pie­da­des por defecto para los elementos para luego so­bre­s­cri­bi­r­las in­di­vi­dua­l­me­n­te en función de las ci­r­cu­n­s­ta­n­cias.

Otro ejemplo: ima­gi­ne­mos que queremos mostrar tres elementos en un co­n­te­ne­dor. Los elementos deben aparecer uno debajo de otro en la pantalla del di­s­po­si­ti­vo móvil cuando éste se mantiene en posición vertical. Cuando el di­s­po­si­ti­vo se pone en posición ho­ri­zo­n­tal, el layout de la pantalla debe cambiar para que los elementos se muestren uno al lado del otro. Con el módulo Flexbox Layout y una CSS Media Query, que solicita la orie­n­ta­ción del di­s­po­si­ti­vo, se puede co­n­di­cio­nar el layout del di­s­po­si­ti­vo a su orie­n­ta­ción en unas pocas líneas de código HTML y CSS. A co­n­ti­nua­ción, definimos el co­n­te­ne­dor y los elementos que contiene en HTML:

Además, definimos las si­guie­n­tes reglas CSS. Definimos la propiedad ‘display: flex’ para el co­n­te­ne­dor y definimos la propiedad ‘flex-direction’ co­n­di­cio­na­da por la CSS Media Query. Si se posiciona el di­s­po­si­ti­vo de manera ho­ri­zo­n­tal (apaisada), los elementos se mostrarán en una fila, uno al lado del otro; en cambio, si se posiciona el di­s­po­si­ti­vo de manera vertical, los elementos se mostrarán en una columna, uno debajo del otro.

Además de las di­me­n­sio­nes de le pantalla y la orie­n­ta­ción del di­s­po­si­ti­vo, también podemos solicitar los datos de la re­so­lu­ción física de la pantalla mediante una Media Query. Esto es es­pe­cia­l­me­n­te in­te­re­sa­n­te para mostrar las imágenes co­m­pue­s­tas por píxeles. Imagínate este ejemplo: un logotipo está di­s­po­ni­ble en dos versiones, una versión op­ti­mi­za­da para pantallas de baja calidad y la otra para pantallas de alta calidad. Un truco sencillo para mostrar el logotipo adecuado en cada caso es poner ambos en la página web, usar un CSS Media Query para consultar la re­so­lu­ción de pantalla del di­s­po­si­ti­vo e im­ple­me­n­tar ‘display: none’ para ocultar la versión que no le co­rre­s­po­n­da. Este tipo de solución se podría im­ple­me­n­tar en el código HTML y CSS de la siguiente manera:

En las ex­pli­ca­cio­nes an­te­rio­res, hemos hablado de la “pantalla” en relación con la anchura di­s­po­ni­ble del di­s­po­si­ti­vo de salida. Esto es co­n­ce­p­tua­l­me­n­te correcto, pero té­c­ni­ca­me­n­te no lo es del todo. El navegador opera in­te­r­na­me­n­te con el concepto de “viewport”. Para que la anchura del viewport se co­rre­s­po­n­da realmente con la anchura de la pantalla, se necesita definir un ‘meta-viewport’ en el ‘<head>’ del documento HTML. Sin este dato, la página se muestra en los di­s­po­si­ti­vos móviles igual que en el PC, lo que reduce drá­s­ti­ca­me­n­te su tamaño.

En el re­s­po­n­si­ve webdesign, los elementos deben adaptarse al espacio di­s­po­ni­ble en la pantalla. A menudo se trata de es­pe­ci­fi­car las di­me­n­sio­nes de los elementos en di­fe­re­n­tes co­n­di­cio­nes. El lenguaje CSS define una variedad de unidades; la unidad de dimensión base es el píxel. Por ejemplo, una imagen de 1080p tiene unas di­me­n­sio­nes de 1920 píxeles de ancho por 1080 de alto.

El pixel es una unidad absoluta por lo que, por de­fi­ni­ción, no se adapta al ancho de pantalla di­s­po­ni­ble. Veamos un ejemplo de por qué esto puede ser pro­ble­má­ti­co. Su­po­n­ga­mos que una página web contiene una imagen con una anchura de 1920 píxeles. Si ajustamos el ancho de la imagen a este valor mediante CSS, la vi­sua­li­za­ción puede resultar incómoda en pantallas pequeñas ya que la imagen sobresale del espacio di­s­po­ni­ble.

Aquí definimos una imagen en HTML con la etiqueta '<img>':

Mediante CSS, le asignamos un ancho de 1920 píxeles:

En este caso, es mejor utilizar una unidad relativa en vez de píxeles. Desde los primeros días, cuando los layouts estaban basados en tablas, el idioma CSS reconoce el po­r­ce­n­ta­je como una unidad relativa. Si es­ta­ble­ce­mos mediante CSS un ancho de la imagen del ‘100%’, la imagen se ajustará al espacio di­s­po­ni­ble. Esto ocurre porque los po­r­ce­n­ta­jes siempre se refieren al elemento que los encierra.

Nos hemos acercado bastante a nuestro objetivo de ajustar el ancho de una imagen al espacio di­s­po­ni­ble. Sin embargo, hemos creado un nuevo problema: En una pantalla de más de 1920 píxeles, la imagen se muestra ampliada y pixelada. Por lo tanto, hay que limitar el ancho máximo de la imagen a sus di­me­n­sio­nes reales en píxeles:

Además de los píxeles y los po­r­ce­n­ta­jes, el idioma CSS reconoce otras unidades. Las unidades relativas em, rem y vw, vh ofrecen in­te­re­sa­n­tes po­si­bi­li­da­des de uso en el diseño re­s­po­n­si­vo. A co­n­ti­nua­ción, tienes un resumen de las unidades más uti­li­za­das en CSS para el diseño re­s­po­n­si­vo, junto con su uso:

Además de las Media Queries simples mostradas hasta ahora, también se pueden escribir CSS Media Queries más complejas. Para ello, CSS reconoce los ope­ra­do­res lógicos ‘and’, ‘or’ y ‘not’. Este es un ejemplo de una Query compleja:

Además de las Media Features ya es­ta­ble­ci­das que pueden co­n­su­l­tar­se a través de CSS Media Query, habrá nuevas funciones in­te­re­sa­n­tes en el futuro. La es­pe­ci­fi­ca­ción “CSS Media Queries Level 5” (CSS5) reconoce, entre otras, las si­guie­n­tes nuevas opciones de solicitud:

Otra in­no­va­ción que se espera con el la­n­za­mie­n­to de CSS5 son las llamadas Container Queries. Con ellas será posible, por primera vez, vincular las reglas de estilo de los elementos a las pro­pie­da­des del container que los envuelven. Las Container Queries se di­fe­re­n­cian de las CSS Media Queries, que solicitan las pro­pie­da­des generales del di­s­po­si­ti­vo en el que se muestran. El uso de las Container Queries permitirá tratar casos es­pe­cia­les para los que hasta ahora se utilizaba Ja­va­S­cri­pt o Media Queries complejas.

En el contexto del diseño web re­s­po­n­si­vo y las CSS Media Queries, a menudo hablamos de “brea­k­poi­nts” (en español “punto de ruptura”). Un brea­k­poi­nt es un ancho de pantalla definido en el que se activa un conjunto de reglas CSS definidas pre­via­me­n­te por una CSS Media Query. Puedes ver los brea­k­poi­nts definidos en una página web si abres las he­rra­mie­n­tas de de­sa­rro­lla­dor en el navegador. Si la vi­sua­li­za­ción re­s­po­n­si­va está activa, los brea­k­poi­nts se muestran como barras de color sobre la página web original.

Una de las mejores prácticas re­co­no­ci­das del diseño re­s­po­n­si­vo es el enfoque mobile first. Si el diseño y de­sa­rro­llo de una página web sigue este enfoque, primero se definen las es­pe­ci­fi­ca­cio­nes de estilo para las pantallas más pequeñas. Estas de­fi­ni­cio­nes co­n­s­ti­tu­yen el marco básico del diseño. A partir de ahí, se definen varios brea­k­poi­nts para pantallas su­ce­si­va­me­n­te más grandes. Con esos brea­k­poi­nts se definen se­le­c­ti­va­me­n­te nuevas reglas de estilo para los elementos para pantallas más grandes, que van so­bre­s­cri­bie­n­do las reglas vigentes para las pantallas más pequeñas.

El enfoque mobile first queda bien ilustrado por el conocido CSS Utility Framework “Tachyons”. Este define 3 brea­k­poi­nts por defecto: ‘not-small’, ‘medium’ y ‘large’:

Ten en cuenta que, siguiendo el enfoque mobile first, no tienes un ‘small’ brea­k­poi­nt propio. Las es­pe­ci­fi­ca­cio­nes para los di­s­po­si­ti­vos pequeños si­m­ple­me­n­te se definen sin un brea­k­poi­nt.

Dentro de los brea­k­poi­nts, se definen reglas de estilo para los elementos cuya vi­sua­li­za­ción debe adaptarse a pantallas de distinto tamaño. Puede que ya te hayas dado cuenta de que esta ce­n­tra­li­za­ción del CSS Codebase de un proyecto web es co­m­pli­ca­da. No­r­ma­l­me­n­te es pre­fe­ri­ble almacenar todas las pro­pie­da­des CSS de un elemento en su propio archivo por separado.

Para poder modular el código CSS de un proyecto, se uti­li­za­ron primero varios pre­pro­ce­sa­do­res de CSS. Tal vez estés fa­mi­lia­ri­za­do con los lenguajes Sass, Less o Stylus. Más tarde, se incorporó un po­s­t­pro­ce­sa­dor de CSS llamado PostCSS a través del proyecto Node.js. Todas las te­c­no­lo­gías me­n­cio­na­das permiten en­ca­p­su­lar las CSS Media Queries dentro de un selector CSS. De este modo, las reglas de estilo de un elemento pueden definirse de forma conjunta para las di­fe­re­n­tes co­n­di­cio­nes de los medios. A co­n­ti­nua­ción, un ejemplo con Stylus.

Archivo Stylus ‘text.styl’ para las pro­pie­da­des del texto:

Archivo Stylus ‘link.styl’ para las pro­pie­da­des de los enlaces:

El pre­pro­ce­sa­dor Stylus traduce los archivos al idioma CSS y junta las reglas de CSS Media Query bajo un único brea­k­poi­nt. El código Stylus me­n­cio­na­do se traduce al código CSS de la siguiente manera:

El enfoque de en­ca­p­su­lar las CSS Media Queries dentro de las reglas de estilo de un elemento y pro­ce­sar­las a través del pro­ce­sa­dor CSS funciona. Sin embargo, esto sigue obligando al de­sa­rro­lla­dor a alternar entre el plano HTML y el CSS. También es necesario dividir los elementos en di­fe­re­n­tes ca­te­go­rías dentro de HTML, cada categoría con nombre único. La logística que resulta de ello genera una co­m­ple­ji­dad no deseada. Aquí es donde entran a jugar los CSS Utility Fra­me­wo­r­ks, una te­c­no­lo­gía im­pre­s­ci­n­di­ble en la ac­tua­li­dad.

Un CSS Utility Framework in­te­r­co­ne­c­ta las pro­pie­da­des CSS base mediante brea­k­poi­nts. Las ca­te­go­rías CSS re­su­l­ta­n­tes pueden asignarse a cualquier elemento en HTML. Esto permite definir re­s­po­n­si­ve layouts y co­m­po­ne­n­tes úni­ca­me­n­te en HTML sin necesidad de redactar código en CSS. El uso de un CSS Utility Framework permite crear pro­to­ti­pos de manera rápida y es ideal para el de­sa­rro­llo de co­m­po­ne­n­tes. Por ello, los CSS Utility Fra­me­wo­r­ks suelen uti­li­zar­se junto con te­c­no­lo­gías orie­n­ta­das a co­m­po­ne­n­tes como son React y Vue.

Veamos otro ejemplo del CSS Utility Framework Tachyons. Echa un vistazo al siguiente código CSS. Primero definimos las ca­te­go­rías que van de ‘mw1’ a ‘mw3’, las cuales limitan el ancho máximo de cualquier elemento a valores entre ‘1rem’ y ‘3rem’. Además, definimos las co­rre­s­po­n­die­n­tes ca­te­go­rías CSS dentro de los brea­k­poi­nts “medio” y “grande” ya exi­s­te­n­tes, las ca­te­go­rías llevarán en su nombre la abre­via­tu­ra de su brea­k­poi­nt re­s­pe­c­ti­vo:

Con la ayuda de las ca­te­go­rías CSS, podemos redactar la totalidad de los elementos re­s­po­n­si­vos en HTML. El siguiente segmento de código HTML define una imagen que tiene un ancho máximo de ‘1rem’ en pantallas pequeñas. La imagen se ajusta au­to­má­ti­ca­me­n­te al ancho de pantalla di­s­po­ni­ble. En las pantallas medianas, el elemento ocupa un máximo de ‘2rem’, en las grandes un máximo de ‘3rem’.

Los CSS Utility Fra­me­wo­r­ks definen un gran número de ca­te­go­rías base, cada una de las cuales define una sola propiedad CSS. Además de las di­me­n­sio­nes de un elemento, también se es­pe­ci­fi­can las ca­ra­c­te­rí­s­ti­cas de la ti­po­gra­fía, el color y todas las demás pro­pie­da­des que se nos puedan ocurrir. Para cada propiedad base, cada CSS Utility Framework tiene varias ca­te­go­rías definidas, una para cada brea­k­poi­nt existente. Co­m­bi­na­n­do varias ca­te­go­rías, se pueden juntar casi cualquier tipo de elemento re­s­po­n­si­vo que se desee.

El Framework Tachyons al que nos hemos referido an­te­rio­r­me­n­te, tiene ya varios años y no se sigue de­sa­rro­lla­n­do ac­ti­va­me­n­te. Sin embargo, debido a lo re­la­ti­va­me­n­te sencillo que es, sigue me­re­cie­n­do la pena empezar con Tachyons para aprender sobre el diseño re­s­po­n­si­vo. La manera más fácil de entender este enfoque es fijándose en los co­m­po­ne­n­tes Tachyons. Estos son elementos de ejemplo que se definen por completo a través de las ca­te­go­rías de utilidad.

Como sucesor natural de Tachyons, hoy existe una variante moderna llamada Tai­l­wi­n­d­C­SS. Tai­l­wi­n­d­C­SS tiene algunas ventajas sobre Tachyons. Por ejemplo, el proyecto sigue en de­sa­rro­llo activo y es co­m­pa­ti­ble con la mayoría de los sistemas de de­sa­rro­llo front-end más populares. Además, Tai­l­wi­n­d­C­SS puede adaptarse co­m­ple­ta­me­n­te a las ne­ce­si­da­des es­pe­cí­fi­cas de un proyecto. Todos los ajustes por defecto se pueden co­n­fi­gu­rar fá­ci­l­me­n­te, como los brea­k­poi­nts, la escala del tamaño de la fuente, etc.

A pesar de lo cómodo que resulta trabajar con los CSS Utility Fra­me­wo­r­ks, también tienen un gran in­co­n­ve­nie­n­te: para definir un elemento puede que necesite combinar un gran número de ca­te­go­rías base. Además, por defecto, el archivo CSS original contiene ca­te­go­rías para todas las co­m­bi­na­cio­nes de valores CSS y brea­k­poi­nts. En el caso de Tai­l­wi­n­d­C­SS, hay miles de ca­te­go­rías, lo que hace que el archivo CSS sin comprimir aumente su tamaño hasta alcanzar varios megabytes, un tamaño in­so­s­te­ni­ble desde el punto de vista del re­n­di­mie­n­to.

Afo­r­tu­na­da­me­n­te, Tai­l­wi­n­d­C­SS ofrece dos so­lu­cio­nes. En primer lugar, el framework reconoce la in­s­tru­c­ción ‘@apply’, que sirve para combinar varias ca­te­go­rías uti­li­za­das re­pe­ti­da­me­n­te bajo una nueva categoría. En segundo lugar, Tai­l­wi­n­d­C­SS es co­m­pa­ti­ble con la he­rra­mie­n­ta PurgeCSS. Esta he­rra­mie­n­ta se utiliza como parte del proceso de co­n­s­tru­c­ción para eliminar todas las ca­te­go­rías no empleadas en la co­n­s­tru­c­ción de productos. PurgeCSS procesa las pla­n­ti­llas HTML del proyecto e incluye solo las ca­te­go­rías CSS del código CSS original que haya en­co­n­tra­do. Esto reduce el tamaño del archivo de código original a un nivel admisible.