background-origin

Determina el origen a partir de donde se calcula posición del fondo, es decir, el origen de coordenadas para la propiedad background-position. Sus posibles valores son:

• border-box: la posición del fondo se determina respecto al área que incluye el borde (traducido significa que si el borde es discontinuo, el fondo se podrá llegar a ver por debajo de él).
• padding-box: es el valor por defecto y determina la posición del fondo respecto al área que incluye el padding (equivalente a la actual en CSS 2.1).
• content-box: el fondo se posiciona respecto al área de contenido.

background-clip

Determina el área en el que se mostrará el fondo y admite dos posibles valores:

• border-box: es el valor por defecto e incluye el fondo en el área ocupada por el borde.
• padding-box: limita el área en la que se mostrará el fondo a la ocupada por el padding y el contenido, es decir, aunque el origen del fondo esté en el borde, no se mostrará la imagen por debajo de este.

La explicación

Como siempre, lo mejor es acudir a los ejemplos en forma de capturas para explicar ambas propiedades. En ellos he simulado el espacio ocupado por un elemento (respetando el modelo de cajas), es decir, borde (punteado gris grueso), padding (espacio entre el borde y la delgada línea discontinua) y contenido (delimitado por la línea discontinua). Empecemos:

¿Cuál es la diferencia entre el siguiente par de imágenes?

Resulta evidente que la diferencia entre ambas está en que en una se muestra el fondo por debajo del borde, mientras que en la otra no. La CSS de la primera es:

background-origin: border-box;
background-clip: border-box;

…y para la segunda:

background-origin: border-box;
background-clip: padding-box;

Y ahora, ¿entre las siguientes imágenes?

Ahora la diferencia está en el origen del fondo. En la primera, el origen incluye el borde:

background-origin: border-box;

…mientras que en la segunda estaría en el padding:

background-origin: padding-box;

Finalmente, ¿cuál es la diferencia ahora?:

Nuevamente está claro. La primera imagen, al igual que la primera en el par de ejemplos anteriores, tiene como origen del fondo el área del borde, mientras que la segunda tiene dicho origen en el área de contenido:

background-origin: border-box;

y

background-origin: content-box;

Si tu navegador es una versión reciente de Firefox, Chrome, Safari o Konqueror, puedes acceder a la página con un ejemplo de aplicación de ambas propiedades. Si utilizas algún otro (por ejemplo, Internet Explorer u Opera) también puedes acceder al ejemplo, aunque en este caso será para ver el resultado cuando no se soportan estas propiedades.

nota: Mozilla y WebKit soportan estas propiedades de forma experimental con sus sintaxis particulares.

Como ya expliqué en otro artículo, con CSS 3 podremos incluir más de una imagen de fondo. Las propiedades background-origin y background-clip admiten la inclusión de un valor para cada una de las imágenes que se utilicen.

Para terminar, nuevamente comentaré algo respecto a la imagen empleada de fondo en los ejemplos. Es una deliciosa tarta de frutas que hizo Dolores y que me gané por bueno… vale, que me gané a secas… bueno, no me la gané, pero la disfruté como un niño

First of all, the demo page of fish eye menu (remember that only works in Chrome, Safari and Firefox. FF has not transtion property support).

The HTML code:

<ul>
    <li><a href="#"><img src="icons/opera_100.png" alt="opera browser" width="50"/></a></li>
    <li><a href="#"><img src="icons/camino_100.png" alt="camino" width="50"/></a></li>
    <li><a href="#"><img src="icons/chrome_100.png" alt="chrome" width="50"/></a></li>
        .
        .
        .
</ul>

And the CSS code (the top fish eye menu in the example). At the first, the style to display all items inline with a bit of css:

ul,li {
    margin: 0;
    padding: 0;
}
ul {
    text-align: center;
}
li {
    display: inline;
}

And now, the transform and transition properties to obtain the effect:

a:hover, a:focus {
    z-index: 200;
      /* bring to top when the mouse is over or
         when it has the focus (for keyboard navigation) */
}
a img {
    border: none;
    -webkit-transition: all .2s;
       /* in Safari, every animatable property
          triggers an animation in .2s */
    -webkit-transform-origin: top;
       /* in Safari, the origin for
          transformation */
    -moz-transform-origin: top;
       /* in Firefox, the origin for
          transformation */
}
a:hover img, a:focus img {
    -webkit-transform: scale(2);
    -moz-transform: scale(2);
       /* transform property (for Safari and Firefox) */
}

The following article will come… soon…

A partir de ello he preparado la siguiente tabla:

…y por supuesto, la forma shorthand:

background: [ <bg-image> || <bg-position> || / <bg-size> || <repeat-style> || <attachment> || <bg-origin> , ]* <bg-image> || <bg-position> || / <bg-size> || <repeat-style> || <attachment> || <bg-origin> || <’background-color’>

Algunas de las propiedades comienzan a tener soporte en las versiones más actuales de los navegadores (como ya mencioné en la entrada titulada Multiples imágenes de fondo con CSS 3), incluyéndose en algunos casos de forma experimental (por ejemplo en Firefox mediante el prefijo -moz).

nota: Os recuerdo que ninguna de las propiedades se hereda.

En breve, para dejar niquelao el tema y comprender claramente lo que podemos llegar a conseguir modificando las propiedades de fondo, explicaré en detalle lo que hace cada una de ellas.

Hasta el momento, si queríamos combinar más de una imagen como fondo, lo único que podíamos hacer era utilizar alguno de los elementos que teníamos en nuestra página, aplicando un fondo a cada uno para obtener el resultado deseado. Incluso en ocasiones, utilizábamos marcado extra, disminuyendo la calidad de la web al añadir marcado con fines únicamente presentacionales.

