Mantenga las matemáticas en el CSS | Programar Plus

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

.col {
  /* groan */
  width: 14.2857142857%;

  /* oh, I get it */
  width: calc(100% / 7);
}

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

Esa matemática puede ser un poco más complicada a medida que continúa. Por ejemplo, como en nuestros casos de uso para el artículo calc (), ¿qué pasa con las columnas en 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 limpio de leer y administrar.

La legibilidad de las matemáticas se puede mejorar con comentarios si se vuelve demasiado complicado. Supongamos que está tratando de contabilizar un medianil 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);
}

Una vez más, diría que es bastante legible, pero también es una buena cantidad de repetición. Esto podría requerir el uso de variables. Lo haremos con propiedades personalizadas de CSS por diversión. Tienes que elegir qué es digno de una variable y qué no. Es posible que necesite 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 dado una variable allí. ¿Muy lejos? Quizás. 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 todos con este material 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 tomó un camino muy matemático para llegar 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:

Vea el bloque de miniaturas de Pen Fluid 1 + 2 de James Nash (@cirrus) en CodePen.