Un par de consultas sobre el tamaño del contenedor me habrían ayudado | trucos CSS

Las solicitudes de contenedores CSS siguen ganando popularidad 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, compatibilidad con navegador — lo suficiente como para justificar su uso en algunos proyectos, pero tal vez no hasta el punto en que podamos tener la tentación de comenzar a reemplazar las consultas de medios de proyectos anteriores con nuevas y brillantes consultas de tamaño de contenedor.

¡Seguro que son cómodas! De hecho, ya me he encontrado con algunas situaciones en las que realmente quería llegar a ellos, pero simplemente no pude superar los requisitos de soporte. Si pudiera usarlos, así es como se verían en estas situaciones.

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

Caso 1: Rejilla de cartas

Tenías que esperar eso, ¿verdad? Este es un patrón tan común que parece que todos nos topamos 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 tiene la tarea de construir esta cuadrícula de tarjetas con el requisito de que cada tarjeta mantenga su proporción de 1:1:

¡Es más difícil de lo que parece! El problema es que dimensionar el contenido de un componente en relación con el ancho de la ventana gráfica lo deja a merced de cómo reacciona el componente a la ventana gráfica y cómo reacciona cualquier otro contenedor anterior. Si, por ejemplo, desea que el tamaño de la fuente del título del mapa disminuya cuando el mapa alcance un cierto tamaño incorporado, no existe una forma confiable de hacerlo.

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

En mi proyecto del mundo real, me decidí por 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 sólida para obtener la escala que necesita en diferentes tamaños de pantalla en diferentes contextos.

Las solicitudes de contenedores serían mucho mejores porque nos brindan solicitar unidades por contenedorTanto como cqw Probablemente ya lo entiendas, pero 1cqw es igual a 1% por ancho de contenedor También tenemos cqi una unidad que es una medida del ancho incorporado de un contenedor, y cqb para ancho de bloque por contenedor. Entonces, si tenemos un contenedor de tarjetas, eso es 500px ancho, un 50cqw el valor se calcula para 250px.

Si pudiera usar solicitudes de contenedores en mi cuadrícula de mapas, podría configurar .card componente como un contenedor:

.card { 
  container: card / size;
}

Entonces podría establecer una envoltura interna con padding que escala en 10% de .cardancho usando cqw unidad:

.card__inner { 
  padding: 10cqw; 
} 

Esta es una buena manera de escalar de manera consistente la distancia entre los bordes del mapa y su contenido, independientemente de dónde se use el mapa para un ancho de ventana determinado. ¡No se requieren solicitudes de medios!

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

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

5cqw es un valor arbitrario, solo el que yo decidí. Esta almohadilla sigue siendo igual a 10cqw como em unidad es relativa a .card__inner ¡tamaño de fuente!

¿Captaste esto? 2em es relativo a 5cqw tamaño de fuente que se establece en el mismo contenedorLos contenedores funcionan de manera diferente a lo que estamos acostumbrados, como em las unidades son relativas a los mismos elementos font-size valuePero lo que noté rápidamente es que las unidades de contenedor de consultas se refieren a el padre más cercano que también es un contenedor.

Por ejemplo, 5cqw no se escala en función de .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 un contenedor. Por eso me instalé .card__inner envoltura.

Caso 2: diseño alternativo

Necesitaba otro componente de mapa en un proyecto diferente. Esta vez necesitaba que el mapa pasara de un diseño horizontal a un diseño vertical... luego de vuelta al paisaje y de nuevo al retrato cuando la pantalla se hizo más pequeña.

He hecho el trabajo sucio de hacer que este componente cambie a la orientación vertical en estos dos rangos de ventana gráfica específicos (gracias a la nueva sintaxis de el rango de consultas 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 todas las condiciones, ¡sin la preocupación de preguntarse dónde se romperá el contenido!

Las solicitudes de contenedores lo facilitarían, 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. En particular, puede ser difícil usar una consulta de contenedor como esta dentro de un sistema de diseño basado en accesorios. por ejemplo esto .info-card Un componente puede contener componentes secundarios que se basan en accesorios para cambiar su apariencia.

¿Por qué es esto un gran problema? Un diseño de mapa vertical puede requerir un estilo alternativo, pero no puede cambiar los accesorios de JavaScript con CSS. De esta forma corre el riesgo de duplicar los estilos requeridos. De hecho, mencioné esto y cómo solucionarlo en otro artículo. Si necesita usar consultas de contenedores para una parte importante de su estilo, es posible que deba basar todo su sistema de diseño en torno a ellos en lugar de tratar de encajarlos en un existe un diseño que es pesado en las consultas de los 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 darían como resultado un producto más limpio. Digamos que tiene un icono bloqueado con un título:

<h2>
  <svg>
    <!-- SVG stuff -->
  </svg> 
  Heading
</h2>

Es bastante fácil escalar el ícono al tamaño del título, incluso sin consultas de medios. El problema, sin embargo, es que SVG stroke-width puede volverse demasiado delgado para ser notado también en un tamaño más pequeño, y quizás 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 el tamaño y el ancho del trazo. Eso está bien si el ícono está al lado de un título que tiene un estilo con un tamaño de fuente fijo, supongo, pero no es tan bueno cuando trabajas con un tipo fluido que cambia constantemente.

El tamaño de la fuente del título se puede basar en el ancho de la ventana gráfica, por lo que el icono SVG debe ajustarse en consecuencia cuando su trazo funciona en cualquier tamaño. Puede hacer que el ancho del trazo sea relativo al título font-size colocándolo em Pero si tiene un conjunto específico de tamaños de trazo al que debe ajustarse, entonces esto no funcionará porque, de lo contrario, se escala linealmente; no hay forma de configurarlo en un tamaño específico. stroke-width valor en puntos específicos sin recurrir a consultas de medios para el ancho de la ventana gráfica.

Pero esto es lo que habría hecho si hubiera tenido el lujo de recibir solicitudes 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 solicitud del contenedor ajusta el trazo SVG a los anchos específicos que quiero según el ancho del contenedor.

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

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

La mayoría de los ejemplos que he visto hacen una pregunta width, max-widthy min-width, height, block-sizey inline-size como hago 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 preguntar vs. Uno es orientation lo cual tiene mucho sentido porque lo usamos todo el tiempo en consultas de medios. No es diferente con las solicitudes de contenedores:

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

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

¿El otro? Está aspect-ratiopor extraño que parezca:

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

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

Todavía no he encontrado un buen caso de uso para ninguno de ellos. Si tienes alguna idea o sientes que podría ayudarte con tus proyectos, ¡házmelo saber en los comentarios!