Pautas de revisión de código para CSS, JS y HTML

Me han pedido que cree pautas para revisar CSS, JS y HTML. Sé que hay pautas de codificación para JS, pero no sé nada sobre HTML y CSS. Para revisar JS, ciertamente seguiré esas pautas y las mencionaré. ¿Pero qué pasa con CSS y HTML? Además de los errores lógicos y los problemas de sangría, ¿hay algo específico que deba verificar cuando reviso el marcado y / o CSS?

Algunas cosas para buscar:

• ¿Se identifica la información estructurada usando las etiquetas HTML apropiadas? H1- H6para encabezados, UL/ OLy LIpara listas, etc.
• Hay etiquetas legado HTML ( <b>, <i>, <center>, <font>) utilizan?
• ¿Utiliza el sitio la menor cantidad de marcado posible?
• ¿Se externaliza la información de estilo a los archivos CSS?
• ¿Se ha externalizado todo Javascript? incluidos los controladores de eventos?
• ¿Los nombres de clase CSS se refieren a la función en la página ( img-caption) y no a form ( bold-red) o content ( pink-elephant)?
• ¿Las imágenes están en el formato apropiado (PNG o JPEG, según el tipo)?
• ¿Se han utilizado versiones minimizadas de bibliotecas Javascript?
• Opcionalmente, ¿se han minimizado todos los archivos JavaScript y CSS desarrollados localmente?
• ¿Valida el HTML / CSS?
• ¿Se ha utilizado YSlow (o similar) para verificar / optimizar el rendimiento?
• (principalmente) [SEO] ¿Está el sitio accesible con Javascript desactivado?
• [SEO] ¿El contenido más relevante se encuentra en la parte superior del HTML?

Uno de los elementos importantes de un buen estilo en HTML es la mejora progresiva . Esto significa que el diseño HTML será bueno incluso sin CSS o JavaScript. Luego, una vez que se procesan JS / CSS, se verá mejor (por ejemplo, el <select>menú desplegable HTML antiguo se animará).

Esto también tiene que ver con el marcado no intrusivo. En lugar de <font style="color:red;font-size:16pt">Hello</font>uno lo usaría <div class="red-colored-big-fond">Hello</div>.

Lo mismo con JavaScript. En lugar de <button onclick="javascript:alert('a');">Clickme</button>uno, especificaría una clase / ID de botón y lo orientaría desde JavaScript. También hace que su código de marcado sea más fácil de mantener.

Valide que se use la menor cantidad de marcado para realizar la tarea. Asegúrese de que el marcado también sea semántico, no lo use cuando una etiqueta hace exactamente lo mismo y proporciona más información. Valide que los tramos no se están haciendo elementos de bloque y viceversa.

Además, alex saca a relucir un gran punto de forma indirecta. Asegúrese de que nadie use nombres de clase como "fuente grande de color rojo", porque aproximadamente 20 segundos después de que se implemente de verdad, alguien lo cambiará a una fuente azul pequeña. De hecho, he visto este CSS:

.arial12pt { font-family: Verdana; font-size: 8pt; }

Todo en su marcado debe describir qué es la página, no cómo se ve. Definitivamente estoy de acuerdo con la mejora progresiva, pero nuevamente de una manera indirecta. La página no tiene requisitos para buscar un lugar cercano al mismo con CSS o sin él. No intentes hacer que se vean iguales, porque terminarás de nuevo en table-land y spacer.gif.

En lo que respecta al HTML, siempre propongo tener jerarquías y sangría en mis archivos. Por ejemplo, si tengo un montón de divs:

<div id="content">
   <div id="post">
     <div class="title">
       Blah Blah Title
     </div>
   </div>
</div>

Supongo que es bastante obvio para la mayoría de los que crean diseños y plantillas, pero la mayoría de las veces solo veo HTML ilegible que no tiene ninguna jerarquía estructural, lo que dificulta la lectura para otra persona. Supongo que viniendo de un fondo más CS, esto es algo que se me queda grabado. Lo mismo ocurre con CSS también. Digamos que estás diseñando un div:

#whatever{
    background-image: url('blah.gif');
    color: #FFF000;
}

La sangría hace que sea mucho más fácil de leer rápidamente cuando estás acostumbrado a otro idioma mezclado como PHP / Ruby / Whatever. De nuevo, depende de cómo trabajes mejor, pero cuando otros leen mi HTML, me gusta hacerlo realmente organizado :).

Además, como se dijo anteriormente, siempre es una buena idea nombrar sus clases de CSS e identifica nombres relevantes para su diseño, especialmente cuando se vuelve complicado (al igual que nombrar variables y métodos en otros idiomas). Algo más a tener en cuenta es el temido "adivinar y verificar" de los márgenes, rellenos y otros problemas de alineación. Algo que a menudo trato de evitar es poner números negativos en mis márgenes y rellenos. Puede ser confuso si no realizó el diseño usted mismo y si desea volver a él más tarde y modificarlo, es posible que deba revisarlo. En mi opinión, siempre es una buena idea no intentar nada hokey o "kludgy" en CSS, incluso si se ve bien; Por lo general, hay una mejor manera de hacerlo, ¡incluso si tiene que reestructurar su CSS!

Para Javascript siempre quisiera que se validara con JSLint, puedo pensar en tantos errores que JSLint detecta que no usarlo es una locura.

Encontré este documento de estándares que me gustó bastante. También haré eco de lo que se dijo sobre la mejora progresiva. En general, si alguien más escribe el HTML / CSS, debería poder verlo más adelante y sorprenderse de lo mal que está el marcado y debería ser capaz de realizar ajustes de estilo simples de manera fácil y eficiente.