Krypton Solid

Uso de espacios en blanco para mejorar la legibilidad en HTML y CSS – Smashing Magazine

Uso de espacios en blanco para mejorar la legibilidad en HTML y CSS – Smashing Magazine

Desde el principio, ofreceré algunos consejos sencillos: en producción, su código debe ser lo más amigable posible con el rendimiento. Esto significa, Gzip, concatenando y minimizando tantos activos como sea posible, sirviendo así los archivos más pequeños posibles y el menor número de archivos. No creo que nadie diría que estas sugerencias no son las mejores prácticas (incluso si no las implementamos en todos los proyectos). Ahora que lo hemos eliminado del camino, ¿cómo podemos usar espacios en blanco en el código de desarrollo para asegurarnos de que nuestros archivos sean lo más legibles y fáciles de mantener?

Desde el principio, ofreceré algunos consejos sencillos: en producción, su código debe ser lo más amigable posible con el rendimiento. Esto significa, hacer Gzip, concatenar y minificar tantos activos como sea posible, sirviendo así los archivos más pequeños posibles y la menor cantidad de archivos. No creo que nadie diría que estas sugerencias no son las mejores prácticas (incluso si no las implementamos en todos los proyectos).


El código legible y bien escrito no crea juegos mentales ni laberintos cuando otros desarrolladores lo leen. (Imagen: Toca Boca)

Ahora que lo hemos solucionado, ¿cómo podemos usar espacios en blanco en el código de desarrollo para asegurarnos de que nuestros archivos sean lo más legibles y fáciles de mantener posible? Bueno, podríamos considerar varias opciones, comenzando con algunos conceptos básicos.

Otras lecturas en SmashingMag:

Sangría HTML básica

Creo que la mayoría, si no todos, agregamos sangría básica en nuestro HTML:

<header>

   <hgroup>
      <h1>Section title</h1>
      <h2>Tagline</h2>
   </hgroup>

   <nav>
      <ul>
      <li><a href="https://www.smashingmagazine.com/">Home</a></li>
      <li><a href="https://www.smashingmagazine.com/about/">About</a></li>
      <li><a href="http://www.smashingmagazine.com/services/">Services</a></li>
      <li><a href="https://www.smashingmagazine.com/contact/">Contact</a></li>
      </ul>
   </nav>

</header>

<div class="main">
   <p>Content goes here.</p>
</div>

El principio aquí es que siempre que algo está anidado, sangras, para que quede claro dónde está todo en la jerarquía del marcado. Con anidamiento HTML simple, el contenido de la <head> La sección a menudo se descuida, pero mantener la anidación coherente aquí también es una buena práctica.

Por ejemplo, el siguiente código de muestra es bastante legible, incluso sin anidamiento:

<!DOCTYPE html>
<html>
<head>
<title>Foo</title>
</head>
<body>
<!-- content… -->
</body>
</html>

Sin embargo, con mucho más contenido en el <head> sección, el anidamiento podría facilitar la escanear el contenido:

<!doctype html>
<html class="no-js" lang="en">
   <head>
      <meta charset="utf-8">
      <meta content="IE=edge,chrome=1" http-equiv="X-UA-Compatible">
      <title>HTML5 Please - Use the new and shiny responsibly</title>
      <meta name="description" content="Look up HTML5, CSS3, etc features, know if they are ready for use, and if so find out how you should use them - with polyfills, fallbacks or as they are.">
      <meta content="width=device-width, initial-scale=1.0" name="viewport">

      <link rel="shortcut icon" href="https://www.smashingmagazine.com/2013/02/using-white-space-for-readability-in-html-and-css/favicon.ico" />
      <link rel="apple-touch-icon-precomposed"  href="apple-touch-icon-114x114-precomposed.png">
      <link rel="apple-touch-icon-precomposed"  href="apple-touch-icon-72x72-precomposed.png">
      <link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png">

      <link href="http://fonts.googleapis.com/css?family=Francois+One|Open+Sans:400italic,400,800" rel="stylesheet">
      <link href="css/style.css" rel="stylesheet">
      <script src="js/libs/modernizr-2.0.min.js"></script>
      <script>if (location.host == 'h5bp.github.com') location.href="https://html5please.us/"</script>

   </head>
   <body id="gfs">
      <!-- content… -->
   </body>
</html>

Este último fragmento de código se toma del HTML5 por favor sitio web. Como puede ver, cuando el contenido de la <head> la sección comienza a agrandarse, sangrar hace que las cosas sean un poco más fáciles de digerir de un vistazo. Note que el <head> y <body> Los elementos estn sangrados, porque ambos son hijos inmediatos del <html> elemento.

Por supuesto, algunos desarrolladores pueden tener un método ligeramente diferente de sangría en ciertas áreas, pero la idea es básicamente la misma; la intención es facilitar la lectura del código en un entorno de desarrollo.

Sangría CSS básica

Además de sangrar HTML, muchos desarrolladores (incluido yo) harán una sangría coincidente en cualquier CSS correspondiente. El siguiente código coincidiría con el HTML que se muestra en el primer ejemplo anterior:

