Niquelao » Javascript

Los problemas del elemento

Sin embargo, si por un "descuido" olvidásemos la etiqueta de cierre de este elemento () 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 (), una imagen () o incluso con un vínculo a un recurso externo ().

).


¿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 (, , ), 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 
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ño
		
	
	Mes
		
	
	
				...
			
				...
			
				...
				
				...
			
		Enero 2007
		
		
		
			
				Lun
				Mar
		
		
			
				
					1
				
				
					2
				
			24
				25
		
	
	
		
			Diciembre
		
		
			Febrero
		
	
	
		
			2004
		
		
			2006
		
	
	
		Cerrar calendario
	

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?
Calendario accesible en javascript (innecesario pero útil)

Enero 2007
Lun	Mar
1	2
24	25



Y más formularios…  jarl!
Rumoroso — Tue, 02 Jan 2007 19:27:48 +0000
Tras la ya extensa saga “Retocando Formularios“, muchos pensaron (bueno, presuponiendo tanto lo de “muchos” como su capacidad para pensar) que no volvería a tratar sobre ellos… ¡Pues va a ser que no! He vuelto para tratar de mejorarlo, pero en esta ocasión desde el punto de vista de la accesibilidad.

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.
Y más formularios…  jarl!


Retocando Formularios, Episodio III (“El Retorno”)
Rumoroso — Sun, 17 Dec 2006 17:06:02 +0000
Después de tanto tiempo, quizás alguno de los tres (incluyendote a ti) lectores de niquelao pensaba que no volveríamos a escribir sobre los formularios…  evidentemente no nos conoce lo suficiente.
El episodio de hoy gira en torno a la idea de conseguir la validación del formato en el que han sido introducidos los datos en los campos de un formulario (o más de uno en el mismo documento, evidentemente).
Planteamiento
Conseguir un script de cliente con las siguientes características:

Reconocer el formato (tipo de dato y/o longitud) con el que hemos introducido los datos en el formulario
Reutilizable para más de un formulario por documento
No intrusivo
Sin modificar (o con una mínima modificación) el código de la página
Accesible para las ayudas técnicas tales como los lectores de pantalla

En episodios anteriores de “Retocando formularos”…
A las funcionalidades desarrolladas previamente en los episodios anteriores (Episodio I y Episodio II)…

