Haga click aquí para acceder a los sitios espejo
<IMG SRC="name.gif">Así de sencillo!. Esto es todo lo que se requiere.
Por supuesto, hacerlo mejor requiere un poco más.
Advertirás que cuando una página está cargando, el texto parará en un punto y esperará, después subirá deprisa a otro punto y esperará de nuevo. Bien, cada uno de los sitios donde se para es una imagen. Cuando el browser encuentra un etiqueta IMG o FIG necesita saber el tamaño de la imagen antes de poder continuar con el texto HTML. La única forma de hacer esto bajo HTML 2.0 era cargar la imagen. Esto significaba esperar al menos por la cabecera de gráfico del GIF antes de continuar. Para evitar esto, Netscape implementó los atributos ALTURA y ANCHURA de la etiqueta IMG para reservar la cantidad de espacio en la página para el gráfico, así el browser puede continuar inmediatamente renderizando el texto HTML. Con esta información Netscape y otros browsers pueden establecer la cantidad correcta de espacio y renderizar el texto alrededor de ella sin tener que traerla. Cada imagen que insertas, NO IMPORTA LO PEQUEÑA QUE SEA, debe tener un atributo de ALTURA y ANCHURA que se corresponda con la cabecera de pantalla lógica. Quedaría como esto:
<IMG SRC="name.gif" ALT="Text-only display" WIDTH=59 HEIGHT=127>
Netscape sometió los atributos ALTURA y ANCHURA al W3C Consortium y han sido incorporados a HTML 3.0. También te aconsejo que incluyas siempre una descripción apropiada en el atributo ALT. Este texto mostrará si la imagen no puede ser enviada a través de la red o si el usuario ha elegido un browser de sólo texto. Además, Netscape, a diferencia de otros browsers, escala automáticamente la imagen que ha traído de acuerdo a la ALTURA y ANCHURA especificadas. No se si este "escalado" es soportado por otros browsers.
Esta imagen linkada es un ejemplo de Animación por demanda. Esta
página HTML ha sido salvada dos veces. Una vez como GIFHTML.HTM: en
esta copia las animaciones son ensanchadas a la anchura indicada en
GIFHTML1.HTM. La página HTML es después salvada otra vez como
GIFHTML1.HTM y todos los links de GIFHTML1.HTM se cambian a GIFHTML.HTM. Esto
quiere decir que los links rebotarán entre idénticos hiperlinks
en dos documentos idénticos, esencialmente haciéndo un reload
desde la caché. Esta es una manera más elegante de decirle al usuario que pulse el botón de reload.
También hace que ciertas páginas sean mostradas en la posición correcta cuando son mostradas. Esto es muy importante en páginas más grandes que
el tamaño de la pantalla. Muchos reloads colocan al usuario en la parte superior de la
página, donde no verán la animación que está
más abajo. Aquí tenemos un ejemplo:
GIFHTML1.HTM
<HTML><BODY>
<A NAME="positioning_named_anchor"></A>
<p>The start of this section.
<p><A HREF="gifhtml2.htm#positioning_named_anchor">
<IMG SRC="starroll.gif" ALIGN=left WIDTH=59 HEIGHT=59></A>
The animation to be clicked on to play.
</BODY><HTML>
GIFHTML2.HTM
<HTML><BODY>
<A NAME="positioning_named_anchor"></A>
<p>The start of this section.
<p><A HREF="gifhtml1.htm#positioning_named_anchor">
<IMG SRC="starroll.gif" ALIGN=left WIDTH=59 HEIGHT=59></A>
The animation to be clicked on to play.
</BODY><HTML>
Los betas de Netscape tienen un problema GPF con los fotogramas y animaciones funcionando. Si pulsas desplazas la página (hacia delante o hacia atrás) tendrás un GPF si hay una animación funcionando. Si paras la animación antes de desplazarla evitará el GPF. El problema está resuelto en la versión 2.0.
Estoy todavía investigando como hacer una imagen nítida en un browser que no sea Netscape. La mayoría de los browsers mostrarán el primer fotograma de tu animación. Los browsers de HotJava AOL y SUN muestran solamente el último fotograma. Si este fotograma es presentable quedará bien (como en las rolling stars). Pero si tu primer fotograma no es una imagen completa (Como la primera versión de Interconnections) se verá mal. Aol solía mostrar sólo la frase "forming links around the world" en una gran caja transparente para la animación Interconnections. He arreglado esta animación.
Pincha la imagen para volver a mostrarla... La primera posibilidad que vi era
utilizar la animación GIF en una etiqueta LOWSRC, y el fotograma
estático del fichero en una etiqueta SRC como un GIF separado. Solamente
Netscape (que yo sepa) soporta la extensión Netscape de LOWSRC, así
sólo NN escogerá para mostrar la animación. La SRC es
mostrada por todos los browsers y debería ser un GIF estático normal.
EJEMPLO:
<IMG SRC="final_image.gif" LOWSRC="animated_gif.gif">
Si pinchas la imagen para hacer un reload, notarás que la imagen no
se muestra una segunda vez. Esto ocurre porque con el fichero LOWSRC y SCR cacheados,
son mostrados tan rápidamente que solamente el SRC es visible. Esta
imagen tiene un tiempo de espera LOWSRC. Cuando ejecuto esto localmente
en mi disco duro el truco LOWSRC funciona, incluso con reload, pero no
a través de una red o de Internet.
LOWSRC no presta atención al looping. Si hiciera esto resolvería nuestro problema. Estoy sugiriendo esto a Netscape. Creo que leí sobre un atributo (¿[que está siendo] añadido por Netscape?) sin tener en cuenta que no hay caché. Esto podría ayudar. Continúo investigándolo. Aprecio cualquier sugerencia.
Puedes utilizar la etiqueta FOTOGRAMA (FRAME), que solamente es reconocida por 2.0 o superiores, para enviar a los browsers páginas 2.0 y páginas que no son 2.0. Esto significa que debes tener páginas dobles, una animada y otra no. Si tienes espacio suficiente en tu servidor puedes dirigir el cliente al servidor 2.0 o al que no sea 2.0. Exactamente las mismas páginas (sin cambios en el código) tienen un GIF animado en una y GIFs no animados en la otra.
Lo siguiente sería la home page, y el index2.html contendría la misma información, pero sin la información de las etiquetas y con el gif animado al que se refiere.
<html>
<head>
</head>
<frameset ROWS="*,0">
<frame SRC="index2.html">
<frame>
<noframe>
<body>
<img src="standard.gif">
</body>
</html>
</noframe>
</frameset>
<html>
<head>
</head>
<body>
<img src="animated.gif">
</body>
</html>