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é…

Puedo ofrecerte tres tipos de trabajo.

Si lo quieres rápido y bueno, no será barato.

Si lo quieres bueno y barato, no será rápido.

Si lo quieres barato y rápido, no será bueno.

Vía: un cartel en Oxys´s Hell.

Aplicación práctica: a elegir.

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.

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

Salvo que seamos originales y queramos mostrar ese recuadro generado por el campo oculto (“casi oculto”), la solución es simple. Le aplicamos “display: none” y arreglado. Mi consejo es que no se traten de marcar los campos ocultos con una clase para luego aplicarle la propiedad que acabo de escribir. En su lugar se puede aprovechar el que Firefox entiende e interpreta los selectores de atributos:

[css]input[type=hidden] { display: none; }[/css]

Al turrón…

No, no es que este artículo trate sobre cómo maquetar lo que teóricamente debería ir oculto (un campo tipo hidden), y digo teóricamente porque ocurre que en el navegador Firefox, cuando tenemos activa la CSS y declaramos determinados valores para la propiedad “display” sobre los campos de formulario, los campos ocultos dejan de serlo pasando a ser renderizados por el navegador (tal y como se puede apreciar si se observa el ejemplo con el navegador Firefox o, si confias en nosotros y crees lo que decimos, en los siguientes pantallazos).

Llegados a este punto podrían surgir preguntas: ¿por qué aplicar un display sobre un campo “hidden“?; si la finalidad de un campo oculto es pasar información sin mostrarse, ¿por qué se iba a querer mostrar?;… La respuesta es fácil y quizás se comprenda mejor con un ejemplo:

Tenemos el siguiente formulario:
[html]

[/html]…al que le aplicamos unos estilos básicos:
[css]form {
border: 2px outset;
background-color: #CCCCCC;
}
fieldset {
margin: 20px auto;
width: 500px;
border: 1px solid;
padding: 10px;
}
legend {
font-size: 1.5em;
color: #000;
}
label {
font-weight: bold;
font-size: 1.1em;
}
fieldset input {
display: block;
width: 90%;
height: 1.3em;
line-height: 1.3em;
margin-left: 5%;
font-size: 1em;
}
p {
text-align: center;
margin: 1em 0;
}
fieldset p {
text-align: left
}[/css]

Le hemos aplicado un display: block a los campos de formulario para que provoquen el salto permitiendo que el texto que los etiqueta quede por encima. La disposición inmediatamente por encima de los campos de texto de las etiquetas favorece que la caja anónima de texto que generan tenga mayor superficie de contacto sobre la caja del campo, con lo que visualmente transmite mejor y de manera más rápida la asociación entre ambos (además, es la manera en la que me gusta ponerlo, y punto). Quizás se entienda mejor visualmente:

En la imagen anterior se muestran tres formas de maquetar el mismo formulario. En la primera se coloca el texto del label por encima del campo, con lo que su superficie de contacto es mayor. En las otras dos se puede apreciar cómo disminuye dicha superficie si el texto se situa junto al campo que etiqueta. Además, la tercera muestra el problema de querer alinear los campos entre si.

Además, de esta manera se podrían alinear a la izquierda todos los campos de texto, cosa que puede ser desable en muchas ocasiones y que puede crear conflictos cuando la etiqueta antecede al campo (dado que estas no suelen tener la misma longitud).

La cuestión es que al darle esta propiedad a los “input“, en Firefox, y únicamente en Firefox, se renderiza el campo oculto, haciéndolo como un bloque vacío. ¿Comportamiento correcto o bug? Si observamos el comportamiento de IE se apreciará que esto no ocurre. A estas alturas, los detractores de IE ya estarán diciendo que Firefox hace lo correcto, pues en los castings le suelen seleccionar para el papel del bueno. En este caso que cada uno saque sus conclusiones, no sin antes plantear un par de cosas (bueno, cuatro, lo de “un par” es una forma de hablar):