Limpiar de caracteres introducidos por defecto y restaurarlos en su caso
Comprobar si se han rellenado los campos obligatorios y devolver el error correspondiente si es necesario
El script aplica su proceso de reconocimiento de la misma manera que lo haría un usuario (leyendo la información de cumplimentación del formulario (aportada por ejemplo en el propio label del campo)
Modificación mínima o nula del marcado

…se han añadido:

Comprobación de que se ha introducido un correo electrónico válido
Comprobación de que se ha introducido un mínimo de caracteres
Comprobación de que se ha introducido un número si es este el único formato posible

El script
Podéis probar el funcionamiento del script directamente en la página de ejemplo. En esta se han incluido tres formularios para demostrar que es reutilizable y no se interfieren entre ellos.
Si tras probarlo, os gusta tanto como para querer utilizarlo, o sois de los que quieren comprobar lo bien (o mal) que los demás hacen las cosas para sacarle pegas y criticar…  (tras esto último, debería haber unos segundos de silencio) …podéis descargarlo directamente.
¿Cómo se utiliza?
nota I: Antes de decir cómo se utiliza, es súmamente importante recordar que dado que esta validación se hace en el lado del cliente, siempre va a ser necesario hacer una validación en el servidor (no hacerlo os puede restar puntos…  ¿verdad Andrés?). La validación del lado de cliente nunca debería sustituir a la del servidor. Lo que aporta es una mejor experiencia de usuario al no implicar las demoras que el envío, comprobación y devolución de información llevan asociados.
nota II: Recordaros también que siempre se debe informar al usuario acerca de cómo ha de rellenar el formulario, y esto incluye la información de campos obligatorios y de los formatos de datos a introducir. Esta información debe presentarse antes del propio formulario y no se debe dar por sentado que el usuario la va a entender tan bien como la entendería un experto.
Retomando el tema introducido por el último encabezado… al comienzo del script estan declaradas unas variables. Estas son las que incluyen el texto que posteriormente se va a buscar en los label o en los controles de formulario y que servirá para identificar el formato
var for_req = '*'; // identifica el campo obligatorio
var for_mail = 'mail'; // identifica un campo como correo electrónico
var for_num = 'numero'; // identifica un campo como numérico
Los valores son los que se emplearán en el propio formulario y podrán incluirse en el contenido o la clase del elemento label o en la clase del control al que esta se asocie. Ej.:

    Nombre *
    


    Código Postal
    


    E-mail *
    

También se ha añadido una variable con el texto que determinará si un dato a introducir en el formulario debe tener una longitud mínima:
var for_min = 'minimo';
Este texto se deberá incluir en la clase del label o del campo, indicando inmediatamente detrás de él, y mediante el/los dígitos correspondiente/s, su valor. Ej.:

    Teléfono
    

Como se muestra en este último ejemplo, el sistema permite combinar más de una validación (a excepción de determinadas combinaciones ilógicas tales como el correo electrónico y el formato numérico).
A continuación, en el script están presentes dos variables que servirán para aplicar un estilo a los label y campos cuando estos no respeten las condiciones adecuadas de formato y obligatoriedad para su envío:
var labelerror = 'error';
var fielderror = 'error';
Estos valores son los nombres de las clases sobre las que declararemos estilos en la CSS. En este punto es necesario recordar  que con la ejecución del script no se ven alteradas ni la cascada ni la especificidad, con lo que deberemos tenerlo presente al establecer nuestras reglas en la hoja de estilos.
Es importante también tener en cuenta que deberemos aplicar un identificador al elemento form.
Rizando el rizo
Al igual que en el episodio anterior, cuando se crea el contenido que indica el/los error/es cometidos, el foco se traslada al comienzo de este. Esto se pensó teniendo en cuenta que tras pulsar el botón de envío, si ocurre un error, la información de este debería ser lo primero que se mostrase. Un usuario de navegador gráfico no tendría mucho problema en ello (generalmente), pero el usuario que utilizase un lector de pantalla, sin ese cambio del foco, continuaría leyendo el contenido que hay después del botón (¿lo cogéis?).
Además, el script trata de adaptar el lenguaje empleado para la información del error de tal manera que diferencie el singular del plural en función del número de errores encontrados, e incluso si lo que se introducen son caracteres generales o dígitos (en el caso de que el formato sea numérico). También se trataron de agrupar los errores sobre el mismo campo agrupando así la información y facilitando su comprensión y lectura. Puede parecer una forma de rizar el rizo un poco exagerada, pero… ¿por qué no utilizar correctamente el lenguaje?
Optimizando
Personalmente me gusta optimizar los códigos y eliminar lo que no sea necesario. En el script se incluyen determinados fragmentos que podrían ser eliminados, tales como la búsqueda dentro del contenido del label, de su clase y de la clase del campo al que este se asocia, del texto para comprobar si lo introducido sigue un formato adecuado. Si siempre introducimos el mentado texto en la clase del label, las demás búsquedas podrían eliminarse.
Un cambio de última hora (24 de diciembre de 2006)
Haciendo pruebas me di cuenta de que no había tenido en consideración que dentro del label pudiera haber un elemento de línea (tipo strong, span,…) o incluso que pudiera haber asociación implícita con el control de formulario al que se asocia. Esto originaría problemas, pues al crearse la lista de errores, se mostrarían las etiquetas correspondientes o el propio contenido del campo. Para evitarlo acabo de incluir en el script una función que extrae el contenido de las etiquetas a la par que las elimina, y además he añadido lo necesario para no mostrar el contenido del control de formulario.
Bueno, lo dejaré ya porque son las 14:19 del día de NocheBuena. Supongo que no es el momento de estar pensando en formularios y si en los seres querídos…  así que Feliz Navidad a todos.
Retocando Formularios, Episodio III (“El Retorno”)


Retocando Formularios (Episodio II)
Rumoroso — Thu, 14 Sep 2006 16:15:48 +0000
Siguiendo con el patrón que nos marca este mes de frenética actividad “blogera post-vacacional”, ha llegado el momento de acudir al Episodio II de la archiconocida saga “Retocando Formularios”.
El episodio de hoy nos presenta un script que comprueba antes del envio del formulario si se han rellenado todos los campos obligatorios. En caso negativo…   hace cosas muy chulas…
Planteamiento
Crear un script que reconozca los campos de formulario de obligada cumplimentación de la misma manera que lo reconocería el propio usuario (por ejemplo, lo del típico asterisco “*”).
El desarrollo
Partiendo de la idea de no aumentar el marcado del formulario con clases, identificadores, elementos,… que señalen al script lo que es obligatorio y de que el marcado utilizado es correcto y accesible (uso de elementos label asociados correctamente), se ha desarrollado un script que busca todos los label y reconoce en ellos la presencia del * (mundialmente conocido como * o “punto despeinado”).
El valor inicial de los campos obligatorios se almacena en una matriz. Esto permitirá comprobar posteriormente, antes del envío, si se ha modificado o no. También se almacenan la clase que tienen aplicados tanto el label como el campo obligatorio asociado. Esto último se hace para aplicar o restaurar (según sea el caso) una clase un otra en función de que la validación de como resultado el que uno de los campos no ha sido cumplimentado.
El script se ha creado teniendo en consideración la posible presencia de más de un formulario en la página (por ejemplo: un formulario de búsqueda en la barra de utilidades de la sección “formulario de contacto”).
Cuando se pulsa el botón de envío se realiza la comprobación. Si esta es positiva, el formulario se envía (lógicamente o de perogrullo). En el caso de ser negativa, se crea un párrafo con el mensaje que nosotros queramos y una lista con los campos que no han sido rellenados. Asimismo (casi pongo lo escribo como siempre: Así mismo), se aplica una clase al label y otra al campo obligatorio que lleva asociado un estilo declarado en la CSS.
Adicionalmente se ha añadido el comportamiento ya explicado en el Episodio I y que consiste en limpiar/restaurar los valores iniciales de los campos.
El ejemplo
En el caso de que os aburra tanta palabrería, podéis entreteneros con el ejemplo de funcionamiento que hemos desarrollado para este caso, o incluso podéis descargarlo (y sacarle “pegas”).
Problemas:
El resultado negativo de la validación crea contenido que se coloca al principio del formulario. Si estamos usando un lector de pantalla, este no lo leerá si no le mandamos para allí. Solucionado: Tras la creación de los elementos que avisan del error, se provoca un salto al inicio de estos (aprovechando la “id” del párrafo), con lo que lo siguiente que se leerá será el propio aviso seguido del formulario.
A pesar de su fama, no quiero utilizar el *. Solucionado: El script reconoce la presencia de lo que nosotros le indiquemos que busque. Además, se puede hacer que compruebe si se ha aplicado una clase concreta a los campos o a los label (muchas veces se destacan estos aplicando un estilo).
Supongo que habrá más problemas, por lo que si a alguien se le ocurre alguno…  que nos lo diga. Mientras tanto seguiremos pensado que hacemos las cosas REMATADAMENTE bien…
Concluyendo
A partir de ahora, cuando se quiera crear un formulario y validar los campos obligatorios, no hará falta cambiar el marcado ni añadir “cosas raras”. Únicamente será necesario hacer un formulario correcto (según los estádares W3C) y asociarlo el script.
Postdata
Se me olvidaba decir que la accesibilidad no está comprometida si no funciona javascript.
Por cierto, la validación del formulario siempre se debe hacer también del lado del servidor (que no se os olvide).
Retocando Formularios (Episodio II)


Retocando Formularios (episodio I)
Rumoroso — Tue, 05 Sep 2006 04:49:25 +0000
En numerosas ocasiones nos encontramos con campos de formulario que inicialmente incluyen un texto, bien sea con el objetivo de conseguir un nivel de accesibilidad AAA al pie de la letra (punto de verificación 10.4 de las WCAG 1.0), bien por ofrecer una ayuda al usuario indicándole el tipo de contenido a introducir.

Asimismo, en no menos casos, al recaer el foco sobre el campo en cuestión, el texto que había inicialmente se borra dejándonos escribir lo que deseemos. La cuestión es que si no escribimos nada…   ¿por qué no hacer que vuelva el texto inicial?. Tal vez luego quiera volver a ese campo de formulario para escribir algo.

Problema
Queremos restaurar el texto original de los campos del formulario.
Solución
Un script que guarde en una matriz dichos valores y que, al perder el foco el campo de formulario, permita restaurarlos.
El script
El script se detalla a continuación, pudiendo acceder al ejemplo demostrativo o incluso descargarlo.
Para poder utilizarlo, únicamente hay que enlazarlo en la cabecera del documento (). Además, la ausencia de funcionalidad del mismo a causa de que el navegador no lo soporte no implica pérdida alguna ni disminución de la accesibilidad para el usuario.
Lo primero es revisar todos los campos que vamos a controlar mediante este script:
var inputs = document.getElementsByTagName("input");
var textareas =  document.getElementsByTagName("textarea");
Guardamos los valores iniciales:
var valorinicial = new Array();
Asignamos a los campos en los que se puede introducir texto las funciones necesarias para vaciar su contenido o restaurarlo al original según las circunstancias:
function formulario() {
  for (var i = 0; i < inputs.length; i++) {
    if((inputs[i].type == "text") || (inputs[i].type == "password")) {
      valorinicial[inputs[i].id]=inputs[i].value;
       inputs[i].onfocus = function() {vacia(this.id,this.value)}
      inputs[i].onblur = function() {restaura(this.id,this.value)}
    }
  }
  for (var i = 0; i < textareas.length; i++) {
    valorinicial[textareas[i].id]=textareas[i].value;
    textareas[i].onfocus = function() {vacia(this.id,this.value)}
    textareas[i].onblur = function() {restaura(this.id,this.value)}
  }
}
Vaciamos los campos únicamente cuando su contenido sea el mismo que el inicial:
function vacia(id,valor){
  var targetElement = document.getElementById(id);
  var tipo = targetElement.type;
  switch ( tipo ) {
    case "text":
      if (valorinicial[id] == valor)
        targetElement.value = "";
      break
    case "password":
      if (valorinicial[id] == valor)
        targetElement.value = "";
      break
    case "textarea":
      if (valorinicial[id] == valor) {
        targetElement.innerHTML = "";
        targetElement.value = "";
      }
    break
  }
}
Restauramos el contenido de los campos en el caso de no haber introducido nada o únicamente espacios en blanco (y/o retornos de carro en los textarea):
function restaura(id){
  var targetElement = document.getElementById(id);
  var tipo = targetElement.type;
  switch ( tipo ) {
    case "text":
      if (targetElement.value.replace(/ /g, '') == '')
        targetElement.value = valorinicial[id];
      break
    case "password":
      if (targetElement.value.replace(/ /g, '') == '')
        targetElement.value = valorinicial[id];
      break
    case "textarea":
      revisa = targetElement.value.replace(/ /g, '');
      // Eliminamos saltos de línea y tabulaciones
      revisa = revisa.replace(/n/g, '')
      revisa = revisa.replace(/t/g, '')
      revisa = revisa.replace(/r/g, '')
      if (revisa == '') {
        targetElement.innerHTML = valorinicial[id];
        targetElement.value = valorinicial[id];
      }
      break
  }
}
…y finalmente cargamos la función:
window.onload = formulario;
Retocando Formularios (episodio I)


Identificando tipos de enlace
Rumoroso — Sun, 03 Sep 2006 17:40:44 +0000
Una buena práctica que afecta positivamente a la accesibilidad y usabilidad de nuestras páginas es la de identificar el tipo de enlaces que tenemos en nuestra web en función de su destino. Para ello, además de las correspondientes medidas a adoptar respecto a temas de accesibilidad, podríamos crear diferencias de estilo mediante la CSS (procurando siempre mantener la consistencia que permita identificar los enlaces como tal). Mediante esta práctica, los usuarios con acceso a los navegadores gráficos podrán reconocer si el documento al que van a acceder es, por ejemplo, un pdf o si el destino se encuentra fuera de nuestro portal.
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;
Identificando tipos de enlace


Script para intercambiar css
Rumoroso — Mon, 17 Jul 2006 18:25:20 +0000
La idea es tener un script que cambie la hoja de estilos que tenga actualmente asociado el documento por otra alternativa de forma dinámica.
Evidentemente se pueden pensar varias formas para conseguir tal fin. La ventaja que ofrece este sistema es que no inplica la recarga de la página para llevarlo a cabo. Con esto se consigue un efecto sensíblemente más rápido así como la posibilidad de efectuarlo sobre documentos que contengan campos de formulario sin implicar que el usuario pierda los datos introducidos.
Antes de seguir, podéis acceder a un ejemplo.
Este sencillo script se basa en la intervención de dos funciones. Una de ellas es la encargada de sustituir la actual hoja de estilos que tenga el documento asociado. La otra se encarga de generar el enlace necesario para que se ejecute la función anterior. El enlace para la ejecución del cambio se crea mediante un script en lugar de introducirlo en el código por cuestiones de accesibilidad. En el caso de que el navegador no soporte javascript, no se mostrará un enlace sin funcionalidad.
Para nuestro ejemplo hemos desarrollado una de las posibles formas de hacer el intercambio. En este caso se alternan dos hojas de estilo, pero podría hacerse que se sustituya directamente por la que queramos.
La función para cambiar la css:
function cambiacss(id){
	var targetElement = document.getElementById(id);
	//Se busca el fragmento "-print" que sabemos forma parte
	//del nombre de una de las css y se introduce esa css
	//o la alternativa en función del resultado
	if(targetElement.href.indexOf('-print') == -1) {
		targetElement.href="css/style-print-preview.css"
		return "vista normal";
 	}else{
		targetElement.href="css/style.css";
		return "vista preliminar";
	}
}
Se le pasa como parámetro la “id” del elemento link desde donde se enlaza la hoja de estilo. En función de cual sea la css que está enlazada se introduce una u otra. Además, la función devuelve el texto que aparecerá en el enlace que la ejecuta. En nuestro ejemplo se utiliza para pasar a mostrar una supuesta vista preliminar del documento actual (es necesario recordar que si esta fuese la supuesta vista de impresión, debería hacerse una css que se asocie al documento mediante un elemento link que incluya el atributo media=”print”. Echadle un vistazo al código de este documento para verlo.).
…y la función que crea el enlace:
function enlacecss(){
	var pie = document.getElementById("pie");
	parrafo = document.createElement("p");
	parrafo.innerHTML = 'Vista Preliminar';
 	pie.appendChild (parrafo);
}
Se crea un elemento “p” (párrafo) donde irá nuestro enlace. En el ejemplo se crea como parte del pie del documento. Como contenido del párrafo tendremos el enlace al que le asociamos en los eventos “onclick” y “onkeypress” la función de cambio de css. Finalmente hacemos que el script se ejecute al cargar la página:
window.onload = enlacecss;
Bueno, con esto termino, pues además de estar de vacaciones, hoy es mi aniversario de boda y no quiero ni imaginarme lo que puede pasar si mi mujer se entera de que estoy ante el ordenador…
Script para intercambiar css