1. Buenas prácticas en la codificación HTML/CSS (El código HTML/CSS afecta al
rendimiento).
Temas relacionados: Tablas y CSS's | Óptimizar para Buscadores | PageRank en
Google | Éxito en Google
Contenido:
1. Introducción: resolución de conflictos por el navegador
2. Consejos en la codificación de Tablas
o 2.1 Anidamiento
o 2.2 Aspectos gráficos mediante tablas
o 2.3 Estructurar contenidos
o 2.4 El atributo WIDTH
o 2.5 El atributo HEIGHT
o 2.6 El atributo TABLE-LAYOUT
o 2.7 Formato HTML de Tablas, Filas y Celdas
o 2.8 HTML de Tablas bien formado
o 2.9 El atributo WHITE-SPACE
3. Consejos en la codificación de Listas
o 3.1 Especificación de marcadores (bullets)
o 3.2 HTML de Listas bien formado
4. Estilos y CSS's
o 4.1 Estilos "inline"
o 4.2 Formas de aplicar formato
5. Pseudo Clases para Links
o 5.1 Especificación de las pseudo-clases de hiperenlace en el órden correcto
6. Conflictos de estilos
o 6.1 Especificidad
o 6.2 Nomenclatura de reglas
1. Introducción: resolución de conflictos por el navegador:
Quizá una de las razones que ha colaborado a que haya millones de sitios en Internet
es la facilidad y rapidez con que cualquiera sin demasiada formación técnica aprende
HTML. Al menos los rudimentos más básicos para formatear páginas.

2. La segunda razón es la capacidad que tienen los browsers para interpretar HTML
incorrectamente escrito, al menos con algunos tipos de incorrecciones. De todos los
browsers actuales es, desde luego, Intenet Explorer el que mejor inetrpreta HTML-
mal formado.
Y esta capacidad de los navegadores de renderizar correctamente una página
burdamente escrita se basa en la lógica que tienen implementada para la resolución
de conflictos.
Por poner un ejemplo muy básico, se debería escribir un párrafo de texto entre los
tags <p> y </p>. Sin embargo, si el autor de la página abre un párrafo con <p> y
se le olvida cerrarlo, y abre el siguiente párrafo con un nuevo <p> que tampoco
cierra, el navegador interpretará que empieza nuevo párrafo, dará por supuesto el
cierre del primero, el del segundop y así sucesivamente.
La consecuencia negativa inducida de esta "buena virtud" es que esto ha contribuído
mucho al escaso cuidado con que los autores de páginas trabajan y a los escasos
conocimientos con los que se embarcan en la aventura.
Y las malas noticias son que esto no es gratis. Porque el navegador enmplea tiempo
(a veces muy apreciable si la página es extensa) en terminar de "pintar" un página
incorrectamente escrita, es decir, en resolver los conflictos por incorrecciones de
sintáxis.
Si, por ejemplo, escribimos una lista y no incluímos el tag de cierre de lista, </ul> el
navegador probablemente recorrerá todo el HTML de la página buscando el cierre
antes de tomar la decisión de dónde acaba la lista. Y si en la página hay más listas,
unas cerradas y otras no, el tema puede complicarse.
La conclusión es que vale la pena aprender HTML a fondo y aplicarse en escribirlo
sintácticamente correcto.
2. Consejos en la codificación de Tablas:
El elemento de código conflictivo por excelencia (al márgen del peso de las
imágenes, HTML Dinámico, carga y ejecución de JavaScript o Applets) son las Tablas.
Habida cuenta que es la forma absolutamente generalizada que tienen los
programadores de estructurar y situar contenidos y datos en la página, el tag y sus
atributos y relacionados se encuentan con gran profusión en cualquier aplicación.
Con frecuencia, para lo que menos se usan es para tabular datos en el sentido más
tradicional.
1. 2.1 Anidamiento: Está muy generalizado el que se suele incurrir en un
anidamiento de tablas excesivo lo que conlleva, por un lado el aumento del
peso de la página, por otro su longitud en caracteres (e indirectamente la
dificultad de mantenimiento), y, sobre todo, que para empezar a renderizar
la tabla padre el browser ha de haber completado la tabla hija, y para
completar la hija debe haber completado la de 3º nivel… y así
sucesivamente.
Al respecto de su uso y abuso, conviene hacer las siguientes
consideraciones:
 Evitar en lo posible el anidamiento de tablas, al menos, reducir el