header {
   color: blue;
}

   hgroup {
      color: green;
   }

      hgroup h1 {
         line-height: 1.5;
      }

      hgroup h2 {
         font-size: 15px;
      }

   nav {
      background: purple;
   }

      nav ul {
         float: left;
      }

         nav ul li {
            font-size: 20px;
         }

            nav ul li a, nav ul li a:visited {
               text-decoration: none;
            }

.main {
   border: solid 1px #ccc;
}

Para algo, esto parece un poco obsesivo. Pero lo prefiero porque me ayuda a escanear el CSS y encontrar jerarquías coincidentes sin tener que leer cada selector. Por supuesto, este tipo de jerarquía en su CSS debe usarse con moderación si está implementando principios de CSS modular que fomentan los módulos basados ​​en clases y el uso limitado del selector descendiente (por ejemplo, ul li).

Ciertamente, parte del código anterior es algo horrible; No recomendaría vincular sus estilos de encabezado y lista a un contexto específico como ese. Pero con el fin de comprender este concepto de sangría CSS, considérelo como un ejemplo teórico.

El punto es que tiene la opción de aplicar una sangría a CSS para que coincida con la estructura del HTML, lo que hace que sea más fácil de escanear y más fácil de entender en relación con el marcado.

Por supuesto, como es el caso de algunas cosas mencionadas en esta publicación, algo de esto no se aplica cuando está utilizando un preprocesador de CSS. Por ejemplo, la opción de selectores anidados para Sass haría que este último consejo fuera bastante diferente en un entorno de este tipo.

CSS3 legible

Llevemos nuestro abuso del espacio en blanco aún más lejos. Muchas características nuevas de CSS3 permiten conjuntos de valores separados por comas o espacios. Dos simples ejemplos son múltiples orígenes y transforma. Veamos cómo podemos hacer que sean más fáciles de leer:

.example {
   background: url(images/example.png) center center no-repeat,
               url(images/example-2.png) top left repeat,
               url(images/example-3.png) top right no-repeat;
}

.example-2 {
   transform: scale(.8)
              skew(20deg, 30deg)
              translateZ(0);
}

¿Se da cuenta de lo que hemos hecho aquí? En lugar de mantener el valor completo en una sola línea (lo que puede ser largo en algunos casos, especialmente cuando se trata de gradientes y prefijos de proveedores), hemos colocado cada conjunto de valores en una nueva línea, alineada con la que está arriba.

Por lo tanto, cada uno de los tres fondos está en su propia línea, y cada función de transformación está en su propia línea, alineada a la izquierda con el primero de cada ejemplo.

En general, esto podría ir en contra de la idea de tener una sola propiedad por línea (asumiendo, por supuesto, que no está haciendo conjuntos de reglas de una sola línea). Pero en comparación con la alternativa de las colas potencialmente muy largas, esta es una buena opción y hace que estos conjuntos de reglas sean muy fáciles de leer.

Tratar con prefijos de proveedores

Como se mencionó, si eres preprocesando tu CSS o usando -sin prefijo, entonces este consejo no se aplica. Pero puede manipular el espacio en blanco para que los prefijos de su proveedor sean más fáciles de leer de un vistazo:

.example {
   -webkit-transform: scale(.8);
      -moz-transform: scale(.8);
        -o-transform: scale(.8);
           transform: scale(.8);
}

Aquí alineamos los dos puntos para que los valores se alineen, lo que facilita la exploración de todos los valores para garantizar que sean iguales. No puedo decirle cuántas veces ajusté solo el valor de WebKit en un conjunto de reglas como este y olvidé hacer el resto. Por supuesto, esto ilustra la importancia del preprocesamiento, pero si aún no lo está haciendo, entonces este uso del espacio en blanco es una buena opción a considerar.

Además, muchos editores de texto ofrecen una función llamada «edición de bloque» o edición de varias líneas. Esto esta disponible en texto sublime, Empuje, Coda y probablemente la mayoría de los demás. Usar esta función es mucho más fácil cuando los valores que está cambiando están alineados verticalmente.

Referencias de archivos legibles

La esencia de esta siguiente sugerencia proviene de un tuit del cofundador de Twitter Bootstrap, Jacob Thornton. La idea aquí es que si su documento contiene una lista de referencias de archivos, puede hacer que sean más fáciles de leer haciendo algo como lo siguiente:


<link rel="apple-touch-icon-precomposed"  href="https://www.smashingmagazine.com/2013/02/using-white-space-for-readability-in-html-and-css/assets/ico/apple-touch-icon-144-precomposed.png">
<link rel="apple-touch-icon-precomposed"  href="assets/ico/apple-touch-icon-114-precomposed.png">
  <link rel="apple-touch-icon-precomposed"  href="assets/ico/apple-touch-icon-72-precomposed.png">
                <link rel="apple-touch-icon-precomposed" href="assets/ico/apple-touch-icon-57-precomposed.png">
                               <link rel="shortcut icon" href="assets/ico/favicon.png">