Pero ahora la cosa cambia…

Gracias a CSS 3, si queremos utilizar dos o más imágenes de fondo, a la propiedad background-image: le podremos añadir la ruta de cada una de ellas separándolas con comas. Por ejemplo:

background-image: url('fondo1.png'), url('fondo2.png')

Con algo tan sencillo como esto tenemos declarado lo necesario para que el elemento sobre el que lo apliquemos tenga las dos imágenes como fondo.

Claro, a partir de este punto surgen nuevas dudas…

• ¿se superponen entre ellas?
• ¿se pueden posicionar en distintos lugares?
• ¿se puede repetir una sobre un eje y evitar que la otra lo haga?
• …

…y todas tienen como respuesta SI.

Respecto a la superposición, la primera imagen que se declara es la que se coloca más próxima al usuario. A continuación y por detrás de esta, se coloca la siguiente (en un eje perpendicular a la pantalla), luego la siguiente, y así sucesivamente hasta la última, que será la que se sitúe detrás de todas. Es como si cada imagen se situase en una capa. Si además declaramos un color de fondo, este se pondrá por detrás de todas las imágenes empleadas.

En cuanto al resto de dudas, puedo generalizar una respuesta, pues todas han surgido al pensar en las propiedades que habitualmente utilizamos, es decir, posición de la imagen de fondo (background-position), comportamiento al scroll (background-attachment) y repetición (background-repeat). Si queremos que cada imagen tenga un valor determinado, únicamente habremos de declararlos consecutivamente y separados por comas (al igual que hicimos al declarar las propias imágenes). Por ejemplo:

background-image: url('fondo1.png'), url('fondo2.png'), url('fondo3.png');
background-position: 0 0, 150px 200px, left center;
background-repeat: no-repeat, repeat-x, no-repeat;

Con esto declaramos tres imágenes como fondo, la primera se situará arriba a la izquierda, la segunda se desplazará hacia la derecha 150px y hacia abajo 200px y la tercera se colocará también a la izquierda y centrada verticalmente. Respecto a la repetición, la primera y la última no se repetirán y la segunda lo hará sobre el eje horizontal.

Pero aquí no se termina el tema. Para los que nos gusta optimizar el código (que deberíamos ser todos), algunas declaraciones se pueden abreviar:

background-position: 0 0, 150px 200px, left center;

pasa a:

background-position: 0 0, 150px 200px, left;

Se elimina la palabra center. Como todos sabemos (o deberíamos saber), cuando no se declara uno de los valores de posición del fondo, el que toma por defecto es el de centrado (center), en este caso vertical.

background-repeat: no-repeat, repeat-x, no-repeat;

pasa a:

background-repeat: no-repeat, repeat-x;

El tercer valor se puede eliminar. La razón es que cuando faltan valores, se repite la lista de los valores que ya declarados hasta tener uno por imagen (de ahí que si empieza la relación de valores de nuevo, el primero sea no-repeat).

Pero aún se puede optimizar más, aprovechando la propiedad shorthand background::

background: url('fondo1.png') 0 0 no-repeat, url('fondo2.png') 150px 200px
repeat-x, url('fondo3.png') left no-repeat;

Como veréis, todo esto abre el abanico de posibilidades a nuestros diseños.

Algunos navegadores, en sus versiones actuales, comienzan a tener soporte para múltiples imágenes de fondo. Entre ellos están Firefox (a partir de la versión 3.6), Chrome, Safari y Konqueror. Si estáis utilizando uno de ellos, podéis ver el resultado en el ejemplo que he preparado. Lamentándolo mucho, aun no hay soporte en Internet Explorer (ya se verá si lo incluyen en su futura versión 9) ni en Opera. A continuación os incluyo un pantallazo con lo que se muestra en el ejemplo cuando hay soporte (si accedéis con un navegador sin soporte, únicamente veréis el borde punteado):

Aparte de lo comentado, CSS 3 también incluye nuevos valores para algunas de las propiedades mencionadas, además de nuevas propiedades que darán gran versatilidad a nuestros diseños. En un próximo artículo las trataré en detalle. Para ir abriendo boca os menciono background-size… ¡sí, es lo que estáis pensando!

nota: Supongo que aparte del contenido técnico del artículo, lo más apetecible es la tarta de la foto. Pues para daros un poco de envidia os diré que la foto la hice yo y es una tarta de frutas que me preparó Dolores… Es evidente que ella también domina el tema de controlar la presentación, pero además os garantizo que el domina la gestión de contenidos, pues estaba deliciosa…

Hoy uno rapidíto

En una determinada diapositiva tuve que categorizar una lista de propiedades. Esta lista resultaba ligeramente larga como para acomodarla de forma vertical en la pantalla (máxime cuando quería añadir otra lista más en la misma diapo), con lo que decidí estilarla en línea. Nuevamente mi intención era aprovechar la propia presentación como ejemplo (os recuerdo que la hice con el rumoslide, el cual es básicamente XHTML, CSS y javascript) para demostrar lo que se puede conseguir con las hojas de estilo.

A continuación incluyo la lista en cuestión. Lo hago en forma de imagen para que se vea su aspecto sin estilar (únicamente muestra los estilos que Firefox le aplica por defecto):

El HTML empleado es simple. Se trata de una lista en la que cada item está constituido por un elemento code con texto en su interior:

<ul class="herencia">
	<li><code>border-collapse</code></li>
	<li><code>border-spacing</code></li>
	<li><code>caption-side</code></li>
	<li><code>color</code></li>
	...
	<li><code>widows</code></li>
	<li><code>word-spacing</code>
