Entradas en la categoría “Estándares”

Favicon y estándares

22 de enero, 2009 - por | | Estándares

¿Cómo añadir un favicon a tu sitio web? es una de las entradas de la W3C recomendando su método preferido para poner el favicon en tu sitio web.

Un favicon es una imagen (icono) que se asocia con tu sitio. ¿Ves nuestro sombrerito en la barra de direcciones del navegador? Es nuestro favicon, ;-). Para añadir un favicon a tu sitio web la W3C recomienda que hagas una imagen de 16×16 ó 32×32 píxeles en formato PNG (un estándar del W3C), GIF o ICO. Después, la guardes dentro de tu árbol y la definas en la página con el valor del atributo rel=”icono”. Además, tendrás que definir qué tipo de imagen es y dónde la has colocado.

Ahí va un ejemplo para HTML 4.01:

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en-US"
lang="en-US";

type=”image/png”
href=”/somewhere/myicon.png” /;
[…]

[…]

[…]

[…]

Para XHTML 1.0 es muy parecido:

[…]
[…]

¡Vamos a intentarlo!

Desarrollo con estándares web 2

2 de diciembre, 2008 - por | | Desarrollo, Estándares

Segunda parte de la traducción al español del texto de Roger Johansson: Developing With Web Standards – Recommendations and best practices.

¿Aún no leíste la primera parte?


3. Estándares web

¿Qué son los estándares web?

Los estándares web son tecnologías, establecidas por el W3C y otras instituciones de estándares, que son utilizadas para crear e interpretar contenido web. Dichas tecnologías están diseñadas para documentos-tipo futuros publicados en la web, y para hacer dichos documentos accesibles al mayor número de personas y dispositivos posibles.

Lenguajes para estructurar

Lenguajes de presentación

Modelos

Lenguajes de scripting

Este documento se centra en HTML 4.01 Strict para la estructura, CSS Nivel 1 y Nivel 2 para la presentación, y JavaScript para el scripting (aunque no se ofrecen muchos ejemplos de scripting).

Cuando se dice que un documento se adhiere a los estándares web, quiere decir que el documento además de hacer uso de las tecnologías referidas antes:

  • consiste en HTML o XHTML válido
  • utiliza CSS en vez de tablas para el layout
  • está propiamente estructurado y semánticamente marcado
  • funciona en cualquier navegador web

“Funciona en cualquier navegador web” no quiere decir “se ve igual en cualquier navegador web”. Hacer que un documento se muestre de forma idéntica a través de navegadores web y plataformas es prácticamente imposible. Incluso utilizando sólo imágenes tampoco se conseguirá que se muestre de forma idéntica en cualquier sitio.

Los documentos que son publicados en la web son consultados por una amplia variedad de dispositivos en diferentes sistemas operativos, con monitores de diferente resolución y calidad (o sin monitor, incluso), así como por usuarios que pueden haber cambiado el tamaño de fuente por defecto del navegador, así como otras preferencias.

Darse cuenta de ésto y aceptar que simplemente no puedes tener el control absoluto de la apariencia visual de un sitio web en los navegadores de tus usuarios hace que tu vida sea mucho menos frustrante. Cualquiera que crea sitios web necesita entender que existen prerequisitos técnicos a considerar, de la misma forma que aquellos que publican sobre papel o hacen películas o televisión tienen otros prerequisitos que considerar.

¿Necesita un sitio web comportarse exactamente igual en todos los navegadores?

¿Por qué utilizar estándares web?

Algunos desarrolladores y diseñadores web tienen resistencia respecto del uso de estándares web. Argumentos comunes son los de “…es demasiado difícil”, “…funciona en cualquier caso”, y “…los programas generan código inválido”.

Es fácil reaccionar emocionalmente y construir una resistencia hacia el aprendizaje de algo nuevo, que requiere que abandones técnicas que conoces y con las que te sientes cómodo. Sin embargo, si contemplas la situación de una forma lógica verás que hay muchos beneficios para aprender y utilizar estándares web. He aquí unos pocos:

  • desarrollo y mantenimiento más fáciles: Utilizar HTML más semántico y má estructurado hace mucho más fácil y rápido entender el código creado por cualquiera. Agradecerás, asimismo, cuando tengas que cambiar algo en tu propio código meses o años después de la primera vez que lo escribiste
  • compatibilidad con futuros navegadores web: cuando utilizas estándares definidos y código válido tus documentos pasan la prueba del futuro, reduciendo el riesgo de que futuros navegadores web no sean capaces de entender el código utilizado
  • descarga y renderización más rápidas de las páginas: utilizar CSS para la presentación tiende a aligerar los documentos HTML, lo que significa descargas más rápidas para los usuarios
  • mejor accesibilidad: HTML semántico, donde la estructura está separada de la presentación, hace más fácil para lectores de pantalla y dispositivos de navegación alternativos interpretar correctamente el contenido
  • mejor posicionamiento en los buscadores: la separación de contenido y presentación hace que el contenido represente una mayor parte del tamaño total del fichero. Combinado con marcado semántico ésto generalmente mejora el posicionamiento en los motores de búsqueda
  • adaptación más sencilla: un documento semánticamente marcado puede ser fácilmente adaptado para imprimir, así como para dispositivos de navegación alternativos, como dispositivos de mano y teléfonos móviles, simplemente enlazando a distintos ficheros CSS. Puedes, asimismo, hacer cambios que afectan a todo el sitio web editando un único fichero

El uso de estándares web ahorra tiempo y dinero para los creadores de sitios web, y en general aporta una mejor experiencia del usuario del sitio web.

Validación

