Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.
Ocho pasos para servir buen XHTML
Diseño UX
01/8/2006
|
Daniel Torres Burriel
Hoy hace un calor en Zaragoza de esos que a las 9 de la mañana te quitan las ganas de salir de casa. Así que os voy a proponer los ocho pasos que Tantek elik sugiere en 8 steps to serving better (X)HTML para servir un buen código XHTML. No son cosas excesivamente nuevas, ni mucho menos, pero por lo menos están ordenadas y siempre las podemos recuperar e incorporar a nuestros procesos de validación.
- Valida las páginas. Es el paso fundamental que hay que remarcar tantas veces como sea necesario. No podremos dar pasos adelante si tenemos un código XHTML que no sea válido. A modo de ayuda, los errores más comunes que impiden que una página valide correctamente son:
- Ampersands (&) sin escapar (codificar). El modo correcto de hacerlo es así:
&, en minúscula - Elementos sin cerrar, como
img,linkobr - Elementos de bloque (block) situados dentro de elementos en linea (inline)
- Cierre de tags donde no corresponde
- Falta de cierres de tags, quedando éstos abiertos
- Scripts sin su correspondiente atributo
type - Hojas de estilo dentro del
body - Existencia de atributos propietarios, como
autocomplete - Utilización de atributos con mayúsculas donde no se debe, como
onSubmiten lugar deonsubmit - Formularios sin el atributo
action - Varias etiquetas
bodydentro de la página - Uso de atributos
targeten XHTML estricto
- Ampersands (&) sin escapar (codificar). El modo correcto de hacerlo es así:
- Elimina diseños basados en tablas e imágenes con espacios en blanco. No debería haber mucho más que decir sobre esto, ¿no?
- Deshazte de los metas keywords. No merece la pena gastar tiempo ni espacio en esto. A los buscadores ya no les importa.
- Mejora la nomenclatura de los valores del atributo class. Algunos ejemplos de buenas prácticas al respecto:
- Usar selectores de contexto
- Uso de minúsculas en los nombres de las clases e id’s
- Evitar nombres de clases con significado relacionado con la presentación, como
azul,titverde, etc.
- Suprime los espacios en blanco en el código. No ayudan en nada, son molestos y no tienen razón de ser.
- Haz uso de rel y de hreflang cuando uses un idioma diferente. El uso de
rel="alternate"implica que existe una alternativa a la página en otro idioma. - Reduce el código comentado. El código comentado debería ser eliminado al pasar por el servidor. Lo ideal es que en lugar de usar los comentarios de código de HTML, usemos los propios del lenguaje de servidor que se use: php, ruby, etc. Claro que eso es válido siempre que hagamos uso de sitios web dinámicos. En el caso de páginas estáticas no hay más remedio que usar los comentarios de HTML.
- Usa hCard. Usar el microformato hCard para marcar nuestra información de contacto.
Que aproveche.
En Torresburriel Estudio apoyamos el rediseño de tu producto digital con un proyecto de acompañamiento donde aplicamos metodologías de diseño centrado en el usuario. Contacta con nosotros y cuéntanos tu proyecto. Te enviaremos una propuesta adaptada a tus necesidades y presupuesto.
No veo tan claro que sobre el punto 3: «Deshazte de los metas keywords». Me parece que no sobran.
Hay herramientas SEO que continúan promoviendo las «palabras clave». Por ejemplo la herramienta Seekbot, es un simulador del robot de Seekport, y en cualquier evaluación que hace las calafica como Importantes y las solicita cuando faltan.
¿No creen que es mejor que sobren que no que falten?
Por lo que respecta a la traducción de lo que dice Tantek elik, creo que es lo que quiere decir, claro que puedo estar perfectamente equivocado.
Y en lo que respecta a mi opinión, creo que las palabras clave son útiles en tanto en cuanto las usemos dentro de nuestro sitio web para operar con ellas, y no tanto como para que los motores de búsqueda operen con ellas.
Un apunte que he olvidado comentar es que mi opinión al respecto de las palabras clave debe tener en cuenta la supremacía aplastante de Google en cuanto a herramienta de recuperación de información para usuarios de internet 🙂
Buen punto.. jejeje!
Olvidaste poner (o pusiste mal) el enlace a la nota original. 🙂
Cierto, Federico. Gracias. Ya está arreglado.
Saludos, Dani y lectores de este blog.
Otro detalle más (debo estar borracho si estoy corrggiendo a Tantek, je je). La existencia de
rel="alternate", no implica que exista una versión en otro idioma, también puede ser en otro formato [type] (por ejemplo, en un fichero pdf), o para otros medios [media] (por ejemplo, una versión para PDAs).Por lo demás, tampoco estoy muy de acuerdo con suprimir los metadatos, eso sí, si nos decidimos a ponerlos, que estén bien hechos.
[…] Recorto y pego (literalmente) desde la web de torresburriel esta lista de pasos para servir un buen XHTML Me ha parecido tan buena y ordenada que me la apunto, para que no se me olvide nada. El original es de Tantek elik 8 steps to serving better (X)HTML. […]
Buen apunte, lo seguire pero me entra una duda con esto
Utilización de atributos con mayúsculas donde no se debe, como onSubmit en lugar de onsubmit
esto esta claro los atributos siempre en minuscula, pero leyendo la especificacion del xhtml, tambien dice que los valores de los atributos deben estar en minuscula
y mi pregunta es por ejemplo tengo una capa que la llamo menuHeader, le pongo esa letra asi en mayuscula para poder leerla, validando el xhtml en w3c no da problemas tampoco el taw
pero esta realemente bien? deberia de dejarme de hacer eso y ponerlo siempre en minusculas aunque para mi sea mas dificil leer despues el codigo
espero vuestras opiniones
graciass
Muy interesante el articulo!!
Saludos
[…] de 2006 a las 14:45 y está archivada en: (x)HTML. Puedes dejar un comentario, o enviar un trackback desde tusitio. […]
Guau, hay cosas allí que uno no percibía. Gracias muy útil.
Ruby
Hola.
Voy leyendo en varios sitios la recomendación de no usar letras mayúsculas en nombres de clases e id’s, pero no encuentro una razón concreta para no hacerlo («Puede dar problemas en …»)
Me ha tocado ver un CMS que automáticamente transformaba las mayúsculas en minúsculas, pero aparte de este tipo de problemas, ¿por qué no se recomienda hacerlo?
Saludos.
[…] Ocho pasos para servir buen XHTML […]