• ¿Acaso algún programador quiere mostrar la caja creada por un campo oculto?
• ¿Acaso el diseñador piensa ignorar lo que el programador hace y pretende mostrarlo por su cuenta?
• ¿Acaso no dice la especificación: hidden controls: Authors may create controls that are not rendered but whose values are submitted with a form. Authors generally use this control type to store information between client/server exchanges that would otherwise be lost due to the stateless nature of HTTP. The INPUT element is used to create a hidden control. (hidden control)?
• ¿Qué finalidad puede tener el mostrar la caja vacía creada por el campo oculto?

Una solución

Salvo que seamos originales y queramos mostrar ese recuadro generado por el campo oculto (o mejor “casi oculto”), la solución es simple. Le aplicamos “display: none” y arreglado. Mi consejo es que no se traten de marcar los campos ocultos con una clase para luego aplicarle la propiedad que acabo de escribir. En su lugar se puede aprovechar el que Firefox entiende e interpreta los selectores de atributos:

[css]input[type=hidden] { display: none; }[/css]

…y una reflexión

¿Se habrán planteado los desarrolladores de Firefox el tratar de mostrar otras cosas ocultas tales como el aura, el alma, fantasmas,…? ¿Esperaré a que consigan hacerlo antes de enviar este artículo a Iker Jiménez?

El Efecto

El efecto consiste en que crea a a la derecha del elemento un espacio igual de largo que el espacio que hay entre los extremos izquierdos del documento y del propio elemento. Evidentemente no hace nada más que molestar…

Se puede apreciar usando IE7 para acceder al ejemplo.

La Solución

Lo que está ocurriendo es un desbordamiento del contenido (ese contenido imaginario que sólo IE ve), con lo que la solución pasa por aplicar un overflow: hidden al item de lista y… listo.

Si lo aplicásemos al body podría no aparecer el scroll vertical. Si lo aplicamos a la ul, tendríamos que compensar el que en Firefox la lista se pone a la derecha pero los items se alinean entre ellos a la izquierda (curioso).

Al temario. ¿Qué es lo que pasa?

Cuando utilizamos los pseudo-elementos definidos por la especificación de CSS 2.1 :first-letter y :first-line (obviamos el pseudo-elemento :first-child y similares ya que nuestro amigo IE pasa un poco de ellos) podemos comprobar que en ocasiones no obtenemos los resultados esperados.