</ul>

…y el resultado que quise obtener (y que evidentemente obtuve) es el siguiente (nuevamente incluyo un pantallazo):

Los estilos empleados para conseguir este resultado son:

code {
	font: .8em monospace;
	color: #009;
}
.herencia li {
	display: inline;
}
.herencia li:after {
	content: ', ';
}
.herencia li:last-child:after {
	content: ' ';
}

Lo primero que hice fue estilar el elemento code para poder diferenciarlo del resto de texto. Para ello jugué con el tamaño de la fuente, su familia y su color. Como se ve, todo muy simple.

Para que la lista inicialmente en vertical pasase a alinearse cambié la propiedad display de los items a inline. Luego hice aparecer una coma tipográfica y un espacio (“, “) mediante la propiedad content (contenido generado). Esta la apliqué sobre el pseudoelemento :after. Finalmente, como esto hace aparecer la coma también en el último item, lo que hice fue indicar que su contenido generado estuviese vacío (content: ' ').

Vale, es evidente que hay una pega en algo que aun no he comentado y que espero que alguien se haya dado cuenta (idealmente alguno de los alumnos/as asistentes al curso). Para seleccionar el último item utilicé la pseudoclase :last-child de CSS 3, cuyo soporte está muy poco extendido. Pensaréis que podría haber utilizado únicamente selectores de CSS 2.1. Por ejemplo, podría haber generado el contenido antes de cada item (en lugar de después) usando :before y luego seleccionar con :first-child el primer item para quitarle la coma de delante. ¿Por qué no lo hice?… por lo siguiente:

La coma se dispone al comienzo de cada línea cuando un item se sitúa en dicha posición, lo cual es evidentemente una incorrección. Para evitar esto, y sabiendo que el navegador que iba a utilizar tiene soporte para ello, decidí emplear CSS3… Lo se, :last-child no está suficientemente extendido entre los navegadores, pero al menos en las ultimísimas versiones si… y para la presentación me sirvió perfectamente.

Después de todo este rollo se puede extraer una conclusión: CSS me mola, y el poder usar la presentación del curso como ejemplo me mola aun más. Eso si, por favor,… navegadores con más soporte y que llegue pronto CSS 3.

Os dejo el enlace a un par de listas en las que se detalla el grado de soporte de CSS en base al navegador:

• http://www.webdevout.net/browser-support-css#css3standards
• http://www.quirksmode.org/css/contents.html

Por cierto, en la presentación no me pude aguantar y utilicé un poco más de CSS 3… evidentemente no me podía quedar sin redondear algunas esquinas. En un próximo artículo os lo comentaré…

La cuestión es que lo extenso del temario (o lo ajustado del tiempo) hizo que me quedase con las ganas de comentar algún detalle sobre los estilos que empleé en la presentación. Precisamente para ello me he puesto a escribir este artículo (bueno, y para retomar la costumbre de escribir periódicamente en el blog).

Como es lógico, el comienzo es el comienzo, con lo que hoy le toca a la portada:

De la portada lo que quiero comentar es lo que hice con el título de la presentación. Mi idea era destacar ambas palabras (CSS y avanzado), tratando de hacerlo con suficiente énfasis individual para cada una, pero cuidando que no perdiesen su unión. Para ello, entre otras cosas, jugué con el tamaño y color de las fuentes (grande y claro vs menor y oscuro) y con su posición (superposición parcial).

Lo primero, el código HTML que utilicé:

<h1>
	CSS
	<span>Avanzado</span>
	<span></span>
</h1>

Y a continuación la CSS y su explicación:

h1  {
	font-size: 7em;
	color: #ffc8a3;
	line-height: .8;
	font-style: italic;
	margin: .5em 0 .2em 20%;
	border-bottom: 3px solid;
	position: relative;
	overflow: hidden;
}

La idea ha sido estilar primero las letras CSS del encabezado. Como el resto del texto se incluye en un span, se puede aplicar un estilo genérico para el h1 para luego compensar el efecto sobre este. Así pues, declaré un tamaño de fuente suficientemente vistoso (7em), un color que combinase de forma adecuada con el resto de los estilos empleados y que no fuese demasiado intenso, el alto de línea y el estilo cursiva. Además le apliqué unos márgenes, teniendo en cuenta que quería separarlo de la izquierda un 20% del ancho total. Finalmente le puse una línea inferior de 3px (el color lo hereda de la tipografía).

Junto con estos estilos, como la superposición de palabras la conseguí con posicionamiento absoluto (más adelante lo comento), recurrí a inicializar las coordenadas de los descendientes del encabezado posicionándolo en relativo. El control sobre lo que desborda (overflow: hidden) lo añadí a posteriori (porque vi que el resultado quedaba elegante) tras estilar el resto del encabezado. Con esto se consigue que la parte inferior de la palabra avanzado oculte al sobresalir sobre los límites del h1.

A continuación estile la palabra avanzado:

h1 :first-child {
	font-size: .5em;
	font-style: normal;
	color: #222;
	position: absolute;
	top: 60%;
	left: 15%;
	opacity: 0.75;
	-moz-opacity: 0.75;
	-ms-filter: alpha(opacity=75);
}

Para evitar el marcado adicional jugué con los selectores. El término avanzado está en el primer elemento descendiente del h1, con lo que la selección se realiza mediante la pseudoclase :first-child. Lo primero, cambiar las propiedades de la fuente (reducir tamaño, cambiar color y eliminar la cursiva). La superposición la hice mediante posicionamiento absoluto (las coordenadas se toman respecto a la posición del h1 al haberle declarado posicionamiento relativo a este). Finalmente le di un toque extra jugando con su opacidad (recurrí a las propiedades con prefijos específicos que permiten que se vea correctamente en las versiones más actuales de los navegadores).

