Armonía | En definitiva...

Esto es una traducción de un artículo escrito por Dave Shea.

---

Sin duda alguna seguro que te has encontrado con un montón de problemas extraños cuando has tratado de crear un sitio Web usando CSS. Habrás terminado dándote cabezazos contra la pared una y otra vez. Este documento es un intento de hacer el proceso de diseño más sencillo, y tener una referencia rápida para ojear cuando tengas algún problema.

Si tienes algo que añadir al texto, por favor coméntalo aquí.

Existen traducciones disponibles en los siguientes idiomas: Francés, Alemán, Holandés, Italiano, Húngaro, Finlandés, Ruso, Portugués, Japonés y Chino simplificado. Eres libre de traducirlo a otros idiomas.

Cuando dudes, valida.

Cuando hagas pruebas, puedes ahorrarte muchos dolores de cabeza simplemente validando tu código primero. Código XHTML/CSS mal escrito puede acabar en un montón de problemas con tu layout.

Crea y prueba tu CSS en el navegador disponible más avanzado antes de probarlo en otros, no después.

Si creas un sitio Web probando en un navegador "roto", tu código se basará en los problemas de ese navegador. Cuando sea hora de probarlo en un navegador mejor adaptado a los estándares, te frustrará ver que todo se dibuja de forma incorrecta. En lugar de eso, empieza desde la perfección de un buen navegador, y luego haz las mejoras para los navegadores menos capaces. Tu código será más estándar desde el principio, y no tendrás que hacer muchos "hacks" para soportar otros navegadores. Hoy día, los mejores navegadores son Mozilla, Safari u Opera.

Cuando uses float en tu layout, asegúrate de limpiarlos correctamente.

Los float son especiales, y no siempre se comportan como esperas. Si te encuentras con que un elemento flotado se sale del elemento contenedor, o simplemente no se comporta como esperas, asegúrate de que lo que quieres es correcto. Échale un ojo al tutorial de Eric Meyer acerca de este problema.

Márgenes colapsados; Aplica padding o un borde para evitarlo.

Puedes pelearte con un espacio en blanco de más donde no lo quieres, o con nada de espacio donde quieres que haya algo. Si estás usando márgenes para ello, su colapsamiento será probablemente el culpable. Andy Budd lo explica a la perfección.

Trata de evitar darle padding o bordes y un ancho fijo a un elemento.

IE5 interpreta incorrectamente el modelo de cajas de CSS, lo que acarrea un montón de problemas con muchas cosas. Hay muchos modos de "rodear" el problema, pero es mucho mejor evitarlo del todo dándole el padding al elemento padre en lugar de al hijo que tiene el ancho fijo.

Evita el "Flash of Unstyled Content" en Internet Explorer.

Si usas @import para tus hojas de estilo externas, más tarde o más tempranos notarás cómo IE muestra un "flash" de la página sin formato antes de aplicar el CSS. Esto puede evitarse.

No uses min-width en IE.

Este atributo no es soportado por IE. Pero sí que trata width como min-width hasta cierto punto, así que con un poco de filtrado, puedes obtener el mismo resultado.

Cuando dudes, disminuye el ancho

Algunas veces los errores en el redondeo causarán cosas como que 50% + 50% sea igual a 100.1%, lo que termina rompiendo la maquetación en algunos navegadores. Trata de cambiar 50% por 49%, o incluso 49.9%.

¿El contenido no se muestra correctamente en IE?

Puede que estés sufriendo el bug Peekaboo, especialmente si se muestra cuando pasamos por encima de un enlace con el ratón. Mira en Position is Everything para una solución.

Ten cuidado al estilizar los enlaces si usas anclas internas.

Si usas anclas internas en tu código, (<a name="ancla">), te darás cuenta de que le afectan las pseudoclases :hover y :active. Para evitar esto, lo mejor es que uses id para las anclas, o estilizar con otra sintaxis ligeramente distinta: :link:hover, :link:active

Asegúrate de que el efecto que deseas existe en realidad.