Validación es el proceso de controlar que un documento se adhiere a las reglas del lenguaje de programación utilizado en el documento. Puedes compararlo chequeando un texto que has escrito para ver errores de “spelling”.

Asegurar la calidad a través de la validación es una importante parte del desarrollo web. Muchos errores que son difíciles de descubrir manualmente, son descubiertos durante la validación. Un error puede ser tan trivial como un error de escritura, o tan serio como un elemento o un atributo utilizados de un modo incorrecto. Puede no tener ningún efecto en la forma en que el documento es renderizado en un navegador web o desfigurarlo completamente.

Desgraciadamente, mucha gente no valida sus documentos. Algunas personas puede que no tengan conocimiento de la validación, otras llegan a olvidarlo, y hay otros que intencionadamente evitan la validación. Creo que esta situación se puede atribuir a las compañías de navegadores web. La mayoría de los navegadores web intentan interpretar HTML inválido de la mejor forma que pueden e intentan averiguar cuál es la intención del creador en vez de mostrar un mensaje de error. Es comprensible que los navegadores web quieran hacer tal cosa, pero esta tolerancia de errores es sin duda la principal razón para el (sloppy) marcado que es comúnactualmente.

¿Por qué no queremos ayudarte? es una explicación excelente de Mark Pilgrim sobre las ventajas de la validación. El artículo también explica por qué puede resultar más difícil conseguir ayuda de la gente en foros de discusión y listas de correo si no has validado tus documentos antes de preguntar.

Algunos editores HTML disponen de herramientas de validación ya listas o utilizan los servicios de validación del W3C, disponibles onlne. Puede utilizar los servicios de validación manualmente:

Otra herramienta excelente para chequear la validez del HTML que creas es la extensión HTML Validator para Firefox.

Comprender los mensajes de error generados por los validadores puede resultar un poco difícil. Un error inicial en un documento puede causar numerosos errores adicionales. Corrigiendo el primero y revalidando conseguirás reducir sustancialmente el número de errores.

Es importante tener en cuenta que la validez por sí sola no significa que el documento es accesible. Tampoco unos pocos de errores de validación hacen que necesariamente tu documento sea innaccesible o incompatible. Dicho ésto, deberías intentar siempre tener un código plenamente válido y tener una buena razón (tal como mejorar accesibilidad para la gente con discapacidades) para cualquier error que decidas dejar. Si las herramientas (editores de código, frameworks, editores WYSIWYG, sistemas de gestión de contenidos) que utilizas generan marcado inválido, son herramientas rotas que necesitan ser corregidas.

Para seguir leyendo

Desarrollo con estándares web 1

26 de noviembre, 2008 - por | | Desarrollo, Estándares

Roger Johansson mantiene actualizada una introducción, ya clásica, al desarrollo con estándares web en su sitio 456bereastreet.com: Developing With Web Standards – Recommendations and best practices. Con el tiempo se han ido haciendo numerosas traducciones a otros idiomas, aunque todavía no contamos con una en español. Así que voy a ir publicando aquí, en diferentes entradas, una traducción completa que, finalmente, también se encontrará en la sección de traducciones de su sitio.

Por cierto, siempre es un placer colaborar con personas tan profesionales y generosas como Roger.


Desarrollando con estándares web. Recomendaciones y buenas prácticas

1. Introducción

Este documento intenta explicar cómo y por qué el uso de estándares web te permitirá construir sitios web de un modo tal que el desarrollador ahorre tiempo y dinero, y el usuario tenga una mejor experiencia. Se discuten, también, otros métodos, guías y buenas prácticas que ayudarán a producir sitios web de alta calidad, accesibles y usables para el mayor número de personas y dispositivos posibles.

2. Historia

Cuando Internet y la Web se popularizaron en la segunda mitad de los 90, las compañías de navegadores web no habían implementado aún CSS (Cascading Style Sheets) de forma suficiente como para que los desarrolladores web tuviesen la capacidad de usarlas para controlar la presentación de un documento HTML. La falta de implementación es en cierto modo comprensible, teniendo en cuenta que la especificación para CSS Nivel 1 fue publicada en 1996, y que la correspondiente al Nivel 2 fue publicada en 1998.

La falta de soporte para CSS en los navegadores web, combinada con las demanda de los diseñadores gráficos en relación con el nivel de control que es posible cuando se trabaja con material impreso, condujeron al abuso de HTML hacia una forma de controlar la presentación visual de una página web.

Un ejemplo de ésto es la “fuga” que se produjo cuando los diseñadores descubrieron que mediante el uso del atributo border="0" para ocultar los bordes de una tabla HTML, fue creada una celda invisible que podía usarse para controlar el layout. Otro ejemplo es el uso de imágenes transparentes, por tanto invisibles, llamadas “spacer GIFs” para el control de los espaciados y los márgenes.

Puesto que HTML nunca fue ideado para controlar la presentación de un documento, fueron, y siguen siendo, utilizados hacks, código inválido y elementos y atributos específicos de algunas compañías. La validación era algo que muy poco conocían o utilizaban. Este tipo de código HTML suele denominarse sopa de tags.

A medida que se fueron publicando nuevas versiones de navegadores web, el soporte para CSS mejoró y se extendió, pero no en la proporción que debería. Sin embargo, aunque las compañías de navegadores son lentas en la implementación correcta de CSS, hemos alcanzado un punto donde los navegadores web con buen soporte para CSS están siendo utilizados por tantas personas que ya no hay razón para no utilizar el HTML en la forma en que debe ser usado: para describir la estructura y el contenido de un documento, y no su presentación. Para eso, podemos actualmente utilizar CSS, que fueron diseñadas específicamente para tal propósito.