Y ahora la pregunta ¿cómo conseguí el efecto del degradado blanco?. La respuesta es sencilla y se basa en el siguiente código:

h1 span + span {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
 	background: transparent url(img/degrada.png) left bottom repeat-x;
}

El span vacío que añadí (y que seguro que a alguno ya le sonaba raro) es el que se encarga de este efecto. En realidad la idea es simple. Se puede conseguir el efecto poniendo sobre el texto una imagen png con un degradado de color que vaya de blanco a transparente (el blanco es por el fondo de la página). Para ello seleccioné el span mediante un selector contextual (es el span que va detrás de otro span, con lo que span + span), lo posicioné en absoluto e hice que ocupase el 100% del ancho y alto del encabezado (al posicionar el span, pasa a admitir dimensiones). Luego le añadí la imagen del degradado como fondo alineado en la parte inferior (como es una imagen estrecha, hice que se repitiese sobre el eje x). Y listo…

El resto de estilos aplicados a la portada (pié y logo) se mantienen constantes a lo largo de las diapositivas de la presentación. En general son bastante sencillos, por lo que los comentaré rápidamente (quizás lo detalle cuando mencione los estilos de otras secciones en artículos posteriores). Decir que el pié es un contendedor genérico que incluye una lista (a la que le he quitado los bullets). Le puse un color de fondo intenso próximo al naranja CTIC y una imagen (también de fondo) colocada a la derecha. Además lo posicioné fixed en la parte inferior de la pantalla porque no quería que se desplazase con el scroll vertical (esto me sirvió de ejemplo durante el curso).

Respecto al logo, es un svg incluido en el elemento object. Lo que hice fue posicionarlo en absoluto ahí arriba y mantenerlo así durante toda la presentación.

En brevé comentaré algunos otros ejemplos de estilo que apliqué a lo largo de la presentación, como por ejemplo, la forma en que conseguí el fondo bicolor con las letras CSS, etc.

Aun así, hoy me di cuenta de un detalle que me sirve para comentar una idea. Cuando queremos jugar con la simulación de sombras, es importante mantener una cierta coherencia. Mejor será que lo ilustre (las imágenes funcionan como enlaces para acceder a su ampliación):

Esta es la cabecera actual de una sección cualquiera de la web, en concreto del área de noticias. De ella me gustaría destacar tres zonas concretas:

Como se puede observar, hay tres efectos de sombra, dos de ellos conseguidos con imágenes y el tercero con el color de los bordes superior e izquierdo. El problema es que la sombra que genera el área azul (la que incluye el logo) trata de simular que la capa inferior es ligeramente cóncava (o la superior convexa), mientras que la que genera la cabecera con la palabra NEWS es totalmente plana. Para rematar el terceto tenemos la sombra de la capa para intercambiar las Views y es la que generada con el color de borde. Mientras que en las dos primeras la luz proyecta la sombra hacia la parte inferior, en la tercera la sombra se sitúa por encima de la capa, con lo que no existe una coherencia en la dirección de la luz o en la ubicación de la misma.

Por este motivo, me atrevo a hacer una simple sugerencia que creo que mejora la situación (os recuerdo que la imagen funciona como enlace para acceder a su ampliación):

Únicamente se trata de hacer dos simples cambios:

• Las dos sombras principales podrían pasar a unificarse (en el ejemplo opté por el segundo tipo de sombra, más recto y definido).
• Por otro lado, en el submenú Views podría haber sugerido intercambiar los colores de los bordes de arriba a abajo y de izquierda a derecha, pero como la sombra creada por estos no considero que sea eficaz, pienso que una opción podría ser desplazar dicho submenú hacia la derecha, alineándolo con el buscador. No creo acertado el que deba tener tanto peso visual como para situarse en un área destacada (como está actualmente). Y ya puestos, al emplear esquinas redondeadas, yo lo pondría como una pseudopestaña que surje de la parte superior de la web. Opcionalmente, lo simplificaría eliminando la opción de la vista actual (por ejemplo, si estamos en la vista desktop, no es necesario incluir dicha opción).

En conclusión, cuando simulemos efectos de sombreado, seamos coherentes. Si queremos que el resultado parezca natural, debemos tener en cuenta la posición de la luz y su direccionalidad.

nota: De acuerdo, enviaré esta sugerencia al propio W3C. Ya os contaré…

headingsMap

Esta extensión genera un índice (o mapa) de cualquier documento web estructurado mediante el uso de encabezados, de tal manera que pulsando sobre cualquiera de los items de dicho mapa, se accede directamente al contenido correspondiente de la página.

Sí, ya lo se, esto mismo lo hace también otra extensión (documentmap). La diferencia estriba en que headingsMap, además de indicar los niveles de cada encabezado y los posibles errores que pudiera haber en su secuencia (por ejemplo, los saltos inadecuados), en el caso de haber marcos (FRAMESET e IFRAMES) también genera el mapa para cada uno de ellos. De esta manera, se convierte en una herramienta útil tanto para la navegación por el documento como para revisar y/o auditar sitios web (en cuanto a accesibilidad, estándares, etc).

Como no podia ser menos, también se le ha añadido una funcionalidad adicional. En el caso de que el documento web al que se esté accediendo sea una presentación en formato web hecha con acc_slide (o rumoslide) o con HTML Slidy, la extensión funciona como un índice, permitiendo acceder directamente a la diapositiva que se desee.