número de niveles lo más posible.
2. 2.2 Aspectos gráficos mediante tablas: Se utilizan tablas dentro de
tablas para conseguir efectos gráficos: bordes-dobles, rellenos, distancias a
márgenes... Esto es un error mayúsculo e implica que se desconocen las

3. enormes posibilidades que ofrecen las CSS, utilizando en su defecto código
oneroso:
 Implementar todas las características gráficas de las tablas:
 Relleno (padding) de tabla y de celdas
 Distancias a bordes (margin)
 Bordes de tablas y de celdas
 Fondos de tabla, filas y celdas...
En concreto, mediante los atributos border-collapse y border-
spacing del modelo de tablas con bordes separados se pueden
conseguir efectos visuales muy interesantes.
3. 2.3 Estructurar contenidos: Se utilizan tablas dentro de tablas para incluir
secciones de una tabla (como por ejemplo una botonera, un grupo de
enlaces, un submenu…).
 Utilizar los encabezados /pies de
tabla <caption> con "align=top" y "align=bottom" (o el
atributo "caption-side: top,bottom" en la clase correspondiente), e
incluir elementos de formato contenedores ( <span>) que no sean
celdas.
 Utilizar tantos encabezados/pies de tabla como sean precisos para
especificar zonas adicionales de las mismas, siempre que esto ayude
a evitar tablas adicionales al respecto.
4. 2.4 El atributo WIDTH: Es muy recomendable utilizar "width" en tablas y
celdas:
 Utilizar siempre "width" en tablas y celdas en valor absoluto o relativo
según proceda, y siempre entre comillas dobles "width= 20%":
 Hay que aportar al browser la información necesaria para que
prediga dónde terminará físicamente la tabla: agiliza mucho
la renderización.
 De no existir esta información el browser tiene que recalcular
el ancho y alto de filas, columnas y celdas en función del
contenido de estas, y esto puede requerir, además, realizarlo
en varias pasadas, lo que penaliza mucho la renderización.
5. 2.5 El atributo HEIGHT: Utilizar el atributo "height" dentro del código HTML
para especificar la altura de una celda es uno de los desaciertos más típicos
en que caen los desarroladores de páginas, entre otras razones, porque es
aceptado por Internet Explorer, pero no es un estándar-HTML.
 La altura de filas o celdas debe especificarse mediante los
atributos "heigth" o "line-heigth" de las clases de estilo que les dan
formato.

4.  De ser preciso especificarlo en el HTML debe hacerse a nivel de fila,
en el "<tr>": aplicará a todas las celdas, reducirá el código y facilitará
la renderización de la tabla.
6. 2.6 El atributo TABLE-LAYOUT: Utilizar siempre que sea posible el
atributo "table-layout: fixed" (algoritmo de composición fija)
 Este atributo se especifica en la clase de estilo definida para la tabla.
 En este caso, el browser pinta la estructura de la tabla utilizando sólo
la información de anchos y altos de filas y celdas, ignorando
totalmente los contenidos de estas.
 La renderización será mucho más rápida que si utiliza un algoritmo
de composición automática, en cuyo caso tiene que analizar los
contenidos de las celdas, y en función de estos, ir recalculando las
dimensiones de filas, columnas y celdas para, a continuación,
pintarlas, lo que en ocasiones suele requerir varias pasadas hasta
obtener la disposición final de la tabla.
7. 2.7 Formato HTML de Tablas, Filas y Celdas: No utilizar (salvo que sea
imprescindible) elementos de formato codificado directamente en HTML en
tabla, filas o celdas.
 Todo, incluyendo alturas, colores de fondo, bordes, paddings,
margenes y características de fuentes... debe ir en clases de estilo
asociadas a tabla, filas o celdas.
 Simplifica el código en extensión y legibilidad, y ayuda mucho
a estructurarlo y mantenerlo.
 Simplifica la renderización porque el browser tendrá que
"recordar" sólo algunas clases de estilo para pintar una
estructura compleja y no tendrá que leer+asignar estilo
contínuamente a cada una de las celdas y sus contenidos.
 Facilita mucho la modificación del diseño y su reutilización.
