Algunas veces las consultas sobre el tamaño del contenedor me habrían ayudado

Las consultas de contenedor CSS todavía están ganando terreno y muchos de nosotros nos estamos mojando las manos con ellas, incluso si es para pequeños experimentos o lo que sea. Tienen grandes, pero no del todo llenos, soporte de navegador — lo suficiente como para justificar su uso en algunos proyectos, pero tal vez no en la medida en que podamos tener la tentación de comenzar a reemplazar preguntas de los medios de proyectos anteriores con consultas de tamaño de contenedor nuevas y brillantes.

¡Seguro que son útiles! De hecho, ya me encontré con algunas situaciones en las que realmente quería llegar a ellos, pero simplemente no pude superar los requisitos de soporte. Si hubiera podido usarlos, así es como se vería en esas situaciones.

Todas las siguientes demostraciones se verán mejor en Chrome o Safari en el momento de escribir este artículo. Firefox planea apoyo a la nave en la versión 109.

Caso 1: Rejilla de cartas

Tenías que esperar este, ¿verdad? Es un patrón tan común que todos parecemos toparnos con él en algún momento. Pero el hecho es que las consultas de tamaño de contenedor me habrían ahorrado mucho tiempo con un mejor resultado si hubiera podido usarlas en lugar de las consultas de medios estándar.

Supongamos que se le ha encomendado la tarea de crear esta cuadrícula de tarjetas con el requisito de que cada tarjeta debe mantener su relación de aspecto de 1:1:

¡Es más duro de lo que parece! El problema es que dimensionar el contenido de un componente en el ancho de la ventana gráfica lo deja a merced de cómo responde el componente a la ventana gráfica, así como la forma en que responde cualquier otro contenedor antecesor. Si, por ejemplo, desea que el tamaño de fuente del encabezado de una tarjeta se reduzca cuando la tarjeta alcanza un cierto tamaño en línea, no hay una forma confiable de hacerlo.

Puede establecer el tamaño de fuente en vw unidades, supongo, pero el componente aún está vinculado al ancho de la ventana gráfica del navegador. Y eso puede causar problemas cuando la cuadrícula de la tarjeta se usa en otros contextos que pueden no tener los mismos puntos de interrupción.

En mi proyecto del mundo real, aterricé en un enfoque de JavaScript que:

1. Escuche un evento de cambio de tamaño.
2. Calcula el ancho de cada tarjeta.
3. Agregue un tamaño de fuente en línea a cada tarjeta según su ancho.
4. Dale estilo a todo el interior usando em unidades.

Parece mucho trabajo, ¿verdad? Pero es una solución estable para obtener la escala requerida en diferentes tamaños de pantalla en diferentes contextos.

Las consultas de contenedores habrían sido mucho mejores porque nos brindan unidades de consulta de contenedores, tales como el cqw unidad. Probablemente ya lo entiendas, pero 1cqw es igual a 1% del ancho de un contenedor. También tenemos el cqi unidad que es una medida del ancho en línea de un contenedor, y cqb para el ancho de bloque de un contenedor. Entonces, si tenemos un contenedor de tarjetas que es 500px ancho, un 50cqw el valor se calcula para 250px.

Si hubiera podido usar consultas de contenedor en mi cuadrícula de tarjeta, podría haber configurado el .card componente como un contenedor:

.card { 
  container: card / size;
}

Entonces podría haber puesto un envoltorio interno con padding que escala en 10% de las .cardel ancho usando el cqw unidad:

.card__inner { 
  padding: 10cqw; 
} 

Esa es una buena manera de escalar el espacio entre los bordes de la tarjeta y su contenido de manera consistente, sin importar dónde se use la tarjeta en cualquier ancho de ventana gráfica. ¡No se requieren consultas de medios!

¿Otra idea? Usar cqw unidades para el tamaño de fuente del contenido interno, luego aplique relleno en em unidades:

.card__inner { 
  font-size: 5cqw; 
  padding: 2em;
} 

5cqw es un valor arbitrario, solo uno que me decidí. Ese relleno sigue siendo igual a 10cqw ya que el em unidad es relativa a la .card__inner ¡tamaño de fuente!

¿Captaste eso? los 2em es relativo al 5cqw tamaño de fuente que se establece en el mismo contenedor. Los contenedores funcionan de forma diferente a lo que estamos acostumbrados, ya que em las unidades son relativas al mismo elemento font-size value. Pero lo que noté rápidamente es que las unidades de consulta de contenedor se relacionan con el padre más cercano que también es un contenedor.

Por ejemplo, 5cqw no se escala en función de la .card ancho del elemento en este ejemplo:

.card { 
  container: card / size; 
  container-name: card; 
  font-size: 5cqw; 
}

Más bien, se escala al padre más cercano que se define como contenedor. Por eso monté un .card__inner envoltura.

Caso 2: diseño alternativo

Necesitaba otro componente de tarjeta en un proyecto diferente. Esta vez, necesitaba la tarjeta para hacer la transición de un diseño horizontal a un diseño vertical... luego de vuelta al paisaje y de nuevo al retrato a medida que la pantalla se hace más pequeña.