En la página de la extensión headingsMap se puede encontrar más información, así como en Firefox add-ons.

Al instalar la extensión, aparece un icono en la barra de estado que despliega el panel lateral en el que se muestra la estructura de encabezados. También se puede acceder mediante la combinación del teclado Alt + O.

WCAG Contrast checker

Mediante esta extensión se puede comprobar si la combinación de dos colores es adecuada para su percepción visual en base a los requerimientos de las WCAG 1 y WCAG 2, empleando para ello el algoritmo que estas proponen. Dado que el algoritmo incluido en las WCAG 2 parece ser más preciso, el resultado de este es el que se muestra por defecto.

En un panel lateral se ofrece la posibilidad de introducir el código de los dos colores que se quieren comparar, mostrándose los resultados tanto para el caso de una percepción normal de los colores, como para situaciones tales como la protanopia, deuteranopia y tritanopia.

El código de color se puede introducir tanto en formato hexadecimal (en forma abreviada o no, y tanto con almohadilla como sin ella), como en RGB (pudiendo usar diferentes separadores entre los valores, como por ejemplo la coma o los dos puntos). Ej:

• En hexadecimal se podría poner: #FC5 ó FC5 ó FFCC55
• En formato RGB se podría poner: 231,28,197 ó 231:28:197 ó rgb(231,28,197)

El uso de la extensión WCAG Contrast checker se puede combinar con la extensión ColorZilla, pues esta permite seleccionar directamente desde el documento web (y copiar al portapapeles) el color que se quiera comprobar. Si se tiene dicha extensión instalada, WCAG Contrast checker reconocerá su presencia. En este caso, pulsando Shift + Z ó Shift + X se activará el eyedropper del ColorZilla y se enviará de forma automática, bien el color de primer plano, bien el de fondo, al WCAG Contrast checker para su análisis.

La extensión hace aparecer un icono en la barra de estado que al pulsarlo despliega el panel lateral, pudiendo acceder también mediante la combinación del teclado Alt + C.

En la página de la extensión WCAG Contrast checker y en Firefox Add-ons hay más información, además del enlace para la descarga.

La pregunta no parece complicada a simple vista. Simplemente con utilizar el elemento <script> en dicho documento, donde el valor del atributo src nos indique donde se encuentra el fichero, sería suficiente.


<script type="text/javascript" src="ruta_a/fichero.js"></script>


Sin embargo, si por un "descuido" olvidásemos la etiqueta de cierre de este elemento (</script>) comenzarían los problemas. IE (6 y 7) devuelven un documento en blanco, sin contenido. Si vemos el código fuente de la página, esta todo. Qué raro, ¿no?

En todo caso, la solución no es difícil. Cerramos el elemento y arreglado.

Si se trata de un documento XHTML, al ser nosotros unos tíos finos que nos gusta el código limpio y ordenado reducimos el código de llamada al código JavaScript mediante el uso de un elemento vacío, al igual que haríamos con contenedor de metainformación (<meta />), una imagen (<img />) o incluso con un vínculo a un recurso externo (<link />).

<script type="text/javascript" src="ruta_a/fichero.js" />

Sin embargo, a pesar de ser un documento válido, Volvemos a lo mismo, IE nos vuelve a sorprender con un documento en blanco. De nuevo, la solución es sencilla: utilizar la correspondiente etiqueta de cierre del elemento (</script>).

¿Eso es todo?. No, que va. Si todo el trabajo lo realizaramos de forma manual no sería mayor inconveniente que recordar en todos los documentos que tenemos que utilizar esta etiqueta de cierre. Lamentablemente, hoy en día las cosas son un poco más complicadas y es habitual que el contenido sea generado y procesado a partir de otros documentos XML, por lo que el tratamiento de ciertos elementos se realiza en cadena. Por ejemplo, a los elementos vacíos se les proporciona de forma automática su correspondiente etiqueta de cierre (<img></img>, <input></input>, <script></script>), lo que a fin de cuentas devuelve un código no muy limpio. Si por el contrario sucede que a todos los elementos vacíos se les aplica la barra de cierre (/) tendremos los problemas anteriormente descritos con nuestro navegador más querido.

La recomendación HTML 4.01 indica que la etiqueta de cierre del elemento <script> es requerida, pero de ahí a que IE se altere y deje de respirar va mucho. ¡Qué menos que pasarse a modo quirks!, ¿no creéis?

Por las cosas que dice, en el siguiente vídeo sería mejor no escuchar al presentador…

Y si, vale, me he permitido la licencia de insertar estos vídeos sin preocuparme de las alternativas textuales, de la validación de código, etc. Es que ya llevo varias sidras y no estoy a lo que estoy.

Lo dicho, hoy invito yo. Ahora sólo hace falta que Mateo (Porras) vaya a por una caja… el sabe cómo conseguirlas…

nota: ¡Se acabaron las prácticas con agua!

Algunos no le dieron más importancia que la que tiene dentro del propio contexto. Sin embargo, otros empezamos a darle vueltas a lo que a primera vista era algo que no podíamos comprender: ¿vamos a retroceder y volver a mezclar lo que entendemos por presentación con lo que entendemos por comportamiento?

Rápidamente muchos se apresuraron a decir… a murmurar… a escribir en listas de correo… que aquello era algo así como sacrílego. Lo confieso, esa fue mi primera tentación. Pero no me tapé los oidos, pues suponía que el W3C no podía estar haciendo algo así, algo en contra de un principio fundamental, la “máxima” que los buenos tratan de respetar, “la separación entre contenido, presentación y comportamiento“. Recapitulé, repensé y me posicioné…

