Aplique éstas, o sus propias directrices, pero asegúrese de seguirlas en todo momento. Debe corregirse tanto la violación de las reglas menores como de las de mayor importancia. Para cualquier adición o contribución, por favor abra una issue en Github.
Cada línea de código debería parecer escrita por una única persona, independientemente del número de colaboradores.
</li> or </body>).<!DOCTYPE html>
<html>
<head>
<title>Page title</title>
</head>
<body>
<img src="images/company-logo.png" alt="Company">
<h1 class="hello-world">Hello, world!</h1>
</body>
</html>Forzar el modo estándar y por lo tanto un renderizado más consistente en todos los navegadores es posible con este simple doctype al principio de cada página HTML.
<!DOCTYPE html>
<html>
<head>
</head>
</html>Extraído de la especificación de HTML5:
Se recomienda a los autores que especifiquen un atributo de idioma (lang) en el elemento html raíz, con el fin de dar un idioma al documento. Esto ayuda a las herramientas de síntesis de voz a determinar qué pronunciación utilizar, a las herramientas de traducción a determinar qué relgas utilizar, etcétera.
Lea más acerca del atributo lang en la especificación .
Diríjase a Sitepoint para ver el listado de códigos de idioma.
<html lang="en-us">
<!-- ... -->
</html>Internet Explorer admite el uso de una etiqueta de compatibilidad <meta> para especificar en qué versión de IE se debe renderizar la página. Excepto en casos excepcionales, es más recomendable indicar a IE que utilice el último modo de renderizado compatible con el modo edge.
Para más información, lea este magnífico artículo de Stack Overflow.
<meta http-equiv="X-UA-Compatible" content="IE=Edge">Garantice de una forma rápida y sencilla el correcto renderizado de su contenido mediante la declaración explícita de la codificación de caracteres. Al hacerlo, puede evitar el uso de entidades HTML, siempre que su codificación de caracteres coincida con la del documento (generalmente UTF-8).
<head>
<meta charset="UTF-8">
</head>Según la especificación de HTML5, no es necesario especificar un type cuando incluimos archivos CSS y JavaScript como text/css y text/javascript ya que son sus respectivos valores por defecto.
<!-- CSS Externo-->
<link rel="stylesheet" href="code-guide.css">
<!-- CSS en el documento-->
<style>
/* ... */
</style>
<!-- JavaScript -->
<script src="code-guide.js"></script>Esfuércese por mantener los estándares y la semántica HTML, pero no a expensas de la practicidad. Utilice la menor cantidad de marcado con la menor complejidad, siempre que sea posible.
Los atributos HTML deberían venir en este orden específico con el fin de facilitar la lectura del código.
classid, namedata-*src, for, type, href, valuetitle, altrole, aria-*Las clases hechas para grandes componentes reutilizables, irían primero. Los ids son más específicos y deberían ser utilizados con moderación (por ejemplo, para enlaces internos de la página), por lo tanto irían en segundo lugar.
<a class="..." id="..." data-toggle="modal" href="#">
Link de ejemplo
</a>
<input class="form-control" type="text">
<img src="..." alt="...">Un atributo booleano es aquel que no necesita ningún valor declarado. XHTML requería la declaración de un valor, pero HTML5 no incluye este requerimiento.
Para más información, consulte en WhatWG la sección sobre atributos booleanos:
La presencia de un atributo booleano en un elemento representa el valor true, y la ausencia del atributo representa el valor false.
Si debe incluir el valor del atributo, pero no lo necesita, siga esta directriz de WhatWG:
Si el atributo está presente, su valor debe ser una cadena vacía o [...] el nombre canónico del atributo, sin espacio en blanco al principio, ni al final.
En resumen, no añada ningún valor.
<input type="text" disabled>
<input type="checkbox" value="1" checked>
<select>
<option value="1" selected>1</option>
</select>En la medida de lo posible, evite elementos padre superfluos al escribir HTML. A menudo, esto requiere múltiples pasos y refactorización, pero produce menos HTML. Tomemos el siguiente ejemplo:
<!-- Mejorable -->
<span class="avatar">
<img src="...">
</span>
<!-- Mejor -->
<img class="avatar" src="...">La escritura del marcado en un archivo JavaScript hace el que el contenido sea más difícil de encontrar, más difícil de editar y menos eficiente. Evítelo siempre que sea posible.
: en cada declaración.box-shadow).rgb(), rgba(), hsl(), hsla(), o rect(). Esto ayuda a diferenciar múltiples valores de color (coma, sin espacio) de múltiples valores de propiedad (coma, con espacio)..5 en vez de 0.5 y -.5px en vez de -0.5px).#fff. Las letras minúsculas son mucho más fáciles de percibir cuando escaneamos visualmente un documento, ya que tienen formas únicas.#fff instead of #ffffff.margin: 0; en lugar de margin: 0px;.¿Preguntas sobre los términos utilizados aquí? Consulte la sección sobre sintaxis del artículo sobre Hojas de Estilo en Cascada en Wikipedia.
/* Mal CSS */
.selector, .selector-secondary, .selector[type=text] {
padding:15px;
margin:0px 0px 15px;
background-color:rgba(0, 0, 0, 0.5);
box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
}
/* Buen CSS */
.selector,
.selector-secondary,
.selector[type="text"] {
padding: 15px;
margin-bottom: 15px;
background-color: rgba(0,0,0,.5);
box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
}Las declaraciones de propiedades relacionadas deberían agruparse siguiendo el siguiente orden:
El posicionamiento iría primero porque puede eliminar un elemento del flujo normal del documento y sobrescribir los estilos relacionados al modelo de caja. El modelo de caja iría después, ya que dicta las dimensiones y la ubicación de un componente.
Todo lo demás, que sucede dentro del componente o sin afectar a las dos secciones anteriores, iría después.
Para ver la lista completa de propiedades y su orden, por favor consulte Recess.
.declaration-order {
/* Posicionamiento */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 100;
/* Modelo de caja */
display: block;
float: right;
width: 100px;
height: 100px;
/* Tipografía */
font: normal 13px "Helvetica Neue", sans-serif;
line-height: 1.5;
color: #333;
text-align: center;
/* Visual */
background-color: #f5f5f5;
border: 1px solid #e5e5e5;
border-radius: 3px;
/* Miscelánea */
opacity: 1;
}@importEn comparación con <link>s, @import es más lento, añade nuevas peticiones a la página, y puede causar otros problemas imprevistos. Evítelos y opte en su lugar por un enfoque alternativo:
<link>Para más información, lea este artículo de Steve Souders.
<!-- Utilice elementos 'link' -->
<link rel="stylesheet" href="core.css">
<!-- Evite '@imports' -->
<style>
@import url("more.css");
</style>Sitúe las media queries lo más cerca posible de sus respectivos conjuntos de reglas. No las agrupe todas en una hoja de estilos separada o al final del documento. Hacerlo así, sólo hace más fácil perderlas en un futuro. Aquí una configuración típica:
.element { ... }
.element-avatar { ... }
.element-selected { ... }
@media (min-width: 480px) {
.element { ...}
.element-avatar { ... }
.element-selected { ... }
}Cuando utilice propiedades con prefijo, indente cada propiedad de forma que los valores de la declaración queden alineados verticalmente para facilitar la edición multilínea.
En Textmate, utilice Text → Edit Each Line in Selection (⌃⌘A). En Sublime Text 2, utilice Selection → Add Previous Line (⌃⇧↑) y Selection → Add Next Line (⌃⇧↓).
/* Propiedades con prefijo */
.selector {
-webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
box-shadow: 0 1px 2px rgba(0,0,0,.15);
}En aquellos casos en los que una reglas contenga solo una declaración, considere la posibilidad de eliminar los saltos de línea para facilitar la lectura y edición. Los conjuntos de reglas con múltiples declaraciones deberían dividirse en varias líneas separadas.
Lo importante aquí es la detección de errores—p.ej., un validador de CSS que le dice que tiene un error de sintaxis en la línea 183. Con una sola declaración, no puede haber confusión. Con múltiples declaraciones, mantenerlas en líneas separadas es necesario para su cordura.
/* Declaraciones únicas en una línea */
.span1 { width: 60px; }
.span2 { width: 140px; }
.span3 { width: 220px; }
/* Declaraciones múltiples, una por línea */
.sprite {
display: inline-block;
width: 16px;
height: 15px;
background-image: url(../img/sprite.png);
}
.icon { background-position: 0 0; }
.icon-home { background-position: 0 -20px; }
.icon-account { background-position: 0 -40px; }Procure limitar el uso de declaraciones abreviadas a aquellos casos en los que necesite setear explícitamente todos los valores disponibles. Las propiedades donde más se suele abusar de la notación abreviada son:
paddingmarginfontbackgroundborderborder-radiusLa mayor parte de las veces no necesitamos especificar todos los valores que representa una propiedad abreviada. Por ejemplo, los encabezados HTML solo definen los márgenes superior e inferior, de manera que cuando es necesario, solo se sobrescriben esos dos valores. El uso excesivo de notación abreviada conduce con frecuencia hacia un código más descuidado con sobrescrituras innecesarias y efectos secundarios no deseados.
La Mozilla Developer Network tiene un gran artículo acerca de las propiedades abreviadas para aquellos que no esté familiarizados con su sintaxis y comportamiento.
/* Mal ejemplo */
.element {
margin: 0 0 10px;
background: red;
background: url("image.jpg");
border-radius: 3px 3px 0 0;
}
/* Buen ejemplo */
.element {
margin-bottom: 10px;
background-color: red;
background-image: url("image.jpg");
border-top-left-radius: 3px;
border-top-right-radius: 3px;
}Evite la anidación innecesaria. El hecho de que puedas anidar, no significa que debas hacerlo. Considere la posibilidad de anidar solo si debe restringir los estilos al contexto del padre y hay múltiples elementos a ser anidados.
Lectura adicional:
// Sin anidación
.table > thead > tr > th { … }
.table > thead > tr > td { … }
// Con anidación
.table > thead > tr {
> th { … }
> td { … }
}Para mejorar la legibilidad, envuelva todas las operaciones matemáticas entre paréntesis con un solo espacio entre valores, variables y operadores.
// Mal ejemplo
.element {
margin: 10px 0 @variable*2 10px;
}
// Buen ejemplo
.element {
margin: 10px 0 (@variable * 2) 10px;
}El código es escrito y mantenido por personas. Asegúrese de que su código sea descriptivo, esté bien comentado y sea comprensible para los demás. Los buenos comentarios de código proporcionan contexto o propósito. No se limite a repetir simplemente un nombre de clase o componente.
Asegúrese de utilizar frases completas para comentarios largos y frases concisas para notas generales.
/* Mal ejemplo */
/* Modal header */
.modal-header {
...
}
/* Buen ejemplo */
/* Elemento que envuelve a .modal-title y a .modal-close */
.modal-header {
...
}.btn and .btn-danger)..btn es útil para button, pero .s no significa nada..js-* en aquellas clases que denoten comportamiento (en lugar de estilo), pero mantenga estas clases fuera de su CSS.Es útil también aplicar muchas de estas reglas para la creación de nombres de variables en Sass y Less.
/* Mal ejemplo */
.t { ... }
.red { ... }
.header { ... }
/* Buen ejemplo */
.tweet { ... }
.important { ... }
.tweet-header { ... }[class^="..."]) en elementos que aparecen a menudo en la página. El rendimiento del navegador se ve afectado por estos selectores.Lectura adicional:
/* Mal ejemplo */
span { ... }
.page-container #stream .stream-item .tweet .tweet-header .username { ... }
.avatar { ... }
/* Buen ejemplo */
.avatar { ... }
.tweet-header .username { ... }
.tweet .avatar { ... }/*
* Encabezado de la sección del componente
*/
.element { ... }
/*
* Encabezado de la sección del componente
*
* A veces es necesario incluir un contexto opcional para el componente entero. Añádalo aquí si es lo suficientemente importante.
*/
.element { ... }
/* Sub-componente contextual, o modificador */
.element-heading { ... }Configure su editor con los siguientes ajustes para evitar incoherencias comunes en el código y falsos 'diffs':
Considere documentar y aplicar estas preferencias en el archivo .editorconfig de su proyecto. Vea, por ejemplo el de Bootstrap. Obtenga más información sobre el EditorConfig.