¿Y que significa todo esto exactamente?

Sencillamente que gracias a este trocito de código podremos aplicar todas las pseudo clases y pseudo elementos para dar formato a nuestras páginas. Así conseguimos que Internet Explorer sea capaz de adoptar e interpretar todo lo necesario para acercarse un poco a un navegador que cumple los estándares.

¿En qué nos beneficia?

Pues sencillamente en que nuestros HTML serán más sencillos, por ejemplo: podremos olvidarnos de aquellas clases que indican cual es el último elemento de la lista, podremos añadir contenido directamente desde la hoja de estilos a nuestro HTML, modificar estilos según el atributo de un elemento… En definitiva todo lo que marca la W3C.

• Lista del soporte que da a MSIE

¿Y la accesibilidad?

Y, como llego tarde, ya he leído comentarios en blogs sobre la utilización de javascript y su accesibilidad. Para el número pequeño de usuarios que navegan con JavaScript desactivado, aproximadamente entre un 8% y un 6%, la página es completamente visible y funcional, no se verá de la misma manera, pero el contenido es accesible para todos los usuarios.

Ya pero… no valida

Sobre esto mejor que yo lo explica Alberto Fortes en su post: Validadores automáticos del w3c si, pero no. No podemos hablar de usabilidad, accesibilidad, diseño centrado en el usuario, personas… y luego dejar todo del lado de un validador automático que no olvidemos que es una máquina. Es decir una maquina va a evaluar si el sitio está indicado para personas. Ojo con los validadores, ojo con las herramientas automáticas de validación de la accesibilidad.

¿Quieres saber más?

• Los selectores de CSS son ya posibles en internet explorer, gracias Alberto
• JavaScript library, IE7
• Validadores automáticos del w3c si, pero no
• Accesibilidad y herramientas automáticas

En muchas ocasiones las limitaciones en el uso y opciones tipográficas de la Web hacen que por motivos de diseño necesitemos sustituir un título por una imagen. A partir de aquí siempre surge la duda de si esa imagen es presentación o contenido. Si lo consideramos contenido, la discusión está terminada. Ponemos la imagen directamente en el código mediante la etiqueta <img />.

¿Dónde está el problema?

El problema lo encontramos si lo consideramos como presentación. En este caso necesitamos de alguna técnica. Descartando, por motivos de accesibilidad, las que utilicen JavaScript o Flash.

Técnicas

La que siempre he utilizado es la conocida FIR. Esta técnica consiste en ocultar mediante CSS un elemento span contenido dentro del bloque y colocar una imagen de fondo para bloque.

Veamos un ejemplo

<!-- XHTML -->
<h1><a href=”#”><span> ¿Por qué maquetar con CSS?</span></a></h1>