El error no está en la propuesta de controlar con CSS el comportamiento de los enlaces. El error reside en nuestra interpretación del término “comportamiento”, o más bien en lo que creemos que abarca. Está claro que la forma en la que se muestra el contenido pertenece a la capa de presentación. En base a esto… ¿el que se muestre en una ventana nueva qué es: comportamiento o presentación? Yo tengo clara la respuesta…

Cito textualmente (extracto de CSS3 Hyperlink Presentation Module):

Some parts of behavior are presentational; e.g., CSS can say that
activation of a hyperlink causes a new window to pop up (but not, e.g., that
the activation sends a POST request to a server). The specifiable behaviors
include:

• replace current document or portion of a document by target
• pop up a temporary window (possibly modal) with the target
• ditto, but pop “under”
• show target in a specific window
• using tabs in a tabbed interface rather than windows in the above

Yo creo que está bastante claro.

Por ahí alguien escribió irónicamente que, por ejemplo, el segundo punto se referiría a algo parecido al lightbox, como si fuese algo que se ha de hacer con javascript y fuese una tontería (por no utilizar un adjetivo peor) considerarlo como presentacion. En mi humilde opinión, básicamente el lightbox no consiste más que en mostrar dentro de una capa un contenido (objetivo del enlace), posicionándolo, poniendole un fondo, etc. ¿Acaso eso no es presentacional? Evidentemente, todo menos la petición al sevidor pertenece a la capa de presentación.

En conclusión… el comportamiento es una parte fundamental de la trilogía. Comencemos a demostrar que entendemos qué es y que sabemos diferenciarlo del resto.

Después de investigar un poco por la red, encontramos que en todos los sitios que se hacen eco de la novedad referencian siempre los mismos ejemplos, obtienes la foto de un CD o el cartel de una película y a partir de la información obtenida podrás realizar, incluso, compras (se supone que del CD en cuestión o las entradas para la peli). Esto me suena al mítico ejemplo utilizado en la Web Semántica con los horarios de los aviones …

Buscando aplicaciones prácticas del invento, porque no se juntan con los investigadores de la Universidad de Cambridge (los que concluyeron que Jessica Alba es matemáticamente perfecta), intercambian algorítmos y así, mediante una foto sepamos si tenemos delante a la mujer perfecta (para decirselo, más que nada). Aunque vistas las escasas referencias encontradas sobre el tema, nos conformaremos con lo de los CD´s.

Parece que ellas ya le han encontrado alguna utilidad. Que ruina!!.

Última hora

Al parecer, Kooaba proporciona este servicio a vuelta de MMS.

Para evitar las frustrantes esperas que hemos de sufrir cuando, tras realizar la consulta, la fecha elegida no está disponible, en algunos sitios el calendario las filtra ofreciendo sólo las que si lo estan. Esto me hizo pensar que al acc_calendar le hacía falta esa posibilidad para quedar (al menos un poco) “niquelao”.

Dicho y (tras un buen rato) hecho. Mediante un toque de ajax, podemos aplicar un filtro sobre el calendario para que únicamente permita la selección de determinadas fechas. Para ello, de forma opcional añadiremos la clase disp en el campo de texto para la fecha. En el script hay disponible una variable (fichero_consulta) en la que indicar la dirección que resolverá la consulta de días disponibles en el servidor.

El envío se hace mediante el método POST y las variables son el mes y el año (month, en formato numérico, y year). El servidor ha de devolver los días disponibles en forma de texto y separados por comas. Por ejemplo, con php podría devolver la cadena 12,13,14,17,21,28,29 mediante un simple echo.

Ya he retocado el artículo original dedicado al calendario para detallar (otra vez) esta funcionalidad e incluir un ejemplo.

Si alguno de vosotros piensa que es mejorable, que lo diga. Yo por mi parte haré lo que pueda (teniendo en cuenta que estoy de vacaciones).

Supongo que alguno ya conocerá más de un sistema de los que habitualmente se utilizan, como por ejemplo el HTML Slidy del W3C o el S5 de Eric Meyer. Tras utilizarlos llegué a la conclusión de que, aunque buenos, había algo que quizás podría ser mejorable (según mi criterio, claro).

Como he dicho, ambos sistemas son buenos y válidos, pero en ambos se hace necesario utilizar marcado cuya única finalidad es la de servir para que el script lo utilice y aplique estilos sobre él. Si realmente se quiere tener algo eficaz, ¿por qué no hacer que el propio script genere el marcado que necesita de forma inteligente?

El desarrollo

Me puse manos a la obra con la siguiente premisa: Si tenemos un documento correctamente estructurado y marcado (con sus encabezados, párrafos, listas…), el script debe ser lo suficientemente inteligente como para organizar y generar la presentación, todo ello sin incluir ningún contenedor adicional, ni clases, ni id. Únicamente ha de ser la propia estructura del documento la que permita diferenciar lo que se tiene que incluir en cada diapositiva.

Tras pegarme con ello, aquí está el resultado. El acc_slide, o como Andrés y Maroto lo llaman, rumo_slide o slide_oso. En lugar de seguir escribiendo más acerca de ello, lo mejor es demostrar de lo que estoy hablando. He preparado dos presentaciones, ambas con la descripción del sistema y de su utilización. La diferencia entre ambas es el grado de resumen. No dudéis en echar un vistazo al marcado que he empleado para ver de lo que estoy hablando:

nota: aunque la forma de navegación por la presentación se trata en la misma, la forma básica de moverse por los contenidos se realiza con las flechas (arriba y abajo) del teclado.

