| Errores Comunes del desarrollo web
POR ROGER JOHANSSON - www.456bereastreet.com/
Traducción al español por Hermann Kaser. Artículo original en inglés
Han habido muchos comentarios sobre mi reciente articulo titulado Web development mistakes (Errores comunes del desarrollo web) y eso es bueno. No todos los comentarios eran del tipo que yo pedí, pero crearon una interesante discusión, que no se me fue de las manos.
He repasado la lista original y agregado algunos errores mencionados en los comentarios mas constructivos, junto con, y quizás esto debería haber estado desde el principio, mis razones para llamar a algo un error e incluirlo en la lista. También he añadido algunos enlaces para dar mas información sobre algunos errores, para aquellos que quieran saber mas.
Confusión con el DOCTYPE
Obviándolo completamente, incorrecto o en el lugar equivocado. He visto HTML 4.0 Transitional usado en documentos que contenían XHTML así como en documentos con marcos, declaraciones de DOCTYPE apareciendo después de la etiqueta de <html> y DOCTYPES incompletos.
¿Por qué? Dos razones. Primero, lo dice la especificación de HTML 4.01 así como la de XHTML 1.0. Segundo, la mayoría de los navegadores modernos usan el DOCTYPE para decidir que tipo de procesamiento van a usar. Esto se conoce como “Intercambio de DOCTYPE”. Para que los resultados sean más consistentes a través de la mayor cantidad de navegadores, especialmente usando CSS, querrán que los navegadores usen su “Modo de conformidad con los estándares”. Mas información en Fix Your Site With the Right DOCTYPE! (Arregla tu sitio con el DOCTYPE correcto) y Activating the Right Layout Mode Using the Doctype Declaration (Activando el modo de diseño correcto usando la declaración de DOCTYPE)
<span>-mania
Una forma común de estilizar algo con CSS es meterlo dentro de un elemento <span> y ponerle una propiedad con una clase. Estoy seguro que todos hemos visto cosas como <span class="cabecera"> y <span class="texto">.
¿Por qué? En la mayoría de los casos es completamente innecesario, no tiene valor semántico y hace que el código quede ilegible. Usen elementos de cabecera para la cabecera, pongan párrafos en los elementos de párrafo, hagan listas con los elementos de listas de HTML. Usen CSS para estilizar esos elementos. Si es necesario, añadan atributos de clase o id.
(Demasiada) Organización visual
Tratar de crear paginas como si se tratase de un WYSIWYG, pensando en como va a quedar el diseño, en vez de preocuparse de la estructura primero y de la presentación luego.
¿Por qué? No toda la gente que usa Internet puede ver. Y no hay ninguna manera de la web WYSIWYG. Siempre va a haber variaciones mientras la gente siga usando distintos navegadores, sistemas operativos, tamaños de pantalla, resoluciones de pantalla, tamaño de ventanas, calibración de colores y tamaño de fuentes. Internet NO es un libro o la televisión. Haz tu diseño flexible.
Falta de semántica
Código no semántico. Elegir que elemento HTML usar en función de cómo se ve (visualmente) en la mayoría de los navegadores, en vez de por su significado. (NT: Usar <b> en vez de <strong>)
¿Por que? Este error esta relacionado con el de “<span>-mania” en que no se usan los elementos de HTML para dar significado al contenido. Sin HTML semántico es mucho más difícil que los navegadores no-visuales puedan entender el sentido del documento. El código semántico tiende a ser mas fácil de estilizar con CSS.
Codificacion del texto no acorde
Especificar la codificación del texto en la cabecera HTTP que manda el servidor y usar otra en los documentos. Esto puede confundir a los navegadores y hacer que muestren el documento de una manera incorrecta.
¿Por qué? Porque quieres asegurarte que todos los visitantes pueden leer el contenido.
Atributos alt inservibles
Obviados o inservibles. Se pueden encontrar millones de elementos <img> sin un atributo alt. No tan comunes son los atributos inservibles como “espaciador GIF usado para que diseño quede bien ”, “viñeta grande y azul con sombra” y “imagen JPEG, 123 KB”. Recuerden que el atributo alt es requerido en las etiquetas <img> y <area>.
¿Por qué? Se requiere, y sin él cualquier información sobre en la imagen será invisible a los lectores de pantalla, navegadores de texto, buscadores o usuarios con las imágenes apagadas. Nótese que el texto alternativo debe ser relevante. No hace falta especificar el texto alternativo para imágenes decorativas. En ese caso se puede usar una cadena vacía, alt="".
Nombres de id o clases inválidos
Múltiples usos de un mismo valor id. Caracteres inválidos en los nombres de clases y id.
Para CSS (Sintaxis y tipos básicos de datos en CSS2):
En CSS2, los identificadores (incluyendo los nombres de los elementos, clases e ID de los selectores) pueden contener sólo caracteres [A-Za-z0-9] y los caracteres 161 en adelante en ISO 10646, más el guión (-); no pueden comenzar con un guión o un número. También pueden contener caracteres con escape y cualquier carácter de ISO 10646 en forma de código numérico. Por ejemplo, el identificador "B&W?" puede escribirse como "B\&W\?" o "B\26 W\3F".
Para HTML (Tipos de datos basicos de HTML):
Las palabras ID y NAME deben comenzar con una letra ([A-Za-z]) que puede estar seguida por un número cualquiera de letras, dígitos, ([0-9]), guiones (“-“), guiones bajos (“_”), dos puntos ((“:”), y puntos (“.”).
¿Por qué? Los navegadores que sigan las especificaciones no van a mostrar el documento como es debido. Si el documento tiene varios elementos con el mismo atributo id, cualquier código JavaScript que use ese atributo no funcionara o lo hará de manera defectuosa.
Detección de navegador
Usar programas, de cliente o servidor, para detectar el modelo de navegador del visitante y enviar código diseñado específicamente para ese navegador. Falla frecuentemente por razones como navegadores nuevos, navegadores actualizados y spoofing de navegadores (Opera hace esto por default).
¿Por qué? Añade complejidad innecesaria y se romperá eventualmente.
Unidades obviadas en CSS
Los valores de longitud (horizontales y verticales) requieren valores en CSS, excepto cuando es cero. No es como HTML, donde se puede poner width="10". En CSS tiene que ser width:10px; (o cualquier unida válida).
¿Por qué? No funciona en navegadores que sigan la especificación.
CSS especifico de un navegador
Estilo de la barra de desplazamiento, expresiones y filtros .CSS propietario que funciona solo en Internet Explorer.
¿Por qué? Solo funciona en navegadores especificos. Si es absolutamente necesario usar CSS especifico de IE, muévelo a un archivo separado y usa comentarios condicionales para que solo IE lea las instrucciones inválidas.
Dependencia a JavaScript
Hacer un sitio que dependa del JavaScript. Mucha más gente de lo que piensas usa un navegador que no soporta JavaScript o lo tienen deshabilitado. Estadísticas actuales (Estadísticas de navegadores en W3Schools, TheCounter.com) indican que esto es un 8-10% de los navegantes. Los buscadores tampoco tienen un buen soporte para JavaScript, aunque hay noticias de que Google esta trabajando en un soporte para JavaScript con GoogleBot. Si tu sitio requiere JavaScript para navegar, no esperes grandes resultados en los ranking de los buscadores.
¿Por qué? Inservible e inaccesible para los buscadores.
Dependencia a Flash
Asumir que todo el mundo tiene Flash instalado. No todos lo tienen. Y la mayoría de los buscadores tampoco (Google ha comenzado a experimentar con indexar archivos Flash, pero todavía recomiendan que todo el texto y la navegación este disponible en HTML), así que si todo tu sitio depende de flash no vas a obtener grandes resultados en los buscadores.
¿Por qué? Inaccesible para los buscadores. No digo que no se debe usar Flash, sólo digo que se debería usar bien.
Texto en imágenes
Hacer imágenes de texto sin tener una alternativa accesible. No solo tarda mas para que el visitante se baje las imágenes en vez del texto, sino que también se evita que los visitantes puedan copiar el texto o lo agranden.
¿Por qué? Inaccesible, incrementa el tiempo de carga y es fatal para los buscadores.
Formularios malos
Formularios inaccesibles y difíciles de usar. Aprende a usar los elementos <label>, <fieldset> y <legend>, y a no usar el boton de “Reset”
¿Por qué? Inaccesibles y con una usabilidad reducida. Es recomendable leer Creating Accessible Forms y Better Accessible Forms para saber mas sobre como hacer formularios.
HTML arcaico
Multiples tablas anidadas, gifs espaciadores, elementos <font> y otros elementos visuales. Tan común que ni siquiera tengo que mencionarlo.
¿Por qué? Complejidad alta, paginas toscas, inaccesibles y malo para los buscadores.
Ser IE-centrico
Programar para IE/Win primero, luego ajustando para los otros navegadores, si hay tiempo.
¿Por qué? Tarda más tiempo, incita a programar mal. IE/Win es reconocido por aceptar código mal hecho, que se rompe en los otros navegadores. IE también acepta código bien escrito que funciona en todos los navegadores. También leer The IE Factor.
Atributos de HTML invalidos
Usar atributos deprecados o especificos de un navegador como marginwidth, leftmargin, language, height para <table>, border para <img> etc.
¿Por qué? Invalido e inecesario. Es mejor usar CSS. Para elementos <script> usar type y no language, para especificar el lenguaje (casi siempre JavaScript).
Ampersand sin codificar
Muchas veces las URI pueden contener ampersands sin codificar (&). Esto no es válido y puede causar problemas. Los ampersand deben estar escritos como &.
¿Por qué? Los ampersands y la validación
Marcos
Usar marcos para dividir la ventana del navegador en partes independientes.
¿Por qué? Primero, déjenme decirles que los marcos pueden ser útiles, si se usan de una forma correcta, en intranets y ciertas aplicaciones web. Para un sitio publico, sin embargo, pueden tener demasiados problemas de accesibilidad y usabilidad. Problemas para guardar favoritos, para imprimir y tener que hacer alternativas para los buscadores son algunos de los inconvenientes de usar marcos.
Tablas de datos inaccesibles
Tablas que contienen información tabular, pero señalizadas como si fuesen tablas de diseño, sin usar los muchos elementos y atributos existentes para hacer tablas estructuradas y accesibles.
¿Por qué? Los lectores de pantalla y otros medios asistivos no tienen manera de sacarle el sentido a una tabla a menos que este señalizada correctamente. Hay un montón de enlaces a artículos que describen como señalizar una tabla de datos en A table, s’il vous plaît.
Divitis and classitis
Relacionado con <span>-mania. Añadir elementos div y atributos class innecesarios.
¿Por qué? Ver “<span>-mania” y “falta de semántica”
Anchura fija demasiado ancha
Si usan anchura fija, no la hagan demasiado ancha. Nota: No me estoy metiendo en el debate fijo vs. fluido.
¿Por qué? Si la anchura especificada es mayor que la del monitor del visitante entonces lo están obligando a utilizar la barra de desplazamiento horizontal, lo cual es muy malo para la usabilidad.
Nombres de clases o ids definidos
Llamar a una class o id en funcion de su aspecto actual en vez de lo que hace.
¿Por qué? Hacer esto es hacerte el camino mas duro a la hora de rediseñar. Una clase llamada grandeazul puede terminar haciendo que el texto sea pequeño y rojo. Un id llamado columnaizq puede cambiar y estar a la derecha.
No especificar el color de fondo
Evitar declarar el color de fondo del elemento body.
¿Por qué? Muchos usuarios no tiene el navegador configurado para que el color de fondo por defecto sea el mismo que el tuyo.
XHTML mal formado
Usar XHTML que no esta correctamente escrito.
¿Por qué? Si el XHTML se manda como “application/xhtml+xml”, los navegadores que cumplen estrictamente con los estándares no mostraran un documento mal formado. Notese que este sitio no manda todos los documentos como “application/xhtml+xml” por razones explicadas en el articulo titulado Content negotiation.
Esta es una lista muy larga de cosas que tener en cuenta. Si las evitan entonces todo ira bien. Si actualmente están cometiendo estos errores, les puede consolar el hecho de que yo también he sido culpable de cometer muchos de ellos en algún momento. Seguramente esta lista los ayudara a cometer menos errores en el futuro. |
Suscribirse al Boletín