Hay algunas extensiones propietarias de CSS que no están en la especificación oficial. Si estás tratando de aplicar filter o estilos a las barras de desplazamiento, estarás trabajando con código propietario que no funcionará en ningún navegador salvo en IE. Si el validador te dice que el código que estás usando no está definido, lo más probable es que sea propietario, y no funcione de forma consistente entre navegadores.

Divide y conquista: usa los comentarios para desactivar grandes secciones de estilos.

Especialmente útil cuando trabajamos con grandes y desconocidas hojas de estilos. Comenta la mitad del código. Si el problema aún ocurre, significa que está en la otra mitad. Comenta lo que queda y prueba de nuevo. Si el problema deja de ocurrir, está en la sección comentada. Refina el ámbito de los comentarios y prueba de nuevo. Continua hasta que el problema haya sido identificado.

Recuerda “LoVe/HAte” en los enlaces.

Cuando especifiques las pseudoclases para los enlaces, siempre recuerda este orden: Link, Visited, Hover, Active. Otro orden no funcionará de forma consistente. Considera el uso de :focus también, y modifica el orden por LVHFA, (o “Lord Vader's Handle Formerly Anakin”, tal y como sugiere Matt Haughey)

Recuerda “TRouBLEd” para los bordes.

La forma corta, (shorthand), de aplicar los estilos para bordes, márgenes y padding tiene un orden específico: en el sentido de las agujas del reloj empezando por arriba, o Arriba, Derecha, Abajo, Izquierda. Por tanto, margin: 0 1px 3px 5px; resulta en que no hay márgen por arriba, 1 píxel de márgen a la derecha, etc.

Especifica unidades para todos los valores que no sean cero.

CSS requiere que especifiques unidades en todas los valores como fuentes, márgenes, tamaños, etc. (con la excepción de line-height, que da la posibilidad de no usarla). Cero es cero siempre, sean píxeles, em, o cualquier otra cosa, no hace falta especificarle la unidad. Ejemplo: padding: 0 2px 0 1em;

Prueba diferentes tamaños de fuente.

Navegadores avanzados, como Mozilla u Opera, permiten redimensionar el tamaño de la fuente, no importa la unidad que uses. Algunos usuarios tendrán el tamaño de fuente del navegador definido más grande o más pequeño que el que tengas tú. Intenta acomodar tu diseño al rango más amplio posible.

Haz que las mayúsculas y las minúsculas concuerden entre tu HTML y tu CSS

Algunos navegadores son sensibles al cambio entre minúsculas y mayúsculas. Usar una clase como homePage está bien, siempre que seas consistente en el uso de la notación especificada. Aplicarle estilos a homepage causará problemas en algunos agentes de usuario estrictos, (como Mozilla).

Prueba embebido; lanza importado.

Si trabajas con estilos embebidos en el código HTML eliminas cualquier potencial posibilidad de errores de cacheo mientras pruebas. Esto es muy importante cuando trabajamos con algunos navegadores de Mac. Pero asegúrate de que cambias los estilos a una hoja externa, importada con @import o colocada con link antes de lanzar la Web

Añade bordes obvios para ayudar a encontrar fallos en la maquetación.

Una regla universal como div {border: solid 1px #f00;} puede ser un camino largo para encontrar errores en la maquetación. Pero colocar un borde específico a un elemento en concreto ayudará a identificar posibles problemas que pueden no resultar obvios de ningún otro modo.

No uses comillas en las rutas de las imágenes.

Cuando uses una imagen de fondo, evita colocar la ruta entre comillas. No son necesarias, y IE5/Mac tiene problemas con ellas.

No enlaces a hojas de estilo vacías colocadas con vistas de futuro, (para estilos de impresión, etc.)

IE5/Mac tiene problemas con las hojas de estilo en blanco, y el tiempo de carga de la página será mayor. En su lugar, coloca al menos una regla, o incluso un comentario, en la hoja de estilos para que este navegador no de problemas.

Además, hay otros elementos que se aplican específicamente al lado funcional de las cosas, pero se deberían tener en cuenta cuando desarrollemos:

Organiza tus archivos CSS

Asegúrate de comentar tus bloques de CSS de manera apropiada, agrupando selectores relacionados, y estableciendo unas reglas a la hora de nombrar las clases y los identificadores, los espacios en blanco y el indentado, (recomendación: usa un espacio simple en lugar de tabulación para evitar problemas multiplataforma), y un orden en las propiedades.

Nombra las clases y los identificadores por su función y no por su aspecto

Si creas una clase .azulgrande, y más tarde te piden que cambies el texto por pequeño y rojo, esa clase deja de tener sentido. En su lugar usa clases descriptivas, como .copyright o .comentario.

Confía en los filtros CSS solo como última opción.

Los hacks y los filtros CSS pueden ayudarte a aplicar, o no aplicar, estilos CSS de forma selectiva a varios elementos. En lugar de usarlos cada vez que encuentres un problema, encuentra la forma de aplicar el mismo efecto de una manera más "cross-browser", (para todos los navegadores). Aquí hay una gran lista de filtros CSS.

Combina selectores.

Mantener tu CSS ligero es muy importante para minimizar el tiempo de descarga; siempre que puedas, trata de agrupar selectores , usar las herencias, y minimizar la redundancia usando métodos cortos, (shorthand).

Ten en cuenta la accesibilidad cuando uses el reemplazamiento por imágenes

La técnica FIR tiene algunos problemas con los lectores de pantalla, y con aquellos que tienen las imágenes desactivadas. Existen alternativas; usa la más adecuada.

Si alguna vez has tratado de jugar con el CSS al hacer una página Web, te habrás dado cuenta de lo increíblemente potente que es. Pero seguro que también habrás notado otra cosa: que Internet Explorer hace lo que le da la gana. ¿Me equivoco?

Pues bien, si alguna vez has sentido la frustración correr por tus venas debido a que tu maquetación no se ve como debe, o a que el elemento que acabas de dejar tan bonito se va al garete cuando compruebas tu creación en ese navegador, deberías intentar tener en cuenta y tratar de comprender lo que os voy a contar a continuación.

Cuando algo te falle en Internet Explorer, recuerda esta palabra: hasLayout, o simplemente layout. ¿Y por qué tienes que recordar esta palabra? Porque es la base de muchos de los problemas de Internet Explorer con el CSS. Pero antes de seguir con todo esto, ¿qué diablos es el hasLayout?

Nuestro querido Microsoft, con su gran manera de hacer las cosas, creó una especie de propiedad interna que determina cómo se dibujan los elementos (X)HTML en la ventana del navegador, (Internet Explorer), cómo interactuan con los demás, cómo reaccionan ante determinados eventos, etc. Esta propiedad es nuestro famoso hasLayout. Se entiende esta propiedad como una propiedad de tipo boolean, es decir, que puede tener dos valores, true, o false. Algunos elementos tienen el hasLayout en true por defecto, esto quiere decir que tienen layout, mientras que otros no. Y ahora algo importante, se le puede dar layout a los elementos que no lo tienen mediante algunas propiedades CSS.

Como hemos dicho, el hasLayout es la base de mucho de los problemas de Internet Explorer, por lo que es importante conocerlo y saber cómo darle layout a un elemento, saber si lo tiene por defecto, etc.

Como ya he dicho, existen una serie de elementos que tienen layout por defecto. Estos elementos son:

• <html>, <body>
• <hr>
• <img>
• <table>, <tr>, <th>, <td>
• <marquee>
• <input>, <textarea>, <select>, <button>
• <iframe>, <applet>, <embed>, <object>

El resto de elementos (X)HTML de los que disponemos, por defecto no tienen layout, pero podemos hacer que lo tenga aplicándole alguna de las propiedades CSS que comento a continuación:

float:left; o float:right;

Bien conocidos son ya los bugs de Internet Explorer con respecto a los elementos flotados

position: absolute;

Con este tipo de posicionamiento, el elemento al que se la apliquemos ganará layout

width o height

Cualquier valor dado a estas propiedades hará que el elemento tenga layout

display: inline-block;

Muy útil cuando queremos darle layout a un elemento en línea

zoom con cualquier valor, o writing-mode: tb-rl;

Ambas son propiedades propietarias de Microsoft, así que si queréis usarlas, tened en cuenta que no validarán

Después de repasar todo esto, mi consejo es el siguiente: cuando tengáis algún problema con vuestro CSS en Internet Explorer, tratad de darle layout al elemento que os está fallando, (un height:1%; para ese elemento en vuestra hoja de estilos para Internet Explorer colocada usando comentarios condicionales puede hacer maravillas). Y en el caso de que el elemento que falla tenga layout porque le habéis colocado una propiedad CSS que se la otorga, tratad de quitársela y conseguir el mismo efecto CSS mediante otros métodos.

Si después de probar esto la cosa sigue dando problemas, entonces podéis pasar a buscar algún hack específico o cualquier cosa de estas. Pero no perdéis nada por probar antes lo del hasLayout, y os puede sacar de más de un aprieto.

Por cierto, si queréis leer más sobre el hasLayout de Internet Explorer, no olvidéis pasar por el artículo On Having Layout: The concept of hasLayout in IE/Win, el mejor recurso que he podido encontrar para comprender esta curiosa propiedad, "madre" de la mayoría de problemas de CSS en Internet Explorer.

Gracias a una de las listas de correo a las que estoy suscrito, (no recuerdo el mensaje ni la lista, ando algo despistado), he llegado a un texto de Eric Meyer donde habla sobre la posibilidad de no incluir unidades de medida en la propiedad CSS line-height.

En el texto se comenta que según la especificación de CSS 2.1, a la propiedad line-height no es necesario especificarle una unidad de medida concreta, (em, px, o cualquier otra). De hecho, según Eric Meyer, la mejor opción es no ponerla, y dejar que tome la unidad de la propiedad font-size del elemento, ya esté especificada exlícitamente o sea heredada.

ul {font-size: 15px; line-height: 1;}
li {font-size: 10px;} /* Tomará como line-height 10px */
small {font-size: 80%; line-height: 8px;} /* Tomará como line-height 8px */

El único problema de todo esto es que por algún motivo u otro, el validador del W3C no acepta valores sin unidad de medida, aunque la especificación lo permita para line-height.

A estas alturas no sé de qué me extraño, ya existe un hack para IE7. No sé yo si buscar hacks para un navegador que aún no ha salido, y que supuestamente va a tener una mejor integración con los estándares, es la mejor opción de entre todas las posibles. Quizá lo mejor hubiera sido notificarlo a Microsoft, y que se encarguen de solucionarlo. Quiero pensar que mejorar su producto es la meta de Microsoft para Internet Explorer 7.

Sea como sea, el hack consiste en el uso de un selector que IE7 no soporta, el selector de negación:

p.prueba {
  background:#fff;
  color:#000;}

p[id$="prueba"]:not([class="xxx"]) {
  background:#000;
  color:#fff;}

Este CSS se aplicará al siguiente XHTML:

<p class="prueba" id="prueba">
  Este texto tendrá fondo negro y el texto en blanco si la regla se aplica,
  pero IE7 no la aplicará porque no soporta el selector de negación, así
  que se quedará con la regla anterior, mostrando el texto en negro y
  el fondo en blanco
</p>

Revisando hoy mis feeds con mi lector local favorito, NewsFire, he encontrado un par de lecturas interesantes, y no me gustaría que os las perdierais:

• Mostrando la forma extendida de una abreviatura, en 5.1.1
• CSS 3 selectors explained, en 456BereaStreet

Una parte muy a tener en cuenta a la hora de desarrollar nuestras aplicaciones Web son los formularios. Estos han de ser simples, consistentes, comprensibles, accesibles, etc. En este artículo de hoy voy a enseñaros la forma en la que suelo hacer mis formularios, y los motivos por los que he elegido determinados detalles que acostumbro a usar.

Para hacer más sencilla la comprensión de todo esto he creado un sencillo ejemplo con un mismo formulario dividido en tres estados distintos, donde cada uno de ellos muestra una etapa de la "vida de un formulario".

Primera etapa: Formulario en estado normal

La primera etapa de todo formulario es aquella en la que nos lo encontramos por primera vez, impoluto, limpio completamente, esperando ser cumplimentado y enviado.

Es una etapa muy importante, ya que debemos conseguir que de un simple vistazo el formulario sea comprensible para el usuario. Y por si fuera poco, hemos de usar nuestro lenguaje de marcado favorito de forma correcta, preocupándonos además por la accesibilidad del formulario.

Hay diversas cosas que suelo realizar siempre que hago un formulario. Una de ellas es englobarlo con el elemento fieldset con un atributo title bien descriptivo, y colocándole su correspondiente legend:

<fieldset title="Formulario general en estado normal que realiza una función determinada">
  <legend>Formulario general en estado normal</legend>
</fieldset>

Otra cosa imprescindible es el uso de los label. A todos los controles del formulario, salvo a los botones, les coloco su label correspondiente. Debo destacar que normalmente acostumbro a englobar todo el control con el label además de usar el atributo for de este, me explico:

<label for="cajaTexto1">Caja de Texto 1 <span class="obligatorio">(Obligatorio)</span><br />
  <input type="text" id="cajaTexto1" name="cajaTexto1" maxlength="255" title="Caja de Texto. (Campo obligatorio, con un límite de 255 caracteres.)" />
</label>

Como podeis ver, toda la caja de texto se encuentra englobada dentro de un label, y este a su vez hace uso del atributo for para referenciar a la caja de texto. Hay personas que sólo hacen uso del atributo for, pero hay algunos agentes de usuario que todavía no soportan esta forma de referenciación, así que procuramos mantener ambas formas para evitar incompatibilidades.

Si os fijais, la caja de texto usa el atributo maxlength, que nos permite limitar el número de caracteres que van a poder introducirse en ella. Si se conoce este límite, es más que recomendable hacer uso de este atributo, para ahorrarnos sustos si, por ejemplo, los datos van a guardarse en una Base de Datos y al usuario le da por meter un capítulo entero de El Quijote.

Además también es recomendable dotar a todos y cada uno de los controles del formulario del atributo title, explicando brevemente qué se debe hacer en ese control, y si es posible, informar de las limitaciones: obligatorio o no, tipos de datos que acepta, (sólo números, sólo letras, etc.) Con respecto a este mismo tema, en el texto del label, y para que el usuario tenga acceso a esta información a golpe de vista, suelo añadir también de forma muy breve, las limitaciones del campo. Las englobo en un span para poder manejarlas posteriormente de forma sencilla con CSS.

Por destacar otro detalle, en el ejemplo podéis ver que en el desplegable hago uso de optgroup para dividir los grupos de elementos que componen el control. Es importante que useis este elemento si vuestros desplegables necesitan subdividir en grupos los elementos, nada de usar option con guiones ni nada de eso.

<label for="combo">Desplegable <span class="obligatorio">(Obligatorio)</span><br />
  <select id="combo" name="combo" title="Desplegable con 5 opciones divididas en 2 grupos. (Obligatorio elegir una opción)">
    <optgroup label="Grupo 1">
      <option selected="selected" value="1">Opción 1</option>
      <option value="2">Opción 2</option>
    </optgroup>
    <optgroup label="Grupo 2">
      <option value="3">Opción 3</option>
      <option value="4">Opción 4</option>
      <option value="5">Opción 5</option>
    </optgroup>
  </select>
</label>

Ver ejemplo para el formulario en estado normal

Segunda etapa: Formulario con mensajes de error

Esta etapa, obviamente, no siempre va a ocurrir, pero debemos tener especial cuidado a la hora de controlarla, porque un formulario con mensajes de error poco claros, e incluso liosos o inexistentes, hará que todo el proceso se vaya al garete.

Mis formularios suelen tener tres formas de aviso distintas para los errores:

• Mensaje general con una lista de puntos a comprobar
• Estilos CSS distintos en los controles incorrectos
• Mensaje informativo breve junto a cada control incorrecto

Todos estos mensajes han de destacar de forma muy clara por encima del aspecto normal del formulario, para que así el usuario pueda localizarlos y comprenderlos sin el menor esfuerzo.

Si observais el ejemplo, lo podreis ver claramente. Tonos rojos para todos los mensajes, un grosor de borde significativo para los controles incorrectos, y un pequeño texto junto a cada uno de ellos.

Mirando el código del mensaje general justo al comienzo del fieldset os dareis cuenta de que he usado el elemento big con un span interno que contiene un texto llamativo que luego oculto con CSS. Esto lo hago pensando en los usuarios que no tienen los estilos CSS activados. Puesto que no se percataran de los estilos con tonos rojos y demás, les doy un elemento "distinto" y un texto impactante para que su atención se centre sobre el mensaje de forma más sencilla.

<div class="mensaje error">
  <p><big><span>*** !ATENCIÓN!</span> Encabezado error</big></p>
  <p>Etiam porta semper nisl. Aenean lacus risus, condimentum id, pharetra in, dictum vel, quam. Maecenas non mauris ut dolor cursus dignissim.</p>
  <ul title="Lista de puntos a verificar">
    <li>Debes rellenar el campo obligatorio "Caja de Texto 1"</li>
    <li>El campo "Caja de Texto 2" no tiene un formato correcto. Sólo se aceptan caracteres alfanuméricos</li>
  </ul>
  <hr />
</div>

Ver ejemplo para el formulario con mensajes de error

Tercera etapa: Formulario ejecutado de forma satisfactoria

Esta es una etapa meramente informativa, y no es absolutamente necesario, ya que un formulario puede terminar con una redirección a otra página, con un mensaje simple porque no se necesite tener el formulario de nuevo, etc.

De todas formas la estructura es exactamente igual que la del mensaje general de errores de la etapa anterior, salvo que con unos estilos distintos en tonos "menos preocupantes" que el rojo. También, del mismo modo que antes, pienso en los usuarios con CSS desactivado colocando un mensaje llamativo que capte su atención incluso sin estilos.

Ver ejemplo para el formulario ejecutado satisfactoriamente

Hace algunas semanas se comenzó a discutir en la lista de correo del grupo AccesoWeb del SIDAR sobre cómo se debe marcar de forma semántica y correcta un poema, o una canción, con XHTML. Se vertieron muchas opiniones, todas muy interesantes, pero bajo mi punto de vista, y desde el de otros tantos en la lista, la forma correcta sería la que voy a explicar a continuación.

Normalmente, un poema o una canción se componen de estrofas, y cada una de estas estrofas está formada por uno o varios versos. En XHTML no existe ningún elemento que se encargue explícitamente de marcar este tipo de textos, por lo que habría que recurrir a elementos existentes para conseguir un marcado correcto y semántico, y además, que sea accesible. Ahora bien, ¿qué elementos son los correctos?

Bajo mi punto de vista, se puede considerar cada estrofa de un poema, o de una canción, como un párrafo normal de texto, con la salvedad de que las lineas están "partidas", no son contínuas. Una de las opciones contrarias al uso del elemento p para marcar las estrofas era usar el elemento pre, y escribir el poema tal y como se quiere que aparezca. Para mí esto no es una opción válida, ya que no se le da al poema un marcado semántico adecuado, se obvian los párrafos, etc.

A raiz de la sugerencia de usar pre, alguien apuntó el uso de párrafos, pero añadiendo la propiedad CSS white-space con el valor pre para "imitar" el resultado del elemento pre, pero sin usarlo. Desgraciadamente esta opción tampoco me parece correcta. Un usuario con CSS desactivado no podría comprender que lo que esta leyendo es un poema, ya que los versos desaparecerían y solo vería párrafos.

Para mí, la mejor opción es usar párrafos para marcar las estrofas, y saltos de línea para separar los versos. Parece un poco contradictorio, porque el elemento br suele estar desaconsejado cuando hablamos de XHTML y demás, pero creo que en este caso hemos encontrado una situación en la que es, además de correcto, aconsejable usarlo.

Usando esta forma, nos aseguramos de que los usuarios con CSS desactivado puedan leer correctamente el poema. Pero se nos plantea otro problema, ¿qué ocurre con los lectores de pantalla? ¿Cómo leerian el poema estos lectores? Es ahora cuando saltan a la palestra una serie de propiedades CSS normalmente desconocidas para la gran mayoría: los estilos aurales.

Estos estilos sirven para controlar la forma en la que los lectores de pantalla van a leer nuestro documento. Desde las pausas, hasta la velocidad, pasando por el tono, etc. Desgraciadamente muy pocos lectores de pantallan soportan este tipo de estilos. Aún así es algo que está ahí, y que hay que aprovechar, puesto que es importante.

Teniendo en cuenta todo lo comentado, y siempre según mi punto de vista, la forma más correcta para marcar un poema sería la siguiente:

<p>Siempre nos piden que entendamos<br />
el punto de vista de los otros,<br />
sin importar si es anticuado,<br />
necio,<br />
asqueroso.</p>

<p>A uno le piden<br />
que entienda<br class="pausa" />
amablemente<br class="pausa" />
todos los errores de los otros,<br />
sus vidas desperdiciadas,<br />
sobre todo si son de edad avanzada.</p>

<p>Pero su edad es lo único<br />
en lo que nos fijamos.<br />
Han envejecido mal<br class="pausa" />
porque han vivido sin enfoque,<br />
se han negado a ver.<br />
¿Que no es culpa suya?</p>

<p>Se me pide que oculte<br />
mi opinión ante ellos<br class="pausa" />
por miedo a su miedo.</p>

<p>La edad no es un crimen,<br />
pero la vergüenza de una vida<br />
deliberadamente desperdiciada<br />
entre tantas vidas,<br />
deliberadamente desperdiciadas,<br  class="pausa" />
sí lo es.</p>

Siendo su CSS:

.pausa {pause-after:700ms;}

Como veis, hago uso de un estilo CSS con la propiedad pause-after asociado a algunos elementos br del marcado del poema para determinar una pequeña pausa al final de ese verso. Obviamente esto es muy personal, y según como interpretemos que debe ser la lectura del poema, tendremos que jugar con más propiedades aurales de CSS, como pitch, volume, etc.

Por cierto, el poema es de Charles Bukowsky, y se titula "Siempre nos piden que entendamos...":

Siempre nos piden que entendamos
el punto de vista de los otros,
sin importar si es anticuado,
necio,
asqueroso.

A uno le piden
que entienda
amablemente
todos los errores de los otros,
sus vidas desperdiciadas,
sobre todo si son de edad avanzada.

Pero su edad es lo único
en lo que nos fijamos.
Han envejecido mal
porque han vivido sin enfoque,
se han negado a ver.
¿Que no es culpa suya?

Se me pide que oculte
mi opinión ante ellos
por miedo a su miedo.

La edad no es un crimen,
pero la vergüenza de una vida
deliberadamente desperdiciada
entre tantas vidas,
deliberadamente desperdiciadas,
sí lo es.

Navegando por ahí me he topado con un artículo excelente y muy completo sobre cómo funcionan la opacidad y las transparencias en CSS.

Un aspecto del CSS que no creo que esté todavía maduro para usar, pero siempre viene bien investigar, comprobar, hacer experimentos, etc. Es la mejor forma de aprender.

Observando el nuevo fichero CSS que he creado para esta nueva versión con DotClear del blog, me doy cuenta de dos pequeños detalles que la hoja de estilos anterior no tenía.

El primero de ellos es la forma de estructurar los estilos. Para esta hoja de estilos he optado por usar la llamada estructuración por flags, la leí por primera vez en Stopdesign, aunque posteriormente la he visto comentada en multitud de blogs. Consiste, básicamente, en agrupar los estilos según la zona del documento a la que se apliquen, por ejemplo:

• Cabecera
• Lateral
• Cuerpo
• Pie

Para tener un acceso rápido a cada una de estas zonas, con la estructuración por flags lo que se hace es colocar un nombre al comienzo de cada zona, un nombre fácil de recordar, corto, y que podamos buscar de forma única en nuestro documento. Viendo un ejemplo se entiende mejor:

/*
 * =Cab
 * * * * * * * * * * */
#cabecera {color:red;}

/*
 * =Lat
 * * * * * * * * * * */
#lateral {color:blue;}

/* Etcétera */

Si os dais cuenta, colocamos el símbolo "=" en el identificador de cada sección, para que a la hora de hacer la búsqueda, nos evitemos que aparezca cualquier otro resultado en el resto de la hoja de estilos.

El otro detalle que he añadido a la hoja de estilos es el uso de la pseudo clase :focus en los enlaces. Hasta ahora sólo había utilizado esta pseudo clase en los elementos de los formularios, pero probando la navegación mediante teclado en mi blog, (para comprobar si era accesible o no), me dí cuenta de que cuando tabulaba por los enlaces no se destacaba cual era el que estaba seleccionado. Así que decidí añadirles esta pseudo clase aplicándoles los mismos efectos que con el :hover.

Creo que estas dos son buenas prácticas a tener en cuenta a la hora de realizar nuestras hojas de estilos. Al menos a mí me han dejado contento.

CSS tiene infinidad de características que lo hacen muy útil para todo aquel que quiera aplicar estilos a sus documentos HTML o XHTML. Para ejemplificar la profundidad de estas características voy a hablaros de dos tipos de selectores, clasificados dentro de los llamados pseudo-elementos. Los pseudo-elementos que voy a comentar son :first-line y :first-letter.

Son dos tipos de selectores muy simples, y que nos permiten aplicar estilos a unas determinadas partes de las etiquetas a las que se los apliquemos. Como vais a poder comprobar, son muy muy específicos, ya que, comparados con lo habitual, que es aplicar estilos a determinadas etiquetas, o a determinada clase, etc. esto va un poco más allá

Vamos a comenzar con first-line. Este pseudo-elemento nos va a permitir aplicar estilos únicamente a la primera linea de texto del elemento en bloque al que se lo coloquemos. Es más fácil de lo que parece. Imaginemos que vamos a escribir un párrafo, por ejemplo del último libro que me estoy leyendo. Y queremos que la primera linea de ese párrafo, se muestre en rojo. Pues para está first-line. La forma con truco de hacerlo hubiera sido controlando el ancho del párrafo, mirando cual es la primera linea, y con un span, por ejemplo, aplicar los estilos para que aparezca rojo. Con first-line nos ahorramos todo eso. Veamos el ejemplo:

p:first-line{color:red;}

<p>Fue entonces cuando se produjo lo increíble. Sin cambiar lo más mínimo su postura perfectamente protocolaria, la mujer, de pronto, abrió el escote de su kimono.</p>

El resultado sería, (por favor, haced caso del código de arriba, no del código interno de este blog):

Fue entonces cuando se produjo lo increíble. Sin cambiar lo más mínimo su postura perfectamente protocolaria, la mujer, de pronto, abrió el escote de su kimono.

Si usais un navegador que respete los estándares del World Wide Web Consortium, (Internet Explorer no), podreis ver que la primera linea del párrafo está coloreada de rojo.

Hay que decir que el pseudo-elemento :first-line solo puede aplicarse a elementos en bloque, elementos de tipo inline-block, al elemento caption de una tabla, y a las celdas de las tablas.

El otro pseudo-elemento del que quería hablaros es :first-letter, que, como podreis deducir, nos permite aplicar estilos a la primera letra del elemento al que se lo coloquemos. Siguiendo con el ejemplo anterior, podemos hacer que la primera letra del párrafo aparezca más grande, al estilo tipográfico.

p:first-letter{font-size:3em;font-weight:bold;}

Y el resultado sería, (de nuevo, por favor, haced caso del código de ejemplo que pongo, y no del código interno del blog):

Fue entonces cuando se produjo lo increíble. Sin cambiar lo más mínimo su postura perfectamente protocolaria, la mujer, de pronto, abrió el escote de su kimono.

Este pseudo-elemento tampoco podrá ser visto en navegadores que no respeten los estándares. Y solo se podrá aplicar a elementos en bloque, items de listas, celdas y caption de tablas y elementos de tipo inline-block.