• Versión reducida y Versión reducida descargable
• Versión extendida (si, muy extendida) y Versión extendida descargable

Características básicas

acc_slide ha sido creado teniendo como objetivo la separación absoluta entre el contenido y el comportamiento, evitando cualquier consideración acerca de este al crear y marcar la información que se quiera mostrar.

Entre las características que el sistema de presentaciones acc_slide posee se pueden destacar:

• Únicamente requiere de una correcta y lógica estructuración del contenido mediante el uso de encabezados. No necesita de elementos adicionales más allá de los necesarios para el marcado semántico del contenido. El sistema reconstruye y adapta el árbol DOM, con lo que no impone la necesidad de un marcado concreto. Esto lo hace compatible con cualquier documento (X)HTML bien estructurado (incluso con los que incluyen el marcado empleado por otros sistemas de presentaciones). Esto lo hace totalmente versatil. Se podría utilizar sobre un documento web, sobre el marcado empleado en los otros sistemas de presentaciones, etc.
• Respetuoso con los estándares y la accesibilidad.
• Separación absoluta de contenido, presentación y comportamiento.
• Fácil integración y fácil utilización. No requiere conocimientos específicos, y si se utiliza uno de los temas propuestos, no es necesario conocer CSS.
• Permite crear secciones con grupos de diapositivas.
• El aspecto gráfico ofrece gran versatilidad y se controla totalmente con CSS. Además se pueden crear varios estilos y jugar con la especificidad de selector para aplicarlos (y combinarlos) en caliente (mientras se ejecuta la presentación).
• Sistema autoplay de reproducción automática.
• Incorpora un sistema para abrir enlaces de forma integrada a la presentación. Si se incluye el atributo title en el enlace, el contenido de este se mostrará al pié de la ventana. Además, el destino del enlace puede ser una URL o una imagen.
• Cada diapositiva se asocia con un ancla de tal manera que se puede ir directamente a la que se desee. El ancla coincide con la posición de la diapositiva en la presentación.

Llegados a este punto, espero vuestro feedback. También estaba pensando crear un repositorio público de estilos para el sistema. Si os parece una buena idea y queréis participar con los vuestros, no lo dudéis. Podéis enviar vuestros temas a rumoroso@niquelao.net

Tras observar la posible versatilidad de otros calendarios que se cargan con javascript, me he decidido a implementar un nuevo cambio y retocar/actualizar el artículo original.

El cambio consiste en la posibilidad de utilizar el calendario para cargar cada uno de los datos de la fecha en un campo de texto independiente. Asímismo, he decidido eliminar ciertos estilos que se aplicaban desde el propio script para que todo lo referente a la presentación sea una tarea de CSS.

Espero vuestro feed-back.

El nuevo script tiene una pequeña modificación tal que si en cualquier momento se introducen nuevos campos de texto bastará con llamar posteriormente a la función cargaLinks() para que todo funcione como se desea.

Se puede acceder al artículo completo del calendario (con la revisión incluida) desde acc_calendar v1.1 o desde el enlace permanente del área de Recursos de la página principal.

nota: Lo que no podemos olvidar es que para que los nuevos input asocien el enlace para la apertura del calendario tendrán que poseer las clases ya indicadas en el anterior artículo.

Objetivos

En principio he establecido dos objetivos principales, que más que objetivos han sido pautas de trabajo a la hora de construirlo:

• Que sea accesible y no intrusivo. Evidentemente, en ausencia de soporte para javascript no se ofrece la opción de desplegar el calendario, pero, si hay soporte… ¿por qué no hacer que el contenido generado sea accesible y utilizable?
• Que sea fácil de implementar y utilizar. He buscado una forma tal los programadores que deseen implementarlo en sus páginas web no requieran de introducir código adicional. Al igual que en CSS se utilizan diversos tipos de selectores (de elementos, id, clases,…) para asociar estilos a las diferentes partes de nuestros documentos, ¿por qué no utilizar lo mismo para asociar comportamientos?

Además, como objetivos secundarios están: optimizar, generalizar, internacionalizar,… (siendo realista, tuve que eliminar los objetivos de ligar y el de ganar dinero.)

El ejemplo

Para comprobar su funcionamiento, podéis acceder a un ejemplo y descargarlo.

Incluyéndolo en nuestros documentos

La inclusión del calendario en nuestro documento es tan sencillo como incluir el elemento script correspondiente en el head:

<script type="text/javascript" src="acc_calendar/acc_calendar.js"></script>

El calendario se cargará para cualquier campo de texto que lleve incluida la clase “fecha“. El formato de la fecha se introduce en la primera línea del script. Así, si por ejemplo se desea que la fecha siga el orden día/mes/año, no incluyendo un 0 delante del día cuando esté formada por un dígito, e incluyéndolo en el mes cuando sea necesario:

var formato = 'd/mm/y';

Para conseguir mostrar el calendario junto a un campo de texto, este deberá llevar la clase “fecha”. Además, todos los posibles parámetros se introducen como clases. La lista completa es la siguiente:

• Cargar calendario (requerido): fecha
• Fechas previas a hoy: prev
• Fechas posteriores a hoy: post
• Rango de años: rangX (siendo X el número de años)
• No se incluye el día actual: todnact

Ventajas

Entre las ventajas que se le pueden atribuir tenemos:

• Fácil de usar e implementar.
• No es intrusivo.
• El código y el contenido que se genera es accesible (marcado, organización, contenido,…) y es utilizable mediante el uso de ayudas técnicas (lector de pantalla,…). En este punto se ha tenido en cuenta en qué lugar recae el foco tanto al mostrarse como durante el funcionamiento y al desaparecer. Así, cuando se muestra, el foco recae directamente sobre el selector de años, siguiendo un orden lógico al tabular desde él, y cuando se cierra el calendario (mediante el enlace de cierre o tras haber seleccionado una fecha) el foco recae sobre el campo de texto al que se le había asociado.
• Se facilita la navegación por el mismo independientemente del dispositivo. Se puede navegar utilizando cualquiera de los dispositivos con los que podamos navegar por la web.
• Sus parámetros son fácilmente configurables y su llamada muy simple (mediante el uso de nombres de clase).
• El idioma lo toma directamente del documento padre, pudiendo añadir traducciones nuevas al código. En el caso de no estar declarado el idimoa en el documento (cosa que no debe ocurrir), el español será el que se utilice por defecto. Actualmente, además del español incluye el inglés. Adicionalmente se ha hecho que reconozca si es inglés americano, no porque vaya a cambiar el contenido, sino para cambiar la disposición de los días de la semana (el domingo se coloca primero).
• Los estilos aplicados al calendario se incluyen mediante una CSS enlazada por medio del script, con lo que en ausencia de soporte para este, se optimiza la descarga del documento al no llamarse a dicha hoja de estilos.
• Se han incluido clases de tal manera que se puedan aplicar estilos sobre cualquiera de las celdas de la tabla (días activos, días no activos, día actual), así como estilos específicos para los sábados o domingos.

Código generado

A continuación incluyo parte del código generado por el script. Como se puede observar (y como ya he dicho) se incluyen nombres de clase e id para poder controlar la maquetación mediante la hoja de estilos.

<a title="Desplegar el calendario para seleccionar una fecha" href="#" class="enl_cal">
	<img alt="" src="acc_calendar/acc_calendar.gif" />
</a>
<div id="calendar">
	<label id="label_year" for="nav_year_select">Año
		<select id="nav_year_select">
			...
			<option>1987</option>
			<option selected="selected">1988</option>
			...
		</select>
	</label>
	<label id="label_Meses" for="nav_mes_select">Mes
		<select id="nav_mes_select">
			<option selected="selected">Enero</option>
			<option>Febrero</option>
			<option>Marzo</option>
			...
		</select>
	</label>
	<table summary="Calendario con los días disponibles de Enero de 2007" id="calendario">
		<caption id="caption">Enero 2007</caption>
		<colgroup span="5"></colgroup>
		<colgroup span="2"></colgroup>
		<thead>
			<tr>
				<th scope="col"><abbr title="Lunes">Lun</abbr></th>
				<th scope="col"><abbr title="Martes">Mar</abbr></th>
				...
			</tr>
		</thead>
		<tbody id="tbody">
			<tr>
				<td class="act">
					<a title="Seleccione esta fecha" href="#">1</a>
				</td>
				<td class="act">
					<a title="Seleccione esta fecha" href="#">2</a>
				</td>
				...
			</tr>
			<tr>
				...
				<td class="inact">24</td>
				<td class="inact">25</td>
				...
			</tr>
		</tbody>
	</table>
	<ul id="nav_mes">
		<li>
			<a href="#">Diciembre</a>
		</li>
		<li class="post">
			<a href="#">Febrero</a>
		</li>
	</ul>
	<ul id="nav_year">
		<li>
			<a href="#" title="Ir al año">2004</a>
		</li>
		<li class="post">
			<a href="#" title="Ir al año">2006</a>
		</li>
	</ul>
	<div id="close_it">
		<a href="#">Cerrar calendario</a>
	</div>
</div>

Conclusión

A modo de cierre… ¿qué se podría decir de este calendario?… pues que “es innecesario… pero útil” y que “no tiene implicaciones negativas en términos de accesibilidad“.

…por cierto ¿qué día es hoy?

A las funcionalidades que introducían los anteriores scripts le he añadido la capacidad de reconocer la agrupación de campos mediante el elemento fieldset, y todo con la finalidad de mejorar la experiencia de usuario y la accesibilidad. Este elemento tiene como finalidad el agrupar campos en base al tipo de datos a introducir (ej. datos personales, datos bancarios, datos académicos, etc), mejorando la estructura y la accesibilidad del conjunto. Al fieldset se le añade el elemento legend que funciona a modo de encabezado de los datos agrupados.

…y ¿para qué?

La idea me surgió tras ver horrorizado un inmenso formulario con multitud de campos obligatorios (y no voy a decir donde…). Cuando no se rellenan estos, la lista con los errores se vuelve larguíííííííííísima, con lo que resulta muy incomodo de leer, difícil de comprender e incluso estéticamente horrible.

Si los campos de formulario van agrupados para facilitar su comprensión, ¿por qué no agrupar los errores siguiendo el mismo patrón?

Para el funcionamiento del script no hace falta la agrupación, pero bueno… siempre es positivo tenerla presente y utilizarla.

La prueba

Como siempre, podéis acceder al ejemplo de uso o incluso descargarlo directamente.

Como se puede observar, los errores siguen mostrándose mediante una lista. No obstante, en este caso se crea una lista anidada para tratar de agruparlos y conseguir esa mejora en estructura antes mencionada.

…y todo esto se relaciona con

• Retocando Formularios, Episodio III (”El Retorno”)
• Retocando Formularios (Episodio II)
• Retocando Formularios (episodio I)

Importante: Quiero recordar que el uso de javascript no debe tener implicaciones negativas en la accesibilidad. Bien utilizado, y con todas las consideraciones hacia el usuario, mejora su experiencia.

¿Qué? ¿Estoy o no estoy a la última?. Esto no se consigue ni con un master.