Se toma el ejemplo de arriba directamente desde Bootstrap. Aquí todo href atributos de la <link> los elementos están alineados. Esto facilita la referencia o el ajuste de un <link> porque la actualización normalmente será el valor de la href atributo.

Por supuesto, esto viola un poco las reglas de sangría HTML. Entonces, alternativamente, puede optar por esto:

<link rel="apple-touch-icon-precomposed"  href="https://www.smashingmagazine.com/2013/02/using-white-space-for-readability-in-html-and-css/assets/ico/apple-touch-icon-144-precomposed.png">
<link rel="apple-touch-icon-precomposed"  href="assets/ico/apple-touch-icon-114-precomposed.png">
<link rel="apple-touch-icon-precomposed"    href="assets/ico/apple-touch-icon-72-precomposed.png">
<link rel="apple-touch-icon-precomposed"                 href="assets/ico/apple-touch-icon-57-precomposed.png">
<link rel="shortcut icon"                                href="assets/ico/favicon.png">

Este último ejemplo parece más limpio y tiene la ventaja de alinear los otros atributos, aunque eso no es tan necesario en mi opinión.

Pero espera. ¿Qué pasa si no te importa que el href El atributo aparece en último lugar (que parece ser el personalizado y no es necesario para la validación). Entonces podrías hacer esto en su lugar:

<link href="https://www.smashingmagazine.com/2013/02/using-white-space-for-readability-in-html-and-css/assets/ico/apple-touch-icon-144-precomposed.png" rel="apple-touch-icon-precomposed" >
<link href="assets/ico/apple-touch-icon-114-precomposed.png" rel="apple-touch-icon-precomposed" >
<link href="assets/ico/apple-touch-icon-72-precomposed.png" rel="apple-touch-icon-precomposed" >
<link href="assets/ico/apple-touch-icon-57-precomposed.png" rel="apple-touch-icon-precomposed">
<link href="assets/ico/favicon.png" rel="shortcut icon">

No se necesitan trucos de espacios en blanco aquí, porque el href los atributos se alinean bien. Pero si le molesta la falta de alineación de los otros atributos, o si simplemente no puede soportar la idea de href primero se enumera el atributo, luego tendrá que optar por una de las soluciones anteriores.

Clases condicionales legibles

El concepto detrás de la alineación de atributos no es nada nuevo. HTML5 Boilerplate ha estado haciendo este tipo de cosas durante algún tiempo con sus clases condicionales de IE. Así es como se ve ese fragmento de código en la última versión:

<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->

En este caso, el atributo de clase en la apertura <html> etiqueta en cada condicional (y, por cierto, la etiqueta en sí) se está alineando, porque esta es la parte del código que es más relevante para la legibilidad y el mantenimiento, y la parte del código que sufriría más en legibilidad si esta alineación no fuera regalo.

Selectores legibles separados por comas

Siguiendo con Boilerplate, volvamos a CSS. Aquí hay algo que se usa en la hoja de estilo principal de ese proyecto:

html,
button,
input,
select,
textarea {
   color: #222;
}

Aquí, en lugar de mantener todos los selectores separados por comas en una sola línea, lo que sería más difícil de escanear, cada selector se coloca en una nueva línea. Esto puede ser útil cuando los selectores son algo largos, como en el siguiente ejemplo, también tomado de Boilerplate:

.visuallyhidden.focusable:active,
.visuallyhidden.focusable:focus {
   clip: auto;
   height: auto;
   margin: 0;
   overflow: visible;
   position: static;
   width: auto;
}

Similar a la idea detrás de la alineación de atributos HTML discutida anteriormente, esta alineación vertical hace que el código sea fácil de escanear en comparación con escanear una única línea aparentemente interminable de selectores separados por comas.

¿Puede su editor de texto ayudar con algo de esto?

Como desarrollador de mucho tiempo que se ha acostumbrado a codificar a mano, mi conocimiento de las características de los diferentes editores de texto es bastante limitado.

Algunos editores de texto o IDE pueden hacer algo de esto automáticamente. Además, los desarrolladores de complementos pueden usar algunos de estos patrones para crear complementos o extensiones que hacen este tipo de cosas automáticamente o con solo hacer clic en un botón.

Si tiene alguna sugerencia de herramientas integradas o extensiones para los editores de texto que puedan ayudar con esto, estoy seguro de que los lectores de Smashing Magazine estarán encantados de saberlo.

Conclusión

Se nos anima a todos a hacer todo lo posible para que el código en un entorno de desarrollo sea lo más fácil de leer y mantener. Espero que estas sugerencias mejoren su código de esta manera.

Y saber que este uso del espacio en blanco no inflará nuestros archivos es reconfortante; después de todo, esto no es para código de producción. Por lo tanto, haga lo que crea necesario para que su HTML y CSS sea más fácil de manejar, y asegúrese de minimizar esos activos al implementarlos en producción.

Finalmente, si tiene alguna sugerencia sobre el uso de espacios en blanco en HTML o CSS, estaremos encantados de escucharla.

Deja un comentario