Hice el trabajo sucio de hacer que este componente fuera vertical en esos dos rangos de ventana gráfica específicos (gritar al nueva sintaxis de rango de consulta de medios!), pero nuevamente, el problema es que luego está bloqueado para las consultas de medios establecidas en él, su padre y cualquier otra cosa que pueda responder al ancho de la ventana gráfica. ¡Queremos algo que funcione en cualquier condición sin preocuparnos por preguntarnos dónde se romperá el contenido!

Las consultas de contenedores habrían hecho esto muy fácil, gracias a la @container regla:

.info-card {
  container-type: inline-size;
  container-name: info-card;
}

@container info-card (max-width: 500px) {
  .info-card__inner {
    flex-direction: column;
  }
}

Una consulta, fluidez infinita:

¡Pero espera! Hay algo de lo que tal vez quieras estar atento. Específicamente, podría ser difícil usar una consulta de contenedor como esta dentro de un sistema de diseño basado en accesorios. Por ejemplo, este .info-card El componente podría contener componentes secundarios que se basan en accesorios para cambiar su apariencia.

¿Por qué es tan importante? El diseño de retrato de la tarjeta puede requerir un estilo alternativo, pero no puede cambiar los accesorios de JavaScript con CSS. Como tal, corre el riesgo de duplicar los estilos requeridos. De hecho, toqué esto y cómo solucionarlo en otro artículo. Si necesita usar consultas de contenedores para una parte significativa de su estilo, es posible que deba basar todo su sistema de diseño en torno a ellas en lugar de tratar de calzarlas en un sistema de diseño existente que tiene muchas consultas de medios.

Caso 3: Trazos SVG

Aquí hay otro patrón muy común que he usado recientemente donde las consultas sobre el tamaño del contenedor habrían dado como resultado un producto más pulido. Digamos que tiene un ícono bloqueado con un encabezado:

  
    
   
  Heading

Es bastante sencillo escalar el ícono con el tamaño del título, incluso sin consultas de medios. Sin embargo, el problema es que los SVG stroke-width puede volverse demasiado delgado para que se note tan bien en un tamaño más pequeño, y tal vez llamar demasiado la atención con un trazo súper grueso en un tamaño más grande.

Tuve que crear y aplicar clases a cada instancia de icono para determinar su tamaño y ancho de trazo. Eso está bien si el ícono está al lado de un encabezado que tiene un estilo con un tamaño de fuente fijo, supongo, pero no es tan bueno cuando se trabaja con un tipo fluido que cambia constantemente.

El tamaño de fuente del encabezado puede basarse en el ancho de la ventana gráfica, por lo que el ícono SVG debe ajustarse según corresponda donde su trazo funcione en cualquier tamaño. Puede hacer que el ancho del trazo sea relativo al encabezado font-size al establecerlo en em unidades. Pero si tiene un conjunto específico de tamaños de trazo al que debe ajustarse, esto no funcionaría porque, de lo contrario, se escala linealmente; no hay forma de ajustarlo a un tamaño específico. stroke-width valor en ciertos puntos sin recurrir a consultas de medios sobre el ancho de la ventana gráfica.

Pero esto es lo que habría hecho si hubiera tenido el lujo de consultas de contenedores en ese momento:

.icon {
  container: icon / size; 
  width: 1em; 
  height: 1em; 
}

.icon svg {
  width: 100%; 
  height: 100%; 
  fill: none; 
  stroke: #ccc; 
  stroke-width: 0.8; 
}

@container icon (max-width: 70px) {
  .icon svg {
    stroke-width: 1.5; 
  }
}
@container icon (max-width: 35px) {
  .icon svg {
    stroke-width: 3;
  }
}

Compare las implementaciones y vea cómo la versión de consulta del contenedor ajusta el trazo del SVG a los anchos específicos que quiero según el ancho del contenedor.

Bonificación: otros tipos de consultas de tamaño de contenedor

OK, así que en realidad no me he encontrado con esto en un proyecto real. Pero mientras revisaba información sobre consultas de contenedores, noté que hay cosas adicionales que podemos consultar en un contenedor que están relacionadas con el tamaño o las dimensiones físicas del contenedor.

La mayoría de los ejemplos que he visto consultan el width, max-widthy min-width, height, block-sizey inline-size como he estado haciendo a lo largo de este artículo.

@container info-card (max-width: 500px) {
  .info-card__inner {
    flex-direction: column;
  }
}

Pero MDN destaca dos cosas más podemos consultar contra. Uno es orientation lo cual tiene mucho sentido porque lo usamos todo el tiempo en consultas de medios. No es diferente con las consultas de contenedor:

@media screen (orientation: landscape) { 
  .info-card__inner {
    /* Style away! */
  }
} 

@container info-card (orientation: landscape) { 
  .info-card__inner {
    /* Style away! */
  }
} 

¿El otro? Es aspect-ratio, lo creas o no:

@container info-card (aspect-ratio: 3/2) { 
  .info-card__inner {
    /* Style away! */
  }
} 

Aquí hay una demostración editable para jugar con ambos ejemplos:

Realmente no he encontrado un buen caso de uso para ninguno de estos todavía. Si tienes alguna idea o sientes que podría haberte ayudado en tus proyectos, ¡házmelo saber en los comentarios!