¿Qué pasa?. Incompresiblemente, IE falla a la hora interpretar la sintáxis de CSS. Si a continuación de estos pseudo-elementos utilizamos la llave ( { ) para comenzar nuestra declaración sin dejar un espacio entre ambos, IE no lo interpreta. Lo puedes ver en el ejemplo uno.

	p:first-line{
		 color: blue;
		 font-weight: bold;
	}

Lo mismo sucede si tratamos de ofrecer propiedades comunes a varios elementos en una misma declaración, donde los mismos aparecen separados por comas ( , ). Lo puedes ver en el ejemplo dos.

	 p:first-letter, blockquote p:first-letter{
		color: #000;
		font: 2.3em serif;
		float: left;
		margin: .2em .2em 0 0;
	 }

Y la solución, ¿si la hubiera o hubiese?

En este caso, existe y es relativamente fácil. Simplemente dejar un espacio en blanco entre el pseudo-elemento y el símbolo que tengamos que aplicar, bien sea la coma ( , ) o la llave ( { ). Si no te lo crees, aquí tienes el ejemplo tres.

	p:first-letter , blockquote p:first-letter {
		color: #000;
		font: 2.3em serif;
		float: left;
		margin: .2em .2em 0 0;
	 }

Eh!! Que aquí no acaba todo!

Otro problemilla que encontramos viene de la mano de las listas. Y ahora, ¿que pasa?. Si aplicamos un estilo al pseudo-elemento :first-letter a elementos de lista, IE de forma agradable lo propaga al marcador del propio elemento de lista (bullet en caso de lista desordenada, número o letra en caso de lista ordenada). Qué incrédulo, mira el ejemplo cuatro.

¿Y la solución para este lío?

Si aceptais pulpo como animal de compañía, diremos que con eliminar los marcadores de las listas mediante:

	 li {list-style:none}

Si no, pués na.

Otro detalle sin importancia, es que a IE7b2 le da igual que no haya espacios entre el pseudo-elemento y el caracter {. Eso sí, a su hermano pequeño si le importa, así que respetemos su espacio vital.

Y ya puestos, ¿qué pasa con la especificidad?

Pués que va a pasar, pués nada, al menos con IE. En primer lugar debemos saber que estos pseudo-elementos solo (que no es poco), afectan a elementos a nivel de bloque. Bien, si definimos unas propiedades para, por ejemplo, un párrafo y a continuación definimos otras propiedades para otro párrafo que aparece dentro de un bloque de cita (blockquote) tendremos las mismas características en los 2 párrafos (claro, eso si nos hemos dado cuenta de darle el espacio correspondiente entre el pseudo-elemento y su maravilloso símbolo. Todo resumido en el último ejemplo.

Y la solución?

Como hoy ya me cansé, la buscas tú.

Problemas

• Tendremos que identificar cada tipo de enlace mediante una clase que permita aplicarle el estilo.
• En muchas ocasiones las personas que introducen los enlaces son los responsables del contenido y no tienen acceso a marcar el código.

Solución

Mediante una sencilla función escrita en javascript, e introducida de forma no intrusiva, podremos identificar el tipo de documento en función del contenido del atributo “title” (si está presente) y/o de la extensión del archivo destino.

Para nota: es una buena práctica el que los editores/responsables de contenido adopten el protocolo común de identificar el tipo de destino del enlace en el atributo “title” del mismo, pues la mayor parte de las herramientas de edición permiten su introducción.

Adicionálmente, se le ha añadido al script la funcionalidad de incluir un texto en el atributo “title” de aquellos enlaces que no lo posean y que apunten a un documento reconocible por el propio script.

Enlaces de Ejemplo

• Google
• Documento en formato pdf
• Este enlace no posee atributo “title” y con la función se le añade: Archivo de Word

El script

El script se detalla a continuación y lo puedes descargar directamente

Lo primero es declarar un array con el fragmento de texto a introducir por el editor/responsable del contenido y que describe el tipo de destino del enlace:

var tFormat = ["enlace externo", "formato pdf", "formato word"];

Declaramos una tipología de enlaces (declarado en el mismo orden que el anterior):

var Format = ["externo", "pdf", "doc"];

Declaramos las clases para formatear cada tipo de enlace (declarado en el mismo orden que los anteriores). Estas tendrán su correspondiente estilo en la CSS:

var classFormat = ["externo", "pdf", "doc"];

function enlaces() {
// Seleccionamos todos los enlaces del documento
 var links = document.getElementsByTagName("a");
 for (var i = 0; i < links.length; i++) {
   // Comprobamos que no son anclas
   if(links[i].href.indexOf(".") > -1) {
     // Comprobamos si tienen atributo "title"
     if(links[i].getAttribute("title")) {
       // Obtenemos el atributo "title" en minúscula
       var title = links[i].getAttribute("title").toLowerCase();
       // Hacemos un bucle que comprueba si en el "title" se
       // encuentra uno de los textos indicados en el array
       // tFormat. Si lo encuentra, le añade la clase
       // declarada en la misma posición que el texto
       // en el array classFormat
       for(var f = 0; f < tFormat.length; f++)
         if(title.indexOf(tFormat[f]) > -1)
           links[i].className += " " + classFormat[f];
     }
     // Dado que no siempre todos los enlaces tienen atributo "title"
     // comprobaremos, por si acaso, el atributo "href" obteniendo
     // la extensión del documento destino y comparándolo
     // con las declaradas en el array Format.
     var ini = links[i].href.length-4;
     var fin = links[i].href.length;
     var wFormat = links[i].href.substring(ini,fin).toLowerCase();
     for(var f = 0; f < Format.length; f++)
       if(wFormat.indexOf(Format[f]) > -1) {
         links[i].className += " " + classFormat[f];
          // Si no tiene el atributo "title" se lo añade
          if(!links[i].getAttribute("title"))
             links[i].setAttribute("title", tFormat[f])
       }

   }
 }
}

Finalmente cargamos el script:

window.onload = enlaces;

Caso desarrollado.- El contenido del documento se estructura en tres áreas o grupos funcionales: contenido específico, menú de navegación principal y un área de carácter transversal al sitio (relacionada bien con el documento actual, como podrían ser noticias de la sección, bien con el sitio web o portal, como por ejemplo enlaces de interés relacionados con la temática del portal o un conjunto de banners).

La organización del contenido en el código se debe establecer en función de su nivel de especificidad y relevancia con respecto a la página actual. Así, el grupo de información específico del documento debería aparecer primero en el código, seguido del área de caracter transversal si esta se relaciona específicamente con la información anterior y varía en función del contenido. A continuación vendría el menú de navegación principal. En el caso de que la información transversal sea común a todo el sitio y no tenga caracter específico en cada sección, esta se dispondrá al final precedida por el menú. En todos los casos se deberían crear enlaces cuya finalidad sea la de poder moverse por el documento saltando entre cada uno de los tres grupos para ir al siguiente o al anterior.

Tratando de conseguir un código lo más limpio y óptimo, el planteamiento del mismo es el siguiente:

1. <div id="cabecera">…</div>
2. <div id="contenido1">Contenido principal…</div>
3. <div id="contenido2">…</div>
4. <div id="contenido3">…</div>
5. <div id="pie">…</div>

Se han añadido una cabecera y un pie al ser esta una de las situaciones más comunes que se puede dar. Se emplean contenedores genéricos de bloque (div) para mostrar el ejemplo. En el caso de que estos incluyesen un único bloque (por ejemplo, una lísta), no serían necesarios, pues el identificador se podría aplicar directamente sobre él. Por el afán de conseguir un código límpio y óptimo, no se emplean contenedores que agrupen a uno o más de estos.

El marcado aplicado y su organización se ha mantenido intacto entre los ejemplos. Los estilos que se han aplicado de forma genérica se han incluido en una css común. El conjunto de estilos específicos para cada uno se ha incluido dentro de la cabecera del documento para facilitar su revisión. En todos los casos se ha mantenido el bloque de contenido principal con un comportamiento fluido.

Se ha utilizado el selector universal para aplicar márgenes a los primeros descendientes del bloque llamado “contenido1″. Dado que no todos los navegadores reconocen correctamente el pseudoelemento “:first-child“, se ha recurrido a aplicar las propiedades a todos los descendientes del bloque y luego anulárselas a todos los descendientes cuyo padre sea descendiente del mismo. Se pueden emplear otros métodos, como por ejemplo el uso de el pseudoelemento anteriormente citado junto a comentarios condicionales para Internet Explorer (IE). Otra forma hubiera sido crear un bloque dentro de “contenido1 ” y aplicar los estilos necesarios sobre este. Se ha evitado este método para conseguir un marcado más límpio y sin la presencia de elementos cuya finalidad sea servir en la maquetación. En realidad, la/s propiedad/es que se podrían ver modificadas para los descendientes son los márgenes laterales, propiedades fácilmente controlables, con lo que la solución propuesta se considera la más optima para este caso.

Es importante tener en cuenta qué propiedades y atributos se han declarado de cara a la aparición de posibles efectos inesperados al aplicar estilos. Por ejemplo, en IE, cuando se incluyen listas dentro de elementos flotados y posicionados en relativo, no se muestran los estilos aplicados al fondo ni los colores aplicados a los bordes (esto se puede subsanar posicionándolas en relativo).

La idea es conseguir un layout a tres columnas con un orden determinado en función de las necesidades del sitio.

Los diferentes layouts se muestran organizados en función del orden de los bloques y de la característica fluida de los mismos. La fluidez de los bloques se consigue definiendo su ancho en porcentaje (siendo para todos los ejemplos un 20% del total de su contenedor) y la riguidez en unidades absolutas (siendo en todos los ejemplos 150px). Así mismo, en lugar de utilizar unidades absolutas, se podrían utilizar unidades relativas (em). Todo dependerá de las necesidades particulares de cada caso:

Orden en el layout 1 2 3

• Ejemplo de diseño fluido: Fluido Fluido Fluido
• Ejemplo de diseño híbrido: Fluido Rígido Fluido
• Ejemplo de diseño híbrido: Fluido Fluido Rígido
• Ejemplo de diseño híbrido: Fluido Rígido Rígido

Orden en el layout 1 3 2

• Ejemplo de diseño fluido: Fluido Fluido Fluido
• Ejemplo de diseño híbrido: Fluido Fluido Rígido
• Ejemplo de diseño híbrido: Fluido Rígido Fluido
• Ejemplo de diseño híbrido: Fluido Rígido Rídigo

Orden en el layout 2 1 3

• Ejemplo de diseño fluido: Fluido Fluido Fluido
• Ejemplo de diseño híbrido: Rígido Fluido Fluido
• Ejemplo de diseño híbrido: Fluido Fluido Rígido
• Ejemplo de diseño híbrido: Rígido Fluido Rígido

Orden en el layout 2 3 1

• Ejemplo de diseño fluido: Fluido Fluido Fluido
• Ejemplo de diseño híbrido: Rígido Fluido Fluido
• Ejemplo de diseño híbrido: Fluido Rígido Fluido
• Ejemplo de diseño híbrido: Rígido Rígido Fluido

Orden en el layout 3 1 2

• Ejemplo de diseño fluido: Fluido Fluido Fluido
• Ejemplo de diseño híbrido: Fluido Fluido Rígido
• Ejemplo de diseño híbrido: Rígido Fluido Fluido
• Ejemplo de diseño híbrido: Rígido Fluido Rígido

Orden en el layout 3 2 1

• Ejemplo de diseño fluido: Fluido Fluido Fluido
• Ejemplo de diseño híbrido: Fluido Rígido Fluido
• Ejemplo de diseño híbrido: Rígido Fluido Fluido
• Ejemplo de diseño híbrido: Rígido Rígido Fluido

En alguno de los casos y para algún navegador (como puede ser Internet Explorer) pudiera darse un comportamiento anómalo al redimensionar la ventana. Básicamente, el comportamiento incorrecto se debe a que aunque se le indique al contenedor cuál debe ser su ancho, al rediemensionar, el texto influye empujando ligéramente los bordes del mismo. Si el conjunto de bloques han de ocupar el 100% del contenedor, podría ocurrir que uno de los que tenga dimensiones relativas, por el efecto antes mencionado, ocupase algo más de lo que debe, empujando a los demás, los cuales, al estar flotados y no caber, saltan hacia abajo. Para darle solución se puede declarar una dimensión en uno de ellos ligéramente inferior a la ideal (por ejemplo, 19.9% en lugar de 20%).

Supuestamente, el tamaño de fuente debería heredarse del elemento padre. Por casualidad (no sabemos quien lo dijo), hemos sabido que los elementos reemplazados (basicamente, controles de formulario, input) no siguen este comportamiento (algunas veces). Aquí estamos para daros la solución.

Se trata de realizar una batería de pruebas para determinar un patrón de comportamiento entre diferentes navegadores y proporcionar una solución compatible con todos ellos.

La solución, al final.

La lista de navegadores utilizada es la que sigue:

• Internet Explorer 5.5
• Internet Explorer 6
• Internet Explorer 7
• Mozilla Firefox 1.5.0.3 (W)
• Opera 8.54 (W)
• Mozilla Firefox 1.5.0.3 (L)
• Opera 9 (L)
• Konqueror 3.5.2
• Galeon 2.0.1

La prueba consiste en realizar diferentes cambios en las propiedades de fuente aplicadas a los elementos del siguiente código:

<p>Lorem ipsum dolor sit amet, consectetuer
adipiscing elit. Curabitur commodo. Phasellus quis dui ut est
scelerisque tempus. Sed faucibus nisl consequat dolor.
Vestibulum ornare laoreet nunc. Nunc euismod nulla et libero.
In dictum. Sed fringilla. Ut nisi neque, porttitor vitae, pretium vel,
sodales a, massa. Vestibulum orci. Quisque pellentesque, leo
vel posuere luctus, ante nisl lobortis mauris, in tempus pede
nibh at nibh. Etiam vehicula varius felis. Sed dapibus risus
nec ante. In ultricies. Ut lacinia felis ac eros. Integer
ultricies libero at velit. Vestibulum adipiscing venenatis
purus. Mauris consequat, libero eget lacinia aliquam, risus
nibh gravida ante, eu consequat neque nibh ut lorem. Nam quam.</p>
<form>
	<p>
		<input type="text" name="nombre" value="Lorem" />
	</p>
</form>

A continuación se ofrecen los enlaces a las distintas pruebas realizadas. A la derecha del enlace se indican las propiedades modificadas en cada caso.

1. Ejemplo 1 (no-style)
2. Ejemplo 2 (body: font-size)
3. Ejemplo 3 (body: font-family)
4. Ejemplo 4 (body: font)
5. Ejemplo 5 (body,input: font-family)
6. Ejemplo 6 (body: font-family / input: font-size)
7. Ejemplo 7 (body: font-family / input: font)
8. Ejemplo 8 (body: font-size / input: font-family)
9. Ejemplo 9 (body,input: font-size)
10. Ejemplo 10 (body: font-size / input: font)
11. Ejemplo 11 (body,input: font)
12. Ejemplo 12 (input: font-family)
13. Ejemplo 13 (input: font-size)
14. Ejemplo 14 (input: font)
15. Ejemplo 15 (body: font / input: font-family)
16. Ejemplo 16 (body: font / input: font-size)
17. Ejemplo 17 (body,input: font-family inherit)
18. Ejemplo 18 (body: font-family inherit/ input: font-size inherit)
19. Ejemplo 19 (body,input: font-size inherit)
20. Ejemplo 20 (body: font-size inherit/ input: font-family inherit)
21. Ejemplo 21 (body: font / input: font-family inherit)
22. Ejemplo 22 (body: font / input: font-size inherit)
23. Ejemplo 23 (input: font inherit)
24. Ejemplo 24 (input: font-size font-family inherit)
25. Ejemplo 25 (body,input: inherit)

Se ha observado un comportamiento similar entre navegadores Firefox y Galeón, también similar entre Konqueror e IE y con ciertas variantes tenemos a Opera.

Podemos concluir, con un porcentaje de acierto mínimo, que sería suficiente con definir un tamaño de fuente relativo (x.ej. 1em) para los input. Si se ha definido un tamaño de fuente en el cuerpo (font-size), el tamaño de fuente del control de formulario se redimensionará adecuadamente, y si no se ha definido nada en el cuerpo, se adaptará al tamaño de texto del resto del documento.

body {
	font-size: 62.5%;
}
input {
	font-size: 1em;
}

Seguramente se observará una pequeña diferencia, según el navegador utilizado. Para terminar de rematar la faena se puede igualar el tipo de fuente, mediante su correspondiente declaración en el cuerpo.

body {
	font: 62.5% Arial,Verdana,sans-serif;
}
input {
	font-size: 1em;
}