La mejor manera de hacer que nuestros sitios web se vean y funcionen correctamente en cualquier navegador, es escribiendo código limpio y que respete los estándares. En la actualidad, la calidad del código HTML presente en cada página es un factor que ayuda a mejorar -o empeorar- el posicionamiento en buscadores, una razón de peso para preocuparnos por escribirlo correctamente.
La lista de buenas practicas que sigue a continuación puede ser percibida por los desarrolladores más avanzados como "básica", y puede que así sea. Sin embargo, espero que sea de utilidad para todos, en especial para nuestros lectores que recién se inician en este mundo del desarrollo web.
En las primeras versiones del lenguaje -hablo de muchos muchos años atrás- y con los navegadores antiguos, muchas de estas reglas podían omitirse y cada uno establecía su propio estilo, sin que esto preocupara mucho a nadie. Por fortuna, las cosas han cambiado y hoy día somos mucho más exigentes con nosotros mismos.
Existe algunas reglas que debemos respetar, sobre todo ahora que HTML5 comienza a presentarse con más fuerza. Estas reglas no las inventé yo, solo las aprendí con mi trabajo y hoy quiero compartirlas para que todos escribamos HTML de calidad.
Declarar el DOCTYPE correcto
Existen varias versiones de HTML, cada una con sus propias reglas, etiquetas, elementos y atributos. La única manera de que un navegador muestre correctamente una página web es conociendo exactamente la versión de HTML que usa el documento que la contiene.
Para indicarle al navegador la versión de HTML que estamos usando debemos usar la declaración <!DOCTYPE> y debe ser la primera línea de nuestro documento. Y aquí algunos ejemplos:
DOCTYPE en HTML5
<!DOCTYPE html>
DOCTYPE HTML 4.01 Strict
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
DOCTYPE XHTML 1.0 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Si te encuentras un poco confundido ahora, puedes utilizar esta referencia donde se muestran las diferentes declaraciones posibles y las diferencias entre ellas.
Recuerda cerrar las etiquetas
Un documento HTML está compuesto por muchas etiquetas que sirven para definir encabezados, párrafos e incluso secciones enteras, usualmente vienen en pares, una para abrir y otra para cerrar. Siempre que abras una etiqueta, recuerda cerrarla correctamente.
Incorrecto <p>Lorem ipsum dolor sit amet
Correcto <p>Lorem ipsum dolor sit amet</p>
Nombra las etiquetas siempre en minúsculas
Tan importante como cerrarlas, es usar los nombres de las etiquetas siempre en minúsculas. Lo correcto es <p> </p>, <div> </div>, <h1> </h1> no es <P> </p>, <dIv> </DIV>, <H1> </H1>, . Además de que produce nauseas leer código escrito de esa manera, es probable que los navegadores modernos no interpreten correctamente estas etiquetas.
Utiliza ficheros externos para CSS y JavaScript
Aunque puedes crear funciones JavaScript y dar estilo a los elementos directamente en el documento HTML, por favor, nunca lo hagas. Utiliza siempre hojas de estilo y scripts externos en archivos separados para estos fines.
Enlaza los CSS externos al principio
Aunque en teoría puedes enlazar los archivos CSS externos en cualquier parte del documento HTML, lo más recomendable es hacerlo dentro de las etiquetas <head> </head>, en la practica esto hará que las páginas se cargan ligeramente más rápido.
Enlaza los JavaScript externos al final
En la medida de lo posible trata de enlazar los archivos JavaScript, justo antes de la etiqueta </body>. Esto ayudará a que las páginas carguen mucho más rápido.
No es una tontería y existe una explicación para esto: cuando el navegador está cargando un script, se detiene por completo la carga del resto del sitio y continua una vez que finaliza el otro proceso. Si se trata de un script de gran tamaño, el usuario deberá esperar un poco y notará fácilmente que algo sucede en el fondo, algo para nada elegante.
Usa el atributo "alt" en todas las imágenes
Es una regla fácil de olvidar, sin embargo hay que hacer un esfuerzo por recordar incluir el atributo "alt" en todas las imágenes. Aunque parezca una tontería, es necesario incluir este atributo por razones de validación y accesibilidad.
Valida tu código
Validar el código de los documentos varias veces durante el proceso de creación, te ayudará a descubrir errores de manera oportuna y te ahorrará dolores de cabeza innecesarios al final, cuando pensabas que ya habías terminado. W3C pone a nuestra disposición su Markup Validation Service que nos permitirá realizar esta tarea de manera sencilla y nos avisará sobre cualquier error en nuestro código.
Memoriza todas las etiquetas
Resulta muy útil repasar la lista completa de etiquetas HTML disponibles y tratar de memorizar la mayor cantidad de ellas. Siempre puedes acceder a la referencia, pero mantenerlas en la cabeza te ayudará a escribir código mucho más rápido.
Si memorizar no es lo tuyo, te recomiendo buscar un editor con soporte para HTML (hay cientos) que te ayude a agilizar el proceso, autocompletando código y ofreciendo sugerencias.
Lee código de otros
Para cerrar, aunque no esté ligado únicamente al código HTML (ya que aplica para JavaScript, CSS y cualquier otro lenguaje) al leer código de otros desarrolladores, incluso mirando el código fuente de tus sitios web favoritos puedes aprender mucho. Inspecciona ese elemento particular que llama tu atención y aprende como lo hicieron. Revisa otros estilos y crea uno propio.
Muy buena nota. Es cierto que W3C detecta errores, ¿conocen alguna herramienta un poco mas precisa?, por que el error aparece, pero uno queda ciego al momento de buscarlo y corregirlo en los archivos.
Siempre he usado el W3C y sinceramente no conozco otro. No entiendo a que te refieres con "más precisa". Cuando hay un error siempre te indica la línea en la que se encuentra y te da una idea de lo que está faltando o sobrando.
Cargar al final javascript? no concuerdo, tal vez con sitios que no lo requieran, no así con sitios que dependen de la libreria JS para funcionar, si es el caso, lo mejor es cargar en head los scripts
Cargar JS al final garantiza que todos los elementos del DOM que van a ser usados por ese JS para funcionar van a estar cargados completamente y totalmente funcionales. Sin DOM la página tampoco funcionaría correctamente, por esta razón es recomendable dejarlo para el final.
Esto no es tan cierto, declarando las funciones de javascript dentro del evento ready o load del documento, garantizamos que todo el DOM este cargado antes de aplicar el js. La razón por la cual se recomienda cargan los js al final es porque el navegador no hace nada más en paralelo mientras se cargan los js (sólo descarga los js y los interpreta), haciendo más lenta (un poco) la carga de la página, en cambio si lo ponemos al final, ya todos los archivos (css, imagenes, etc) han sido solicitados al servidor.
Intuyo que el autor se refiera principalmente (además lo dice) a JS "externo". Comunmente hablamos de scripts de FB, Twitter, jQuery, etc. Si es cierto que se pueden cargar manualmente onload.
Aunque se pueda esperar al evento onload o DOMContentLoaded para ejecutarlos, lo cierto es que los scripts no asíncronos bloquean la carga de la página .
Es decir, si se tarda 100ms en leer jQuery, son 100ms en los que el navegador no está interpretando el HTML, por lo que la página tardará más en mostrarse al completo.
Emilo checa CloudFlare, ese es la tendencia en la web, servidores de archivos de carga asíncrona, si tienes uno de esos es mejor tener todo al inicio, la posicion de los archivos es circunstancial
Cloudflare no es un CDN? (es decir, un servidor de archivos que sirve los más cercanos al visitante)
Lo que me refiero con asíncrono es que el script tenga literalmente el atributo async en el HTML.
http://www.cloudflare.com/features-optimizer
¿Por qué utilizar archivos externos para el css y js? Si es por una supuesta carga más rápido se supone que en teoría es lo mismo ¿no? El css se debe de leer para cargarse, por lo que daría igual incrustarlo en la página o en un archivo externo. En cuanto al Javascript, si lo enlazas o declaras antes del body, ¿Qué pasa si utilizas las funciones que hiciste al inicio (para lo que sea que se haya hecho)? Si las tienes que declarar antes para usarlas saldría lo mismo que poner antes todo el código ¿no?
Están bien las recomendaciones, pero hay que aclarar el por qué.
Mmm quise decir "El css se debe cargar para leerse" y "declaras antes del "
Por que si lo metes en la misma página no podrás usarlo en otras (cualquier proyecto tendrá más de una página casi con toda seguridad) y además no se cachea.
Tener el CSS y el JS en archivos externos separados, entre otras cosas, facilita la lectura del código HTML. La idea es escribir código limpio y válido.
Lo ideal es que todo el css este en un archivo y todo el js en otro, para así, en sólo dos peticiones al servidor cargar todo lo necesario. Se recomienda tener el css y el js en archivos externos por dos razones fundamentales: (1) que estos archivos sean re-usables en diferentes páginas y (2)separar la presentación(css) del contenido(html).
Los archivos CSS externos se almacenan en la caché de navegador, de tal manera que una hoja de estilos que es usada en 5 páginas (por decir algo), sólo es descargada una vez. Si incrustas todos los estilos en las páginas, se van a descargar 5 veces.
No concuerdo con cargar los javascripts al final, tenia sentido, pero con los nuevos servicios de carga asincrona como cloudflare, es mejor cargar los archivos externos lo antes posible.
Si vas a utilizar un servicio de carga asíncrona, tal como mencionas, si tiene mucho más sentido cargarlos al inicio. Para ese caso particular apoyo tu opinión, ¡gracias por el aporte!
No me sabía ése de cargar poner el javascript al final, estuve toda una vida poniéndolo al inicio en el head. Y sumándolo con el último punto, han sido muy pocos los sitios que he visto que lo hayan hecho distinto a mi práctica, incluso he vi sitios que ponían casi todo al inicio y al final uno que otro.
Buen artículo, siempre se aprende algo con entradas sencillas como la tuya Saludos
Pues deberíais aplicaros lo de la validación del código… El W3C Markup Validator dice que tenéis, según la página, 199 errores y 183 advertencias…
donde consigo un buen curso de dreamweaver 8.