/* css */
h1 a { width: 300px; height: 174px; background: url(maquetar-con-css.gif) no-repeat; display: block; color: #033D6E; }
h1 a span { display: none; }

En este caso estamos utilizando la técnica FIR, mira el ejemplo.

Inconvenientes

Accesibilidad. El texto no es leído por los lectores de pantalla, por estar oculto. Esto se podría solucionar mediante el uso de hojas de estilo independientes para cada dispositivo. Así, si se navega mediante lectores de pantalla, cargamos otra hoja de estilos y solucionado.

El problema que realmente tiene es…

¿Y si navegamos con las imágenes desactivadas?

En este caso el navegador no muestra nada, desactiva las imágenes de tu navegador y mira el ejemplo ahora.

Entonces… ¿Qué hacemos?

Bueno pues después de compartir con mis compañeros, de buscar y de leer, llegamos a la conclusión de que la mejor manera era jugar a posicionar los elementos uno sobre otro

/* css */
h1 { width: 300px; position: relative; z-index: 1; }
h1 a { width: 300px; height: 174px; background: url(maquetar-con-css.gif) no-repeat; display: block; color: #033D6E; }
h1 a span { position: absolute; z-index: -1; }

¿Que tal ahora? ¿Mejor?, mira este ejemplo ahora

Lo que estamos haciendo con esta técnica es ocultar bajo la imagen el texto del titular, siempre que la imagen no sea transparente, así para un usuario que navegue con imágenes activadas no apreciará que bajo la imagen hay texto. Sin embargo un usuario que tenga desactivadas las imágenes podrá ver el texto. Y si, además, damos formato a este texto podrá hasta verlo de una manera similar.

Ya se ha hablado de esto…

Estas y otras técnicas las encontrareis mejor explicadas en estos sitios

• Revised Image Replacement, de Dave Shea
• En limalimon.com.es, reemplazo de texto con imágenes ¿si? ¿no? ¿qué técnica usar?
• Marco Giacomuzzi de seraccesible.net, Image Replacement Accesible
• Reemplazo accesible de textos por imágenes

Y, más…

• Replacing Text By An Image, en WellStyled.com
• Desde sitepoint Accessible Header Images With CSS And XHTML

Cuando damos el salto de maquetar con tablas a maquetar con CSS, no damos importancia a la estructura de nuestro código. Los documentos creados bajo estándares deben tener un añadido de semática, aportar mas significado.

En el nacimiento de la web, HTML fue creado como un lenguaje de marcado comprensible semánticamente. Con la llegada de la web mas gráfica, mas “de presentación” este código, antes comprensible, pasó a ser algo imposible de entender. Un cúmulo de etiquetas sin sentido. Seguro que hemos visto infinidad de veces, y lamentablemente seguimos viendo cosas como:

<table width="780" cellspacing="0" cellpadding="0" border="0"><tr><td><img src="/images/0.gif" width="1" height="1" border="0"/></td></tr><tr><td background="/images/01.gif"><img src="/images/0.gif" width="1" height="1"border="0"/></td></tr></table></code>

Vuelta a los inicios

Ahora, más que desde el nacimiento de las CSS (que ha llovido) desde la utilización mas mayoritaria de ellas, podemos volver al significado semántico de nuestro código (X)HTML, posibilitando así la separación del contenido y de su presentación en pantalla o cualquier otro dispositivo.

Si además añadimos significado a nuestros documentos (X)HTML, mediante la utilización de etiquetas del lenguaje, obtendremos beneficios en accesibilidad, en posicionamiento en buscadores, en futuras actualizaciones… y para la multitud de dispositivos futuros que puedan llegar a aparecer.

(X)HTML nos da multitud de elementos con su porpio significado:

• Cabeceras, h1, h2…
• Listas, ul, ol, dl
• fieldset, legend, label
• abbr, acronym
• cite
• caption, thead, tbody
• strong y em

Al igual que en un procesador de textos, aumentamos significado mediante listas, tablas, títulos, subtítulos… Si utilizamos los mismos elementos con significado semántico, no sólo mejorará el entendimiento de nuestro documentos (X)HTML, sino que además ahorraremos código en muchas ocasiones con las ventajas que conlleva de cara al ancho de banda, buscadores, actualizaciones…

Mas elementos: id y class

Para completar el significado disponemos de elementos que nos ayudan a incluir información estructural a nuestros documentos añadiendo atributos como id o class

Un id identifica a un elemento único en el documento y class define propiedades que pueden ser aplicadas a varios elementos. Este segundo elemento es utilizado para para identificar contenido de similares características.

Nombrar ids y class

Un error semántico a la hora de dar nombre a estos elementos es aplicar nombres relacionados con la presentación. Si nombramos a una clase cajaRoja o menuArriba estamos cometiendo un error de concepto. Estamos asociando la presentación con el contenido. Y además no estamos aportando nada a la estructura.

A la hora de seleccionar nombres para nuestras clases, lo mejor es añadir un poco de contenido semántico, utilizando nombres como menuPrincipal, utilidades, mensajeError, contenidoPrincipal…

Trabaja con las herencias

Cuando empezamos a maquetar con CSS, lo primero que hacemos en nuestros (X)HTML es añadir clases e ids para todos los elementos. Una forma de limpiar nuestro código es agrupar elementos dependientes, utilizar la herencia entre clases… de esta forma bajo un mismo contenedor podemos dar estilo a todo lo que contiene.

Div y span

Son dos elementos que nos ayudan a estructurar nuestro código, pero como herencia de nuestro trabajo con tablas (los que hemos maquetado con ellas) tenemos la costumbre de añadir div y span para casi todos los grupos de elementos de nuestro documento.

Muchos elementos ya tienen información semántica suficiente para que no tengamos que incluirlos dentro de una capa contenedora, elementos como las tablas, las listas…

Si añadimos el atributo id con valor menuPrincipal a nuestra lista de opciones de menu no es necesario, además ensuciaría nuestro código, incluir esta lista dentro de un contenedor div con el id menuPrincipal.

Da un paso más

Si ya has dejado a un lado las tablas y trabajas con (X)HTML y CSS da un paso más y trabaja de una manera más semántica:

• Estructura tu código
• Utiliza correctamente las etiquetas que nos proporciona el sistema
• Evita el uso de divs innecesarios
• No nombres a las clases ni a los identificadores pensando en la presentación
• Agrupa elementos en tu CSS

Cuando trabajamos con diseños de página basados en contenedores flotados, mediante la propiedad float, nos encontramos con el problema del div contenedor, éste no se hace tan alto como los div hijos, por lo que éstos no tienen el mismo background que su contenedor principal. Lo vemos claramente cuando queremos poner un borde para poner dentro dos div hijos.

Lo vemos en el siguiente ejemplo.

• Problema al flotar los div

Lo que nosotros queremos es la capa superior contenedor rodee a sus dos hijas. Esto no ocurre porque no tiene una altura definida y como sólo contiene elementos flotados muestra su altura como 0px.

Para Microsoft Explorer basta con asignar un ancho a la capa contenedora para que sí nos muestre el borde alrededor las dos capas interiores.

Solución mediante HTML

Nuestro objetivo es hacer que esto funcione para todos los navegadores.

Hasta ahora conocía una solución que era la de incluir un elemento extra para poder “limpiar” el flujo. Un elemento con el famoso clear: both.

• Solución incluyendo código extra en nuestro HTML

Esta solución es válida pero contraria a la filosofía del diseño de páginas web mediante estándares, porque utilizamos un elemento de contenido para presentación.

Para no perder esta filosofía podíamos introducir la nueva clase en otro elemento que fuese más correcto como un salto de línea o una línea de separación.

Esto tiene que ser así mientras Internet Explorer no acepte la seudo clase after.

Otra solución

Alex Walker nos ofrecía otra solución más simple mediante la utilización de la propiedad overflow.

Esta propiedad controla que el contenido de un div no desborde al div contenedor.

• Solución utilizando la propiedad overflow

Asignando el valor auto a la propiedad overflow, el contenedor se hará tan alto como el de su contenido, para que esta propiedad funcione correctamente en Internet Explorer debemos asignar un ancho al contenedor.

La propiedad overflow

Puede tener 4 valores: visible, hidden, scroll y auto.

El valor que toma por defecto es visible, scroll mostrará las barras de scroll para la capa contenedora siempre, auto sólo las mostrará en el caso en que el contenido sea mayor que un ancho o alto especificado en la contenedora, y hidden ocultará las barras de scroll siempre.

Algunos navegadores como Internet Explorer necesitarán que especifiquemos un ancho o un alto, tal y como lo hemos puesto en el ejemplo.

Para el Explorer Mac debemos utilizar el valor hidden, así no mostrará las barras de scroll.

• Una solución para Mac

Referencias

Este método no es ni nuevo, ni mío, pero he considerado interesante dejarlo por escrito aquí, así espero que os sirva. Las referencias donde encontrareis más, y mejor, información son estas.

• Overflow and clipping
• Clearing floats
• Simple Clearing of Floats