Mantenga las matemáticas en el CSS

Existe la opinión de que dejar los cálculos matemáticos en el CSS es una buena idea, con la que estoy de acuerdo. Esto es para matemáticas que podías calcular en el momento de la redacción, pero que específicamente elegiste no hacerlo. Por ejemplo, si necesita una cuadrícula flotante de 7 columnas (sin censura), es más limpia e intuitiva:

.col {  /* groan */  width: 14.2857142857%;  /* oh, I get it */  width: calc(100% / 7);}

Probablemente podría demostrar que calc()le toma a la computadora un 0,0000001% más de tiempo, por lo que definir explícitamente el ancho es técnicamente más rápido por razones de rendimiento, pero eso equivale a no usar puntuación en oraciones porque ahorra peso HTML.

Esas matemáticas pueden ser un poco más complicadas a medida que continúas. Por ejemplo, como en nuestro artículo sobre casos de uso de calc(), ¿qué pasa con las columnas de esa cuadrícula de 7 columnas que se extienden?

.column-1-7 {   width: calc(100% / 7);}.column-2-7 {   width: calc(100% / 7 * 2);}.column-3-7 {   width: calc(100% / 7 * 3);}

Yo diría que es bastante claro de leer y administrar.

La legibilidad de las matemáticas se puede mejorar mediante comentarios si se vuelve demasiado complicado. Supongamos que está intentando tener en cuenta un mediano basado en márgenes con relleno dentro de un elemento:

.parent {  width: 600px;  padding: 18px;}.left {  /* base width - 1/2 horizontal padding */  width: calc(400px - 18px);  margin-right: 1rem; /* gutter */}.right {  /* base width - 1/2 horizontal padding - gutter */  width: calc(200px - 1rem - 18px);}

Nuevamente, diría que es bastante legible, pero también tiene una buena cantidad de repetición. Esto podría requerir el uso de variables. Lo haremos con propiedades CSS personalizadas para diversión. Tienes que elegir qué es digno de una variable y qué no. Es posible que necesites menos comentarios ya que el código se vuelve algo autodocumentado:

.parent {  --padding: 18px;  --gutter: 1rem;    width: 600px;  padding: var(--padding);}.left {  width: calc(400px - var(--padding));  margin-right: var(--gutter);}.right {  width: calc(200px - var(--gutter) - var(--padding));}

Ese es un equilibrio decente para mí. Aquí hay un paso más:

.parent {  --padding: 18px;  --gutter: 1rem;  --parentWidth: 600px;  --leftSize: 2/3;  --rightSize: 1/3;    width: var(--parentWidth);  padding: var(--padding);}.left {  width: calc(calc(var(--parentWidth) * var(--leftSize)) - var(--padding));  margin-right: var(--gutter);}.right {  width: calc(calc(var(--parentWidth) * var(--rightSize)) - var(--gutter) - var(--padding));}

A cada número se le ha asignado una variable allí. ¿Muy lejos? Tálvez. Ciertamente hace que esas declaraciones de ancho sean bastante difíciles de entender rápidamente. Ana Tudor hace cosas serias con calc(), como prueba de que el nivel de comodidad de cada persona con estas cosas es diferente.

Una de las cosas que me hizo pensar en todo esto es un artículo reciente de James Nash – “Hardcore CSS calc()” – donde construye esto:

Si bien la solución requeriría un camino muy matemático para llegar hasta allí, termina siendo solo una especie de cálculo de nivel medio en el viejo medidor de complejidad. Y tenga en cuenta que no todo obtiene una variable, solo los bits más reutilizados: