WEB 2.0

WEB 2.0

Con el término Web 2.0, subrayamos un cambio de paradigma sobre la concepción de Internet y sus funcionalidades, que ahora abandonan su marcada unidireccionalidad y se orientan más a facilitar la máxima interacción entre los usuarios y el desarrollo de redes sociales (tecnologías sociales) donde puedan expresarse y opinar, buscar y recibir información de interés, colaborar y crear conocimiento (conocimiento social), compartir contenidos.

 

Podemos distinguir:

  • Aplicaciones para expresarse/crear y publicar/difundir: blog, wiki…
  • Aplicaciones para publicar/difundir y buscar información: podcast, YouTube, Flickr, SlideShare, Del.icio.us
  • Aplicaciones para buscar/acceder a información de la que nos interesa estar siempre bien actualizados: RSS, Bloglines, GoogleReader, buscadores especializados
  • Redes sociales: Ning, Second Life, Twitter
  • Otras aplicaciones on-line Web 2.0: Calendarios, geolocalización, libros virtuales compartidos, noticias, ofimática on-line, plataformas de teleformación, pizarras digitales colaborativas on-line, portal personalizado…

Frente a las tradicionales páginas web estáticas (Web 1.0) donde sus visitantes solo pueden leer los contenidos ofrecidos por su autor o editor, en la Web 2.0 todos los cibernautas pueden elaborar contenidos y compartirlos, opinar, etiquetar/clasificar… Esto supone una democratización de las herramientas de acceso a la información y de elaboración de contenidos, aunque como no todos los que escriben en Internet son especialistas, se mezclarán los conocimientos científicos con las simples opiniones y las falsedades.

Tecnológicamente, las aplicaciones Web 2.0 son servicios de Internet, por lo que no es necesario tener instalado un software cliente en el ordenador. Así, nuestra plataforma de trabajo es la propia página web, que nos suministra herramientas on-line siempre disponibles y nos proporciona espacios de trabajo colaborativo.

¿Existe tecnología Web 2.0?
Aunque las barreras son difusas, en la propia WEB existen artículos al respecto. Entre ellos me han resultado interesantes los siguientes:

Podemos considerar tecnologías Web 2.0 las siguientes:

  • · CSS (Separación de Diseño y Contenido)
  • · RSS, RDF, ATOM (Sindicación y agregación de contenidos)
  • · AJAX (Aplicaciones Web basadas en HTML y XML con componentes asíncronos)
  • · JAVA WEB START, FLEX, LASZLO, FLASH (Clientes Ricos Ligeros no HTML)
  • · SOAP, REST, JCC (Servicios Web)
  • · SSO, Registro, Federación de Identidad (Autenticación, Autorización y Seguridad en el acceso a las Aplicaciones WEB)
  • · CAPTCHA (Palabra aleatoria y distorsionada sólo legible para ojos humanos que sirve para evitar el acceso de robots)
  • · JAVASCRIPT, RUBY, PYTHON, PHP (Lenguajes de Script)

¿En qué nos sirve la Web 2.0?

  • El uso de el término de Web 2.0 está de moda, dándole mucho peso a una tendencia que ha estado presente desde hace algún tiempo. En Internet las especulaciones han sido causantes de grandes burbujas tecnológicas y han hecho fracasar a muchos proyectos.
  • Además, nuestros proyectos tienen que renovarse y evolucionar. El Web 2.0 no es precisamente una tecnología, sino es la actitud con la que debemos trabajar para desarrollar en Internet. Tal vez allí está la reflexión más importante del Web 2.0.
    Yo ya estoy trabajando en renovar y mejorar algunos proyectos, no por que busque etiquetarlos con nuevas versiones, sino por que creo firmemente que la única constante debe ser el cambio, y en Internet, el cambio debe de estar presente más frecuentemente.
Anuncios

AJAX

AJAX

Desde hace un tiempo la palabra AJAX es la palabra de moda en el mundo del desarrollo de aplicaciones web.

El termino “Ajax” fue acuñado por Jesse James Garret en su articulo “Ajax: A  New  Approach to Web Applications”, es un artículo en Inglés excelente que vale la pena traducir por completo.

Ajax no es una tecnología. Es realmente muchas tecnologías, cada una floreciendo por su propio mérito, uniéndose en poderosas nuevas formas.

AJAX incorpora:

El modelo clásico de aplicaciones Web funciona de esta forma: La mayoría de las acciones del usuario en la interfaz disparan un requerimiento HTTP al servidor web. El servidor efectúa un proceso (recopila información, procesa números, hablando con varios sistemas propietarios), y le devuelve una pagina HTLM al cliente.

Este es un modelo adaptado del uso original de la Web como un medio hipertextual, pero como fans de “The Elements of User Experience” sabemos, lo que hace a la Web buena para el hipertexto, no la hace necesariamente buena para las aplicaciones de software.

El modelo tradicional para las aplicaciones Web (izq.) comparado con el modelo de AJAX (der.).

Comunicación síncrona vs. Asíncrona

En el desarrollo clásico tanto de aplicaciones como sitios web la comunicación con el usuario es síncrona respecto de las interacciones del usuario, es decir:

1.El usuario realiza una petición al servidor.
2.El servidor envía la página solicitada.
3.El usuario comienza a “leer” la página.
4.Llega un momento dado en el cual el usuario desea cambiar de página y mediante formularios o links realiza una petición al servidor volviendo al paso número 1.

En cambio la comunicación asíncrona no implica sincronismo ante los eventos del usuario, sino que ante cualquier evento del usuario nosotros podemos proceder en consecuencia, es decir:

1.El usuario realiza una petición al servidor
2.El servidor envía la página solicitada
3.El usuario comienza a “leer” la página
4.Llega un momento dado en el cual el usuario quiere cambiar de página o alterar la información que contiene la misma. En ese momento dado la aplicación teniendo definidos los eventos posibles actúa en consecuencia a la interacción que haya podido suceder. Entonces podremos cambiar al usuario de página, o por el contrario modificar la misma para satisfacer al usuario. Estos cambios no implican cambiar de página.

 

Es por esto que una aplicación ajax termina con la idea “arrancar-frenar-arrancar-frenar”. Cada interacción de un usuario generaría un requerimiento HTTP para poder mostrar la nueva información, pero mediante ajax las peticiones al servidor pueden denegarse al “motor ajax” que es quien procesaría las peticiones contra el servidor, permitiendo o no al usuario interactuar con la página mientras el servidor está procesando la información, evitando de este modo los tiempo de carga en los cuales el usuario ve como su reloj de arena da vueltas mientas su navegador trata de componer la nueva página mientras recibe la información del servidor.

 

 

Ejemplos prácticos en producción 

Flickr Yahoo.-

Es un espacio gratuito donde todo el mundo puede subir sus fotos y exponerlas al resto del mundo. En un principio se utilizaba macromedia flash para poder mostrar las fotos, hacerlas rotar , insertar comentarios sobre ellas etc….

Desde hace ya un tiempo incorpora ajax haciendo la navegación mas ligera , accesible e intuitiva.  A día de hoy flickr cuenta con más de un millón de miembros, los cuales interactúan gracias a ajax con sus imágenes en tiempo real. Uno de los mejores detalles que incorpora flickr es la posibilidad de editar el título y  descripción ( entre otros ) en tiempo real sin necesidad de seleccionar la foto, encaminar al usuario a una página de edición donde rellenará un formulario con la nueva información.
Flickr permite pulsando en el título de la imagen convertir el mismo en un formulario, tras editar el título y pulsar el botón de guardar todo resto de formulario desaparece volviendo a la vista normal de la página. En ese momento la nueva información queda guardada en la base de datos para ser consultada por cualquier otro visitante. Este ejemplo demuestra que el peso de la aplicación no tiene porqué ( como suponíamos) crecer sustancialmente sino al contrario, produciéndose una reducción considerable en la información intercambiada entre servidor y cliente.

Google Suggest.-

Google Suggest permite comprobar instantáneamente el numero de resultados que una búsqueda va a tener mientras se está escribiendo la misma. ¿Útil?¿Pesado para el servidor? … si google puede, no es problema de ajax sino de los recursos a emplear.

Este ejemplo demuestra la utilidad de ajax para realizar búsquedas rápidas (ej: Datos personales, números de teléfono) o solucionar problemas a la hora de auto completar campos específicos dentro de formularios.

En la parte práctica copiaremos el ejemplo de google para buscar páginas web haciendo un pequeño código donde buscaremos el número de teléfono de una persona simplemente escribiendo una parte de su nombre o apellido.

Google Maps.-

Ajax es empleado en google maps para poder recargar pequeños cuadros de imagen que forman el plano visible. Por otro lado permite mostrar de una manera mas intuitiva herramientas de análisis , zoom etc…

La herramienta mas útil es el Drag & Drop que nos permite desplazarnos por la imagen arrastrándola en dirección contraria a donde queremos dirigirnos.

Yahoo!

 

 Oddpost (http://oddpost.com/learnmore)

El equipo de webmail Oddpost actualmente están trabajando en

rediseñar Yahoo! Mail siguiendo la filosofía AJAX.

Gmail

 

A la hora de hablar de Gmail, solo quiero hacer un comentario(reflexión personal)… Si gmail fuese de código abierto y se pudiese instalar en cualquier servidor como cliente de webmail… ¿quien usaría Squirremail , neomail o cualquier otro… ?

¿Para qué nos sirve AJAX ?

Ajax nos sirve principalmente para diseñar y programar interfaces de usuario mucho más haya de la web , rompiendo las limitaciones que la “sincronía” supone y abriendo una nueva puerta que nos permitirá desarrollar aplicaciones que en un principio solo podrían concebirse para el escritorio, en aplicaciones web. Este cambio permitirá complementar aplicaciones de escritorio con aplicaciones similares con el plus de la universalidad de Internet permitiendo acceder a información de manera remota pero siempre con una interface similar y un numeroso grupo de utilidades que revalorizarán el producto convirtiendo cualquier desarrollo en algo más que una “página web”.

 Ventajas / Desventajas

Desventajas

•El cliente necesita un navegador que soporte javascript .Hoy por hoy la mayoría de los navegadores soporta JavaScript. Internet Explorer, Mozilla, Firefox, Safari etc… Para esta desventaja tenemos una “excusa” , no estamos hablando de desarrollar páginas web con ajax, sino aplicaciones web, y como toda aplicación tiene unos requisitos mínimos, y siendo este javascript tampoco se discrimina un espectro muy amplio de usuarios.

•El mal uso de ajax/javascript puede mal emplearse sobrecargando el servidor de peticiones ej: Si hacemos que cada milisegundo haga una consulta con una base de datos… al administrador del sistema le pueden surgir instintos asesinos.

Ventajas

•Nos permite diseñar interfaces muchísimo mas dinámicas acercándonos a “aplicaciones de escritorio”.

•La comunicación asíncrona con el servidor nos permite varias cosas que reducen el “peso de la página” / “lineas de código que el cliente tiene que descargarse”

•Campos de select, si las opciones son muchas… no es necesario transmitirlas en la primera carga de la página, podemos producir la lista de opciones cuando el cliente pulse sobre el des plegable. Otra solución es hacer una búsqueda dinámica.

•La navegación por la aplicación mediante ajax nos permite evitar al cliente descargar la cabecera de todos los “documentos”,”pantallas” <html><head><tit….. etc… Podemos cambiar el contenido de cualquier objeto del DOM dinámicamente ante los eventos que controlamos con javascript.

•No requiere plugins o capacidades específicas de ciertos navegadores.

•Las aplicaciones son más interactivas, responden a las interacciones del usuario más rápidamente, al estilo desktop

•Se reduce el tamaño de la información intercambiada

Que hacer / Que NO hacer con ajax

Ajax puede parecernos útil o no , pero como en todos los aspectos de la vida, de nada se puede abusar. Por muy útil, potente o maravilloso que nos parezca no podemos utilizarlo en el 100% de la página sino para pequeños detalles donde aporte novedades y se diferencie del resto de productos.

Tampoco podemos utilizar ajax si nuestro objetivo es la accesibilidad, los requisitos mínimos son “mínimos” pero no podemos confiar a la suerte que todos nuestros clientes tengan un navegador que soporte javascript.
Por esto es necesario controlar las personas que entran a nuestra página, porque de lo contrario se encontraran con una aplicación que simplemente “no hace nada”.

Limites de Ajax

Al entender ajax “manda de una patada” los limites de la web muy lejos. Ajax nos permite hacer interfaces tan dinámicas como siempre hemos deseado pero la inaccesibilidad de flash, plugins de java, etc… no nos dejaban llegar.

Por otro lado a nivel “personal” ajax nos permite hacer muchas más cosas a las que estamos acostumbrados. Es por esto y por su “juventud” que es un espacio muy abierto para la innovación. Los limites personales los pone la imaginación de cada uno.

Estos limites “personales” pueden sufrir un placare tecnológico. Nos encantaría poder tener páginas web actualizadas al enano segundo donde todos los visitantes pudiesen intercambiar información y se refrescasen las ventanas de todos ellos mientras suben archivos y editan Bases de datos mientras graban ficheros de configuración. Pero hay que tener presente que del lado servidor, toda esa interactividad supone gastos cuantiosos. Es necesario llegar a un equilibro entre innovación, recursos y accesibilidad de los clientes.

EN CONCLUSION : AJAX, en resúmen, es el acrónimo para Asynchronous JavaScript + XML y el concepto es: Cargar y renderizar una página, luego mantenerse en esa página mientras scripts y rutinas van al servidor buscando, en background, los datos que son usados para actualizar la página solo re-renderizando la página y mostrando u ocultando porciones de la misma.

Aprendiendo mas de HTML5

DEFINICION:

HTML 5 (HyperText Markup Language, versión 5) es la quinta revisión importante del lenguaje básico de la World Wide Web, HTML. HTML 5 especifica dos variantes de sintaxis para HTML:

Un «clásico» HTML (text/html), la variante conocida como HTML5 y una variante XHTML conocida como sintaxis XHTML5 que deberá ser servida como XML (XHTML) (xhtml+xml).

Esta es la primera vez que HTML y XHTML se han desarrollado en paralelo.

Exactamente HTML 5, ya que no es simplemente una nueva versión del lenguaje de marcación HTML, sino una agrupación de diversas especificaciones concernientes a el desarrollo web. Es decir, HTML 5 no se limita sólo a crear nuevas etiquetas, atributos y eliminar aquellas marcas que están en desuso o se utilizan inadecuadamente, sino que va mucho más allá.

HISTORIA

Durante sus primeros cinco años (1990-1995), HTML pasó por una serie de revisiones principalmente alojados en primer lugar en el CERN y, a continuación, en la IETF.

Un primer intento abortado a extender HTML en 1995 conocido como HTML 3.0, hizo camino a un enfoque más pragmático, conocido como HTML 3.2, que fue completado en 1997. Luego nació la idea del HTML4 llegando a la conclusión en 1998.

En este momento, el número de miembros del W3C decidió detener la evolución HTML y en su lugar comenzar a trabajar en un XHTML equivalente, llamado basado en XML. A qui comenzó con una reformulación del HTML4 en XML, conocido como XHTML 1.0, que no añadió nuevas características excepto la serialización nueva, y que fue completada en el año 2000.

Alrededor de la época en que la evolución del HTML se detuvo en 1998, partes de la API para HTML desarrollado por proveedores de navegador se especificaron y publicaron bajo el nombre de DOM Nivel 1 (en 1998) y DOM Nivel 2 Core y DOM Nivel 2 HTML (comenzando en el año 2000 y culminando en 2003). Estos esfuerzos, a continuación, apagando, con algunas especificaciones de DOM Level 3, publicados en 2004, pero el grupo de trabajo se cierra antes de que se completaron todos los borradores de nivel 3.

En 2003, la publicación de XForms, una tecnología que se posicionó como la próxima generación de formularios Web forms, despertó un interés renovado en la evolución de HTML por sí mismo, en lugar de encontrar reemplazos para él. Este interés recae desde la realización despliegue de ese XML como un sitio Web de tecnología se limitaba a enteramente nuevas tecnologías (como RSS y Atom posterior), en lugar de como un sustituto de los existentes implementado tecnologías (como HTML).

Una prueba de concepto para demostrar que era posible extender las formas del HTML4 para proporcionar muchas de las características que XForms 1.0 introducido, sin necesidad de que los exploradores para implementar motores de procesamiento que eran incompatibles con las páginas HTML Web existentes, fue el primer resultado de este renovado interés. En esta etapa inicial, mientras que el proyecto ya estaba disponible públicamente, y entrada ya fue siendo solicitada de todas las fuentes, la especificación fue sólo bajo copyright de Opera Software.

La idea de que debe abrirse de evolución del HTML fue probada en un taller de W3C en 2004, donde algunos de los principios que subyacen en la obra de HTML5 , así como la propuesta de proyecto principios antes mencionados que abarca funciones sólo relacionadas con las formas, se presentaron a la W3C conjuntamente por Mozilla y opera. La propuesta fue rechazada debido a que la propuesta entra en conflicto con la dirección previamente elegida para la evolución de la Web.
Poco después, Apple, Mozilla y Opera conjuntamente anunciarón su intención de seguir trabajando en el esfuerzo bajo el paraguas de un nuevo lugar llamado el WHATWG (Web Hypertext Application Technology Working Group).

El WHATWG se basa en varios principios fundamentales en particular que:

  • Las tecnologías tienen que ser compatible con versiones anteriores.
  • Que las especificaciones e implementaciones que coinciden incluso si esto significa cambiar la especificación, en lugar de las implementaciones, y que deben ser las especificaciones detalladas suficiente las implementaciones puede lograr interoperabilidad completa sin ingeniería inversa entre sí.

Este último requisito necesario en particular que el ámbito de la especificación de HTML5 incluye lo que anteriormente había sido especificado en tres documentos separados: HTML4, XHTML1 y DOM2 HTML.

En 2006, el W3C indicó un interés para participar en el desarrollo de HTML5, después de todo y en 2007 formó un grupo de trabajo fletado para trabajar con el WHATWG sobre el desarrollo de la especificación HTML5. Apple, Mozilla y opera permitió el W3C publicar la especificación bajo los derechos de autor del W3C, manteniendo una versión con la licencia menos restrictiva en el sitio WHATWG.

Desde entonces, ambos grupos han estado trabajando juntos.

La especificación HTML publicado por el WHATWG no es idéntica a esta especificación. En el momento de esta publicación, las principales diferencias eran que la versión WHATWG incluye características no incluidas en esta versión de W3C: algunas de las características que se hayan omitido, pero podrán ser considerados para futuras revisiones de HTML más allá de HTML5; y otras características fueron omitidos porque en el W3C se publican como especificaciones separadas.

DIFERENCIAS ENTRE HTML4 Y HTML5

NOVEDADES DE HTML 5 

HTML 5 incluye novedades significativas en diversos ámbitos. Como decíamos, no sólo se trata de incorporar nuevas etiquetas o eliminar otras, sino que supone mejoras en áreas que hasta ahora quedaban fuera del lenguaje y para las que se necesitaba utilizar otras tecnologías.

  •  Estructura del cuerpo: La mayoría de las webs tienen un formato común, formado por elementos como cabecera, pie, navegadores, etc. HTML 5 permite agrupar todas estas partes de una web en nuevas etiquetas que representarán cada uno de las partes típicas de una página.
  •  Etiquetas para contenido específico: Hasta ahora se utilizaba una única etiqueta para incorporar diversos tipos de contenido enriquecido, como animaciones Flash o vídeo. Ahora se utilizarán etiquetas específicas para cada tipo de contenido en particular, como audio, vídeo, etc.
  •  Canvas: es un nuevo componente que permitirá dibujar, por medio de las funciones de un API, en la página todo tipo de formas, que podrán estar animadas y responder a interacción del usuario. Es algo así como las posibilidades que nos ofrece Flash, pero dentro de la especificación del HTML y sin la necesidad de tener instalado ningún plugin. Puedes conocer más sobre este nuevo elemento en el manual de canvas que estamos creando en DesarrolloWeb.com
  •  Bases de datos locales: el navegador permitirá el uso de una base de datos local, con la que se podrá trabajar en una página web por medio del cliente y a través de un API. Es algo así como las Cookies, pero pensadas para almacenar grandes cantidades de información, lo que permitirá la creación de aplicaciones web que funcionen sin necesidad de estar conectados a Internet.
  •  Web Workers: son procesos que requieren bastante tiempo de procesamiento por parte del navegador, pero que se podrán realizar en un segundo plano, para que el usuario no tenga que esperar que se terminen para empezar a usar la página. Para ello se dispondrá también de un API para el trabajo con los Web Workers.
  •  Aplicaciones web Offline: Existirá otro API para el trabajo con aplicaciones web, que se podrán desarrollar de modo que funcionen también en local y sin estar conectados a Internet.
  •  Geolocalización: Las páginas web se podrán localizar geográficamente por medio de un API que permita la Geolocalización.
  •  Nuevas APIs para interfaz de usuario: Temas tan utilizados como el “drag & drop” (arrastrar y soltar) en las interfaces de usuario de los programas convencionales, serán incorporadas al HTML 5 por medio de un API.
  •  Fin de las etiquetas de presentación: Todas las etiquetas que tienen que ver con la presentación del documento, es decir, que modifican estilos de la página, serán eliminadas. La responsabilidad de definir el aspecto de una web correrá a cargo únicamente de CSS.

 

ELEMENTOS CAMBIADOS

Estos elementos de HTML5 son imcompatibles con HTML4.

  • El elemento <a /> sin href ahora creará un enlace al sitio.
  • El elemento <address /> es ahora un nuevo concepto de sección.
  • El elemento <b /> ahora representa un trozo de texto a ser estilizado sin ninguna importancia.
  • Para elementos <label /> el navegador no debe mover el foco desde la etiqueta al control a menos que el comportamiento sea estandar para el interfaz utilizado en la plataforma.
  • <menu /> ha sido redefinido para ser usado con los actuales menús.
  • El elemento <small /> ahora representa una impresión pequeña.
  • El elemento <strong /> definitivamente representa el enfasis puesto en trozo de nuestro texto.

ELEMENTOS ELIMINADOS

Como decía, estos son los elementos eliminados y las razones de por qué son prohibidos:

  • Los siguientes elementos (muy usados hace pocos años) se quitan de HTML5 porque son puramente presentacionales (no tienen semántica) y todo el tema estético se debe tratar con CSS:
    • § basefont
    • § big
    • § center
    • § font
    • § s
    • § strike
    • § tt
    • § u
  • Los elementos para trabajar con frames (frame, frameset y noframes) se quitan del estándar por razones obvias: afectan negativamente a la usabilidad y accesibilidad de la web. Además, prácticamente rompen la web, y si se necesita algo similar se puede acudir a los iframe, más potentes y mejor pensados.
  • El elemento acronym se elimina simplemente porque crea confusión sobre su uso, y los desarrolladores no entienden demasiado bien para qué usarlo. Las abreviaciones y acrónimos se pueden marcar con abbr, que sí se mantiene en el estándar.
  • El elemento applet se ha declarado obsoleto y hoy en día no se utiliza. El elemento object reemplaza sus funciones y es lo común hoy en día.
  • El elemento isindex se quita definitivamente. En la era de las cavernas se utilizaba para mandar información al servidor, pero con la llegada de los formularios su uso es arcaico y poco útil.
  • El elemento dir también se declara obsoleto (ya lo era en HTML4), y simplemente se recomienda usar listas normales con ul.
  • El elemento noscript se mantiene en HTML pero no en XML/XHTML, ya que su contenido está en HTML. No estoy muy de acuerdo con este movimiento, pero así será.

ATRIBUTOS ELIMINADOS

Para empezar, todos los atributos referentes a la presentación han sido eliminados, por la misma razón de antes: CSS sirve mejor ese propósito. Recuerdo que el atributo style (que contiene CSS) es ahora universal y puede ser aplicado a todos los elementos, así que si queremos indicar su presentación sin añadir una hoja de estilos aparte, tendremos que usar este atributo. Atención a la lista porque esto sí que es importante, ya que algunos de estos elementos son muy usados, aunque otros están muy obsoletos:

  • Atributo align en todos los elementos.
  • Atributos alink, link, text y vlink en el elemento body.
  • Atributo background en el elemento body.
  • Atributo bgcolor en los elementos table, tr, td, th y body.
  • Atributo border en todos los elementos.
  • Atributos cellpadding y cellspacing en el elemento table.
  • Atributos char y charoff en los elementos col, colgroup, tbody, td, tfoot, th, thead y tr.
  • Atributo clear en el elemento br.
  • Atributo compact en los elementos dl, menu, ol y ul.
  • Atributo frame en el elemento table.
  • Atributo frameborder en el elemento iframe.
  • Atributo height en los elementos td y th.
  • Atributos hspace y vspace en los elementos img y object.
  • Atributos marginheight y marginwidth en el elemento iframe.
  • Atributo noshade en el elemento hr.
  • Atributo nowrap en los elementos td y th.
  • Atributo rules en el elemento table.
  • Atributo scrolling en el elemento iframe.
  • Atributo size en el elemento hr.
  • Atributo type en los elementos li, ol y ul.
  • Atributo valign en los elementos col, colgroup, tbody, td, tfoot, th, thead y tr.
  • Atributo width en los elementos hr, table, td, th, col, colgroup y pre.

Como vemos, algunos de estos atributos sí que se mantienen para ciertos elementos, como la anchura y altura en las imágenes. Sin embargo estos no son los únicos atributos que se eliminan, también hay otros que se quitan por redundancia, por evitar confusiones, por su bajo uso o porque simplemente se han quedado obsoletos.

  • Atributo accesskey en los elementos a, area, button, input, label, legend y textarea.
  • Atributos rev y charset en los elementos link y a.
  • Atributos shape y coords en el elemento a.
  • Atributo longdesc en los elementos img y iframe.
  • Atributo target en el elemento link.
  • Atributo nohref en el elemento area.
  • Atributo profile en el elemento head.
  • Atributo version en el elemento html.
  • Atributo name en los elementos img y a. Para obtener un comportamiento similar se recomienda usar id.
  • Atributo scheme en el elemento meta.
  • Atributos archive, classid, codebase, codetype, declare y standby en el elemento object.
  • Atributos valuetype y type en el elemento param.
  • Atributo language en el elemento script.
  • Atributo summary en el elemento table.
  • Atributos axis y abbr en los elementos td y th.
  • Atributo scope en el elemento td.

OTROS CAMBIOS

  • Hay diversos elementos que no se eliminan por su extendida fama, pero que siendo un tanto ortodoxos deberían eliminarse. Para evitar esto los que están escribiendo el estándar han tenido que redefinir su definición, de tal forma que se tratan de manera similar pero semánticamente son diferentes.
  • Un ejemplo muy claro es u e i, muy usados pero que progresivamente pierden importancia frente a strong y em. Estos dos elementos, que indicaban negrita y cursiva respectivamente, pasan a definirse de una manera muy vaga para indicar un texto diferente en alguna manera al texto normal. Otros elementos se redefinen, particularmente me resulta curioso que se mantenga small mientras big se elimina. De cualquier manera, no es demasiado relevante para los desarrolladores web, en el sentido de que podrán seguir usándolos como ahora.

EJEMPLOS DE UNA APLICACION DE HTML5

Quake en HTML 5

Una aplicación impresionante de HTML 5 fue el port del juego Quake en un navegador.

Photobucket

Imagina de lo que son capaces 3 desarrolladores de Google… Han creado una versión del célebre Quake II corriendo en un navegador. Este Quake II GWT emplea HTML5 y WebGL para la aceleración gráfica.

CONCLUSIONES 

Tal y cómo hemos ido viendo, las novedades de HTML5 se centran en facilitar la implementación de aplicaciones web, avanzar hacia la web semántica y limpiar un poco toda la basura heredada de las anteriores versiones de HTML. Aunque todo eso parezca lejano, lo cierto es que muchos navegadores ya implementan algunas partes sueltas de HTML5, y ya existen varias páginas experimentales que juegan con estos elementos. Por ejemplo, cerramos este minucioso especial precisamente en el día en que Firefox 3.5 es lanzado, pero Safari, Opera, Chrome e incluso IE8 ya soportan algunas cosas.

La vida es hermosa

No nos cansamos de decir por que me sucede esto, por que ami pero sin embargo como somos de reclamones mientras que otros hermans como nosotros, que no tienen pies, manos, etc viven alegres y llenos de fortaleza y sin decir por que me s a mi. Solo para ser feliz es amar a Dios y para eso no se necesita ser el Prsidente de la Rpublica, ni el archi millonario del mundo solo se necesita tener amor en tu corazon.
Vota por la opcion 18 de Roberto y Katia

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!