8. 2.8 HTML de Tablas bien formado: Evitar tener algún tag de la
tabla "<tr>", "<td>", "<th>", "<caption>" sin cerrar.
 Aunque IE sea capaz de renderizar la estructura de una tabla
correctamente estando la sintáxis de la misma incompleta, en
muchos de los casos, supone un tiempo adicional de recorrido de la
estructura para llegar a pintar la tabla. Esto es especialmente grave
en tablas anidadas.
9. 2.9 El atributo WHITE-SPACE: A nivel celda, especificar si es posible en la
clase de estilo como se tratarán los espacios en blanco:
white-space:
 normal
 pre
 nowrap

5. 3. Consejos en la codificación de Listas:
1. 3.1 Especificación de marcadores (bullets): No utilizar especificación de
marcadores en los tags <>:
 Cualquier especificación de formato, incluído el tipo de marcador,
debería ir en una única clase de estilo específica el tipo de lista no-
oredenada (<ul>) u ordenada (<ol>).
 Simplifica el código en extensión y legibilidad, y ayuda mucho
a estructurarlo.
 Simplifica la renderización porque el browser tendrá que
"recordar" sólo 1 clase de estilo para pintar una lista entera y
no tendrá que leer + asignar estilo a cada elemento de la
lista.
 Facilita mucho la modificación de la apariencia de la lista y su
reutilización.
2. 3.2 HTML de Listas bien formado: Asegurarse siempre de que todos los
elementos de la lista tienen el tag de cierre y no hay coflictos en el orden de
cierre con otros tags relacionados (<p>, <font>...):
 Si no se cierra un tag <> el browser deberá recorrerse la lista entera
para poder reconstruirla. Esto es especialmente crítico en listas
anidadas (en las que además habrá que vigilar el cierre y órden de
los tags o </ul> y </ol>) ya que parsear y reconstruir toda la
estructura de elementos puede ser costoso en tiempo y de resultados
inciertos si el HTML no está correctamente formado.
4. Estilos y CSS's :
1. 4.1 Estilos "inline": Evitar en lo posible el uso de estilos "inline" por
elemento:
 Si la página es grande (tiene muchos objetos) aumentan
apreciablermente el peso de la misma al implicar mucho código
adicional.
 El tiempo de renderización es bastante mayor, sobre todo para el
caso de muchos elementos con los mismos estilos (por ejemplo en
celdas de tablas). Evidentemente el browser tarda menos en leer un
estilo de una CSS e ir aplicándolo a todas las celdas que lo precisen
que en ir celda por celda leyendo los atributos de su estilo "inline" y
hacer el render de todas ellas.
2. 4.2 Formas de aplicar formato: Evitar en lo posible la convivencia de
distintos tipos de "styling":
 Del desarrollo llegan a encontrarse en un mismo elemento:
 Estilo aplicado mediante reglas de una CSS asociada a la
página HTML
 Estilo CSS "inline"
 Estilo importado de una CSS externa

6.  Estilo HTML
 Aumenta la cantidad de código utilizada para aplicar estilo.
 Aumenta el tiempo requerido para renderizar el elemento.
 Aporta complejidad para seguir el código, previsualizar el estilo
aplicado y lo hace no reutilizable.
5. Pseudo Clases para Links:
Con alguna frecuencia no funciona la especificación "Hoover" de un hiperenlace. Esto
es porque el browser entra en conflicto debido a la manera en que se han definido
las pseudo-clases de formato de dicho hiperenlace (espera estén definidas en un
orden concreto y las pseudo-clases no lo siguen).
1. 5.1 Especificación de las pseudo-clases de hiperenlace en el órden
correcto en la CSS: Declarar siempre las pseudo-clases del hiperenlace en
la CSS en el siguiente orden:
 a {}
 a:link {}
 a:visited {}
 a:hover {}
 a:active {}
6. Conflictos de estilos:
Tanto para el caso de trabajar con única CSS, como trabajando con varias CSS's en
cascada, puede darse el caso de que varias reglas apliquen sobre un mismo
elemento. En el siguiente ejemplo:
<style type="text/css">
.ParrafoEj1 { color: blue;font-family: arial }
.ListaEj1 { color: red;font-family: tahoma }
</style
<p class="ParrafoEj1"> A continuación viene una lista:

7. <ul class="ListaEj1">
<li> Elemento-1</li>
<li> Elemento-2</li>
<li> Elemento-3</li>
</ul>
</p>
Vemos que para la cadena de texto "Elemento-1" aplicarían tanto la
regla ParrafoEj1 al ser un texto incluído en un párrafo formateado por esa clase de
estilo, como la regla ListaEj1, en cuanto que es un elemento de una lista
formateada por esa regla. Y los atributos de ambas reglas se contradicen: el texto
deberá ir en "arial, azul" o en "tahoma, rojo"?
1. 6.1 Especificidad: El mecanismo de que disponen las CSS's para resolver
este tipo de conflictos se llamaEspecificidad.
Algunos selectores son más específicos que otros. Por ejemplo, los
selectores-ID son más específicos que los selectores de clase. Y estos son
más específicos que los selectores de elementos HTML.
La especificidad se determina según el siguiente órden de priooridad:
11 Los selectores-ID son los selectores más específicos.
11 Los selectores de clase son más específicos que los selectores de
elementos HTML.
11 Los selectores contextuales y los selectores que impliquen a más de
un selector de elemento HTML son más específicos que los selectores
de elemento único.
11 Para dos selectores de múltiples elementos, es más específico el que
afecte a más elementos.
11 Cuando dos reglas tengan la misma especificidad, prevalecerá la que
aparezca en último lugar dentro de la cascada.
Por ejemplo, si dos reglas entran en conflicto y tienen igual
especificidad y ambas están en la misma hoja de estilo, prevalecerá
(tendrá mayor especificidad) la que aparezca en último lugar dentro
de dicha hoja de estilo.
Sin embargo, si dos reglas entran en conflicto y tienen igual
especificidad, una de ellas está en una hoja de estilo, y la otra está
en una hoja de estilo importada, prevalecerá la regla que esté
definida en la hoja de estilo importada, que será por tanto, la que
tenga mayor especificidad.
2. 6.2 Nomenclatura de reglas: La forma en que se asignen nombres a las
distintas reglas de una hoja de estilos no pede ser aleatoria.
De hecho hay una forma de nombrar clases de la CSS que es frecuente
encontrar y que, en varias versiones de browsers suele traer conflictos de
resolución impredecible.
Veamos el siguiente ejemplo en el que definimos reglas para formatear los
distintos elementos de la cabecera de nuestra página:

8. 11 .Header { … }
11 .HeaderTitle { … }
11 .HeaderTitle2 { … }
11 .HeaderTitle2Italic { … }
En este caso el desarrollador ha seguido una metodolología ordenada de
nombrar las clases que precisaba para formatear las cabeceras de sus
páginas
 .Header define el fondo, bordes, rellenos, etc. del área de cebecera.
 .HeaderTitle define el tipo, color y peso de letra del título.
 .HeaderTitle2 define el tipo, color y peso de letra del subtítulo.
 .HeaderTitle2Italic define el tipo, color y peso de letra del subtítulo
usado como "abstract", es decir, como flash explicativo del contenido
del página.
Pues bien: con esta nomenclatura de reglas aparentemente nemotécnica y
"usable", las posibilidades de conflicto para el navegador, según versiones,
son muy altas.
Efectivamente: cuando el navegador encuentra la llamada a la primera
clase, .Header, para formatear el área sobre la que se escribirá el título, la
encontrará en la CSS, encuentra el principio y el final de la cadena de texto
que constituye el nombre, y, en principio, no habrá problemas.
Sin embargo, cuando a continuación encuentra la llamada a la
clase, .HeaderTitle para formatear el texto del título, empieza a buscar en
la CSS y efectivamente encuentra .HeaderTitle, pero al seguir leyendo
encuentra.HeaderTitle2 y puede "tener dudas" de si el 2 forma parte del
nombre de la clase o es otra cosa, y lo mismo con .HeaderTitle2Italic.
El orígen del problema es que hay nombres de clase completos que forman
parte del(os) nombre(s) de otra(s) clase(s) en la CSS, con lo que en el
primer caso, con la clase, .Header existen las mismas posibilidades de
conflicto.
Por lo tanto, en la metodología de etiquetado de las reglas de las
CSS's, nunca el nombre de una clase deberá formar parte de otra
clase de ninguna de las CSS's, locales o importadas, con las que
estemos trabajando.