Consultoria y Formacion Adobe

Terminamos este especial sobre HTML5 con la parte más desagradable (o agradable) del estándar: lo que se elimina. Es curioso que un montón de elementos comunes pasan a estar prohibidos en HTML5, por razones diversas que ahora veremos. Por esas mismas razones bastantes atributos han sido eliminados bien de un elemento concreto o de todos los elementos.

Sin embargo hay que aclarar estas prohibiciones, ya que hay dos caras en esta moneda. Por un lado los desarrolladores no pueden usarlos, si quieren que sus documentos sean HTML5 válidos. Por el otro lado, los navegadores tienen la obligación de implementarlos y soportarlos, para ser compatible hacia atrás con HTML4 y anteriores. Esta dualidad es muy interesante y nos ahorra bastantes problemas de una manera limpia definida en el estándar.

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 veis, 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.

Conclusiones

Tal y cómo habéis 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.

Ahora queda preguntarnos, ¿cuándo se acabará este estándar? Precisamente no hay ninguna fecha, y la condición para que HTML5 se considere estándar es, según la W3C, que al menos un navegador implemente todo HTML5 correctamente. De esta manera se asegura que todo el estándar es factible, que puede ser implementado. Para esto puede quedar dos o tres años, si todo va bien, pero nada es seguro.

Después de las dos primeras entregas de este repaso a HTML5 (parte I y parte II), llegamos a la parte dinámica del estándar, lo que se añade al DOM y a Javascript para conseguir aplicaciones web avanzadas. Por un lado tenemos diversas APIs, es decir, conjuntos de funciones y herramientas que implementan un propósito concreto. Por el otro lado tenemos varias funciones y atributos que sirven a propósitos más generales y que no se pueden enmarcar en una API concreta.

Nuevas APIs

No está claro que todas las APIs siguientes se vayan a incluir en el estándar HTML5 propiamente, de hecho seguro que alguna de ellas se separará creando un estándar propio dedicado. De cualquier forma, estas son las nuevas APIs que nacen o se desarrollan en HTML5:

• Una API para dibujar en 2D, que se podrá usar junto al nuevo elemento canvas. Básicamente, se pueden pintar elementos sobre un lienzo, de manera similar a lenguajes como Java.
• Una API para controlar los nuevos elementos multimedia, video y audio. Así podremos controlar la reproducción con código Javascript, algo interesante pero que puede dar más de sí.
• Una API para guardar datos localmente, utilísimo para que las aplicaciones web puedan trabajar sin necesitar conexión a Internet. Ese DOM storage está ya implementado en las últimas versiones de los grandes navegadores, así que dentro de poco podremos disfrutar de esta clase de aplicaciones sin necesidad de extensiones como Google Gears.
• Una API para que las aplicaciones web puedan enlazarse a protocolos o tipos de archivos MIME, otro añadido extremadamente útil. Esto permitiría abrir las fotos de tu disco duro directamente en una aplicación de retoque online, o un archivo mp3 en una biblioteca online, etc…
• Una API para editar los campos que sean editables, valga la rebuznancia. Esto permite controlar los elementos HTML que son editables por el usuario, tipo Word. Por ejemplo, Google Docs o editar HTML en emails será muy sencillo, y con esta API es trivial cambiar ese contenido con Javascript.
• Una API para controlar las acciones Drag & Drop sobre los elementos que se puedan arrastrar. Esto se puede conseguir actualmente con algunas librerías, pero con esta API el navegador lo permite de manera nativa y más poderosa.
• Una API para controlar el historial desde una aplicación web. Esto permitirá a las aplicaciones web que se muevan con Javascript añadir páginas al historial para que los botones Atrás-Adelante funcionen siempre.
• Una API para habilitar la comunicación entre varias “páginas web”. Es decir, si tenemos varios iframes externos en una web, podemos comunicarnos con ellos y compartir información de manera segura, por ejemplo con gadgets de Facebook o similares.

Novedades en el DOM

Se han añadido a los elementos del DOM nuevas funciones y atributos que facilitan su uso y permiten realizar acciones muy usadas. Aquí comentaré los más interesantes, que trabajan sobre el documento (HTMLDocument) o sobre cualquier elemento (HTMLElement).

• La función getElementsByClassName() se añade a todos los elementos y al documento. Su funcionamiento es similar a getElementsById(), pero en este caso selecciona todos los elementos del documento o de cierto subárbol del documento que contengan esa clase. Su definición es tan amplia que incluso elementos que contenga SVG o MathML pueden ser encontrados.
• El atributo classList está disponible para cualquier elemento, y contiene una lista con todas las clases que tiene ese elemento. Además contiene varios métodos que facilitan trabajar con esa lista: buscar, modificar, borrar, etc. Muy útil para trabajar con elementos que puedan tener más de una clase, es muy sencillo y muy conveniente de usar. Los enlaces también tienen un elemento similar adicional llamado relList que permite lo mismo pero con el atributo rel (como el famoso rel=”nofollow”).
• El atributo innerHTML se añade, por fin, al estándar. Prácticamente usado por todas las aplicaciones web y soportado por todos los navegadores, creo que todos los desarrolladores web lo conocen de sobra. Para aquellos que no lo conozcan, este atributo permite trabajar con el contenido de un elemento en texto plano, incluso cambiando elementos HTML que pueda haber. Igualmente, se añade a todos los elementos y al propio documento, pudiendo cambiar TODO el contenido de una web.
• Los atributos activeElement y hasFocus están disponibles sobre un documento, y permiten conocer qué elemento está activo y si el documento tiene el foco, respectivamente.
• La función getSelection() se aplica también al documento y devuelve un objeto con el texto y elementos que están seleccionados.
• El atributo designMode es otra novedad sobre el documento e indica/modifica que el documento pueda o no ser editado.
• La función execCommand() se aplica sobre el documento y permite ejecutar acciones o “comandos” típicos de edición de documentos. Por ejemplo, con este método se llamaría a los útiles copiar/pegar, pero también a otros típicos como crear un enlace o cambiar el color de un elemento. Como el anterior, la mayoría de estos comandos trabajan sobre elementos editables.

Con esto ya hemos acabado con todas las novedades de HTML5, al menos las más importantes e interesantes para los desarrolladores web. Pero aún nos queda una parte muy importante: los elementos y atributos que se eliminan del estándar y que formaban parte de HTML4 y anteriores. Son muchos y variados, y algunos pueden causar más de un dolor de cabeza, así que los dejamos para la cuarta y última entrega de este especial.

Si en la primera parte de este repaso a HTML5 os comentamos todos los nuevos elementos, ahora vamos a centrarnos en los nuevos atributos más interesantes. Al igual que como comentaba en la primera parte, hay que tener en cuenta que no es un estándar acabado, así que estas especificaciones pueden cambiar y cambiarán. También hay que tener en cuenta que estos no son todos los cambios, solo he seleccionado los relevantes para el día a día de un desarrollador web. Por último, habría que distinguir entre los atributos que solo afectan a un subconjunto de los elementos y los globales, que afectan a cualquier elemento.

Nuevos atributos

Los elementos ya existentes añaden nuevos atributos que permiten hacer cosas muy interesantes. Los más importantes o novedosos son:

• Atributo ping para el elemento a. Este atributo contiene una lista de URLs, las cuáles serán llamadas cuando un usuario haga click en ese enlace. Por ejemplo, un uso práctico sería para estadísticas.
• Atributo autofocus para los elementos de un formulario. Indica qué elemento de un formulario debe ganar el foco al cargar una página. Por ejemplo, en la página principal de Google la cajita de texto gana el foco automáticamente para ayudarnos a escribir sin usar el ratón.
• Atributo form para los elementos de un formulario. Indica a qué formulario pertenece este elemento, y permite poner un elemento de un formulario en cualquier parte de una página. Tal y como está ahora, todos los elementos deben ir dentro de <form>.
• Atributo required para los elementos de un formulario. Indica que es obligatorio rellenar un valor para enviar ese formulario, algo que hoy en día se comprueba con Javascript o en el servidor.
• Atributos autocomplete, min, max, multiple, pattern y step para los elementos input. Estos atributos indican que el valor del input debe cumplir ciertos requisitos, por ejemplo seguir cierto patrón.
• Atributo novalidate para el elemento form. Esto deshabilitará la validación de sus elementos, algo útil si se usa dinámicamente (es decir, con Javascript, activando y desactivándolo).
• Atributos formaction, formenctype, formmethod, formnovalidate, y formtarget para los elementos de un formulario. Estos atributos modifican los atributos del formulario si el elemento es usado (por ejemplo un botón es pulsado o un input es rellenado). Esto permite que dependiendo qué botón usemos podemos tratar el formulario en diferentes páginas usando solo un formulario, algo complicado en HTML4.
• Atributo scoped en el elemento style. Esto permite aplicar estilos solo a cierto subárbol del documento. Por ejemplo, imagina que tenemos un elemento con id igual a “cabecera”; si añadimos el atributo scoped a un style, los estilos contenidos en él solamente se aplicarán a ese elemento y a sus hijos.
• Atributo async en el elemento script. Con este atributo especificamos que el código interno se puede ejecutar en cualquier momento de la página, mejorando la velocidad de carga.
• Atributo manifest en el elemento html. Esto permite indicar nuevos elementos, sobre todo será útil en aplicaciones web.
• Atributo reversed en el elemento ol. De esta forma la lista será numerada en orden descendiente (3, 2, 1…).

Nuevos atributos globales

Además de los anteriores tenemos otros atributos que pueden ser aplicados a todos los elementos de un documento. Esto lo hacen especialmente conveniente si vamos a usar Javascript para modificarlos dinámicamente, ya que no tenemos que comprobar el tipo de elemento para usar los atributos comunes.

• Atributos id, class, style, title, lang y tabindex, ya existentes pero ahora permitidos en todos los elementos. Pues eso, los atributos más usados se vuelven universales.
• Atributo contenteditable, para indicar que el elemento es editable por el usuario. Muy interesante, ya que ahora podremos editar cualquier cosa de manera trivial para el desarrollador, no solamente los elementos de un formulario.
• Atributo contextmenu, para indicar un menú contextual sobre un elemento. Como veis, está todo muy pensado para las aplicaciones web.
• Atributos data-*, donde el asterisco puede ser cualquier nombre. Esto permite atributos personalizados, que luego podremos obtener con Javascript.
• Atributo draggable, para indicar que un elemento se puede arrastrar.
• Atributo hidden, para ocultar un elemento que ya no interesa.
• Atributo spellcheck, para indicar si el contenido de un elemento debe ser pasado por el corrector ortográfico.

Por supuesto estos no son todos los cambios, en próximas entregas explicaremos otros aspectos de este nuevo estándar.

HTML5 está llamada a ser el reemplazo del actual (X)HTML, una de las patas de la web desde su nacimiento. Precisamente en un momento en el que la web está lo suficientemente madura, este estándar aprende de los errores cometidos e intenta solucionar la mayoría de problemas con los que un desarrollador web se encuentra. Como muchas de sus novedades son interesantes y afectan directamente a la futura web, desde AnexoM te vamos a comentar en varios artículos los cambios más importantes, empezando por este artículo donde comentaremos los nuevos elementos.

Antes de seguir habría que aclarar que HTML5 sigue en borrador y lo seguirá estando durante algunos años más. El enfoque general ha cambiado bastante respecto a versiones anteriores de HTML, añadiendo semántica y accesibilidad implícitas, especificando cada detalle y borrando cualquier ambigüedad. También se tiene en cuenta que muchas páginas web actuales son dinámicas, pareciéndose más a aplicaciones que a documentos. Algo básico es que HTML5 está definido en base al DOM (la representación interna de una web con la que trabaja un navegador), dejando de lado la representación “real”, definiendo a la vez un estándar HTML y XHTML.

Mejor estructura

Hoy en día se abusa bastante del elemento div, que nos permite estructurar una web en bloques. En HTML5 hay varios elementos que sirven para estructurar mejor una página web, estableciendo qué es cada sección, y reemplazando en muchas ocasiones a div. Con este extra de semántica, será mucho más coherente y fácil de entender por otras personas. Y lo que es más importante, será trivial de entender para una máquina, dándole más importancia a unas secciones y pudiendo jugar con esos datos automáticamente. Concretamente, la tarea de un buscador será mucho más fácil, pero cualquier aplicación que “lea” páginas web se beneficiará. Estos son los elementos:

• section representa una sección “general” dentro de un documento o aplicación, como un capítulo de un libro. Puede contener subsecciones y si lo acompañamos de h1-h6 podemos estructurar mejor toda la página.
• article representa un contenido independiente en un documento, el caso más claro son las entradas de un blog o las noticias de un periódico online. Así, dentro de la portada podremos tener varios artículos demarcados semánticamente, por lo que una herramienta puede extraerlos fácilmente.
• aside representa un contenido que está muy poco relacionado con el resto de la página, como una barra lateral. Esencial para delimitar el contenido “importante” del contenido “de apoyo”, haciendo más caso al primero que al segundo.
• header representa la cabecera de una sección, y es de suponer que se le dé más importancia que al resto, sobre todo si la sección es un artículo.
• footer representa el pié de una sección, con información acerca de la página/sección que poco tiene que ver con el contenido de la página, como el autor, el copyright o el año.
• nav representa una sección dedicada a la navegación entre el sitio, como la típica barra superior de los periódicos.

En la anterior imagen vemos un ejemplo de cómo cambiaría un documento escrito en HTML normal a HTML5 con estos elementos.

Mejores formularios

El elemento input ha sido ampliado y ahora permite todos estos tipos de datos:

• datetime, datetime-local, date, month, week, time, para que indicar una fecha/hora.
• number para que el usuario indique un número.
• range para indicar un rango entre dos números.
• email para indicar un correo electrónico.
• url para indicar una dirección web.
• search para indicar una búsqueda.
• color para indicar un color.

Lo más interesante de esto es que los navegadores podrán implementar interfaces específicas para cada tipo de dato, por ejemplo una fecha o un color se podrán indicar de manera directa e intuitiva. Otro ejemplo sería el teclado del iPhone, que muestra unos símbolos u otros dependiendo de si es un texto normal, un email (añade @ y el punto) o una url (añade la barra y el punto com), y que por tanto gana mucho con este estándar.

Otros elementos importantes

• audio y video sirven para incrustar un contenido multimedia de sonido o de vídeo, respectivamente. Sin duda uno de los añadidos más interesantes, ya que permite reproducir/controlar vídeos y audios sin necesidad de plugins como el de Flash. Se tratan de manera totalmente nativa como cualquier otro elemento, por ejemplo se pueden incluir enlaces o imágenes dentro de un vídeo. Aunque las implementaciones actuales son un tanto ineficientes, se espera que en un futuro próximo se optimicen. Portales de vídeo como Youtube o Dailymotion ya están empezando a mostrar que un futuro sin Flash es posible (¡y necesario!).
• embed sirve para contenido incrustado pero no nativo, sino ejecutado por plugins como el de Flash. Aunque embed está soportado por casi todos los navegadores desde hace tiempo, es ahora cuando entra parte del estándar y evita el infierno/pelea entre object y embed.
• canvas es un elemento complejo que permite generar gráficos, dibujando elementos dentro de él. Aunque nunca hayas oído hablar de él, seguro que lo has usado alguna vez, por ejemplo de Google Maps. Es un elemento muy potente que dará bastante que hablar en el futuro, y que será el culpable de aplicaciones web espectaculares.

Más elementos

• dialog se plantea para escribir conversaciones, por ejemplo para transcripciones de chat.
• figure se plantea para asociar un contenido multimedia (una foto, un vídeo, etc) a un título o leyenda.
• mark representa un texto resaltado, por ejemplo para resaltar una búsqueda.
• meter representa una medida, como el número de KB. Tiene más sentido si lo unimos con…
• progress representa el estado de una tarea, y se puede usar por ejemplo al subir un documento o al realizar varias tareas pesadas. Esto permitirá barras de tareas personalizadas y potentes.
• time representa una fecha o una hora.
• command representa un comando que el usuario puede ejecutar en su navegador.
• output representa una salida de un programa, probablemente ejecutado directamente en el navegador, como una calculadora.
• datagrid representa datos de manera interactiva y permite trabajar dinámicamente con información y cambiar la página respecto a esa información. Será útil sobre todo si se quiere trabajar con aplicaciones que necesiten de bastantes datos a la vez en el lado del cliente.

En las próximas entradas veremos más novedades interesantes de HTML5, centrándonos en aspectos más dinámicos.

Adobe presenta en AdobeLabs una extensi�n para el uso de HTML5 con Dreamweaver CS5. Esta extensi�n proporciona la posibilidad de desarrollar para HTML5 y CSS3, e incluye actualizaciones y mejoras WebKit para la vista de dise�o y renderizado en Live View.

Esta extensi�n incorpora estas caracter�sticas:

• Introduce el panel de vista previa de multipantallas, lo que permite mostrar en Live View 3 diferentes tama�os de pantalla.
• Agrega y actualiza el code hinting para las nuevas etiquetas, atributos y propiedades HTML5.
• Agrega el code hinting de las siguientes especificaciones CSS3: Transformaciones 2D/3D; animaciones; fondo y el borde; b�sicas de interfaz de usuario; trazado de la l�nea; Marquee; Media consultas; multicolumna, Ruby, contenidos y transiciones.
• Actualizaciones Live View para apoyar <video> y <audio>.
• Mejora de la prestaci�n de CSS3 en Live View.
• Agrega dise�os de HTML5 de arranque para el cuadro de di�logo Nuevo documento.
• Ofrece una mejor prestaci�n de nuevas etiquetas en la vista Dise�o.

Podemos descargar la extensi�n desde la siguiente URL:
http://labs.adobe.com/downloads/html5pack.html

Tambi�n disponemos de un foro espec�fico por si tenemos alguna duda o consulta:
http://forums.adobe.com/community/labs/html5pack/

Los desarrolladores/dise�adores web siempre han tenido la limitaci�n en cuanto al uso de tipograf�as en el dise�o web, para lidiar con esto actualmente se utilizan varias alternativas mediante el uso de Javascript e inclusive Flash, Cuf�n y SIFR por mencionar algunos, pero hoy Google introdujo su Font API y Font Directory en el Google I/O, ofreci�ndonos una excelente alternativa para usar nuevas tipograf�as en web de forma gratuita.

Tipograf�as en CSS y HTML �C�mo funciona?

Existen dos formas de utilizar el Font API:

M�todo 1:

Simplemente agregamos la siguiente l�nea en nuestro HTML entre las etiquetas <head>:

Código :

<!-- embebemos la tipograf�a Tangerine -->
<link href="http://fonts.googleapis.com/css?family=Tangerine" rel="stylesheet" type="text/css" />

y en nuestro CSS le aplicamos la propiedad font al elemento que queramos:

Código :

h1 { font-family: 'Tangerine', serif; }

En este caso estamos aplicando la tipograf�a Tangerine que llamamos en el ‘link’ del HTML a las etiquetas h1.

M�todo 2:

El otro m�todo sin necesidad de modificar nuestro HTML es hacerlo directamente en nuestra hoja de estilos usando @import:

Código :

@import url('http://fonts.googleapis.com/css?family=Droid+Sans');

Y luego en el elemento:

Código :

h2 { font-family: 'Droid Sans', serif; }

En este caso estamos aplicando la tipograf�a Droid Sans que llamamos en el ‘import’ del CSS a las etiquetas h2.

Mas tipograf�as:

Para conocer que otras tipograf�as se pueden utilizar, visiten el directorio de fuentes y elijan la tipograf�a que m�s les guste.

Google Web Fonts en acci�n

La API de Google Fonts esconde una gran complejidad. Por detr�s, la infraestructura de Google se encarga de convertir la fuente en un formato compatible con cualquier navegador moderno (como Internet Explorer 6 en adelante) y enviar a nuestra web los caracteres exactos con los estilos que les hayamos definido.

Estas fuentes tambi�n funcionan bien con CSS3 y HTML5, incluyendo sombras, rotaci�n, etc. Funcionan de la misma manera que las fuentes locales, facilitando la separaci�n de contenido y presentaci�n.
Si quieren ver esto en acci�n, una reconocida web ya relanz� su sitio haciendo uso de la tipograf�a Droid Sans.

Funciona en todos los navegadores, la diferencia es que en algunos se muestra anti-alias y en otros no, en cuanto a navegadores m�viles al parecer no funciona por eso es una buena pr�ctica definir una segunda fuente alternativa.

Esto es un gran recurso gratuito para que desarrolladores podamos usar tipograf�as diferentes sin necesidad de javascript.

M�s informaci�n

Google Font API
Google Font Directory

Google anunci� hoy en el Google I/O 2010 el codec de video On2 VP8 y el proyecto WebM. La raz�n por la que Google compr� On2. VP8 es un codec que competir� contra H.264 por dominar el video en el tag <video> de HTML5.

H.264 es un codec patentado, licenciado y MUY caro (5 millones de dolares le habr�a costado a Macromedia implementarlo en el 2008) de un consorcio del cual hacen parte Apple y Microsoft. Ellos ganan ese dinero cuando se crean aplicaciones con H.264.

On2 cre� VP6, que fue por a�os el codec del video en Flash, .FLV. Es el codec en el que est� todo el video de Youtube. Flash ahora soporta Sorenson Spark, On2 VP6, H.264 y On2 VP8.

On2 VP8 de Google es un codec libre, abierto, sin patentes, sin licencias, protegido contra demandas. Est� apoyado por Adobe, Firefox, Opera, Wikipedia, Youtube, Android, Chrome.

En el Google I/O 2010, el CEO de Mozilla muestra el soporte de On2 VP8 en Firefox (L4C.me io2010)

La web del futuro estar� divida entre Safari Mobile, Safari e Internet Explorer implementando H.264 y Google Chrome, Webkit, Opera y Firefox con On2 VP8. Una guerra similar a BluRay vs. HD-DVD.

La wikipedia anunci� soporte exclusivo de On2 VP8. Youtube soporta On2 VP6, H.264 y On2 VP8. Otros publishers de video probablemente implementar�n H.264 y On2 VP8 al mismo tiempo. Muchos seguir�n usando Flash normalmente para reproducir video, ya que Flash soporta todos los codes y todos los browsers.

�Quien creen que gane la batalla por el video en la web?

Hace d�as que se viene dando un interesante debate alrededor de la tecnolog�a Flash y HTML 5, hemos visto diversas opiniones y a diferentes escalas inclusive algunas declaraciones de parte del CEO de Apple (Steve Jobs) y el CTO de Adobe (Kevin Lynch).

Esto no es algo nuevo, de hecho con cada nueva tecnolog�a que sale al mercado (Silverlight, JavaFX, etc.) y/o cada que la W3C se pone las pilas sucede lo mismo, hay qui�nes toman una posici�n a favor y hay qui�nes toman una posici�n en contra; lo cu�l es muy respetable siempre que esto vaya sustentado con argumentos y no simplemente como un factor de respuesta a todo el ruido que se genera en el medio.

Participa en un debate en vivo de Flash vs. HTML 5

La semana pasada particip� con @freddier y @cvander en el programa Mejorando la Web para hablar al respecto. Los comentarios que pude ver alrededor de esta discusi�n fueron bastante atinados. Es por eso que al final del programa decid� comentarle una inquietud a Freddy y a Christian (qui�nes se mostraron entusiasmados) misma que comparto con ustedes en este post. (Puedes ver la grabaci�n del programa abajo)

La idea es organizar un debate con 5 invitados de cada bando (por decirlo de una manera), es decir 5 entusiastas de Flash y 5 entusiastas de HTML 5. Ya tenemos algunas personas interesadas pero no creo que fuera en realidad algo muy democr�tico si no le di�ramos cabida a cualquier persona de la comunidad que quiera participar.

C�mo participar

Por lo que no importa que posici�n sea la tuya, si est�s interesado en debatir, deja en los comentarios quien eres, qu� piensas y tu posici�n (y tu cuenta de twitter o algo). Los mejores y m�s acertados comentaristas ser�n elegidos para participar en la transmisi�n, que esperamos vean alrededor de 2000 personas en vivo y muchas m�s en su grabaci�n.

A�n tenemos que definir las fechas pero tan pronto tengamos a los participantes lo haremos de manera formal, por lo que si estas interesado en participar no dudes en dejar tu comentario en este post lo antes posible.

Desde que el iPad fue anunciado, sin Flash, mucha gente ha estado especulando su ca�da. Se suma el experimento de Youtube con HTML 5 y el tag <video>. Tal fue el hype generado por la supuesta muerte, que dedicamos un cap�tulo de MejorandoLaWeb al tema.

El mundo de Flash est� cambiando. La computaci�n est� cambiando. La web est� cambiando. Pero Flash no morir� y si Adobe toma las decisiones correctas, incluso puede convertirse en el l�der de campos que no esperamos. Este a�o ser� decidido todo.

Flash, HTML 5, Javascript y el video

HTML 5 tiene cosas impresionantes. Drag and Drop de archivos al navegador, animaciones vectoriales en SVG, un tag para embeber video, otro tag para audio, acceso a disco y geolocalizaci�n por m�ltiples m�todos (GPS, IP, manual, etc). Esto ha dado pie a que muchos digan que "Flash es innecesario".

Molly Holzschlag es una de las personas que m�s sabe de est�ndares en el mundo y compil� una lista de capacidades de HTML 5 y los navegadores que las implementan. No es mala la implementaci�n, pero usarla en producci�n es triste.

El video es un problema "emocional". Algunos quieren OGG como formato, otros H.264 y otros algo completamente diferente. Ahora mismo, el tag <video> tiene la misma versatilidad de las epocas del Real Player.

Cosas que hace Flash que no puede hacer HTML5 o JS ni hay planes para que pueda

• Streaming: UStream, Tinychat, Livestream, incluso Youtube live, inviables con "est�ndares".
• Animaci�n vectorial compleja: SVG? CSS3? Jajajaja. Si tu crees que hacer animaciones con esas tecnolog�as es m�s f�cil, igual que Flash y gasta menos CPU, no has comparado a nivel t�cnico. La realidad es que actualmente, s�lo Flash lo permite como debe ser. El resto de animaciones en SVG, CSS3 o JS gastan demasiada CPU y no hay un software del nivel de Flash para crearlas.
• Edici�n y manipulaci�n de audio: AS3 es capaz de mezclar audio en tiempo real. Nadie m�s puede hacerlo al nivel de AS3.
• Edici�n bit por bit de mapas de bits: Aviary, Picnik y Photoshop Online hechos en Flash y Flex lo demuestran. �En HTML5 o JS? Ninguno realmente usable.
• 100% de compatibilidad a trav�s de todas las plataformas: Si dices que es posible escribir un s�lo c�digo HTML5/CSS/JS que funcione en todos los navegadores ahora mismo, no has hecho nada profesional. En SWF es normal

Flash no es s�lo el player. Flash CS5 es un entorno integrado con la capacidad de dise�ar, dibujar, animar, incluir video, audio, editar todos estos componentes, agregar interactividad y programaci�n de alta complejidad, compilar para desktops, m�viles o iPhones. Ninguna herramienta del lado "est�ndar abierto" ofrece ese nivel de integraci�n ahora mismo. No Dreamweaver, no Visual Studio 2010, no Aptana, ni siquiera una combinaci�n de varias.

Flash, tel�fonos m�viles, Apple

El mundo m�vil es diferente. El iPhone cambi� el mundo y estableci� una fuerte tendencia a las tiendas de aplicaciones, la integraci�n de HTML 5 actualizado en el tel�fono e ignorar a Flash. Android y otros siguieron el mismo camino.

Este mes en el Mobile World Congress, Adobe presentar� el Flash Player 10.1 para todos los tel�fonos m�viles (excepto iPhone), un compilador especial para crear apps de iPhone con SWF desde Flash CS5 y el secreto a gritos, una forma unificada de desarrollar apps "pseudo-nativas" para Android, WebOS, Blackberry y Symbian, con un mismo c�digo.

Flash ya era usado por el 90% de la humanidad conectada antes de Youtube. Las animaciones y los juegos en linea lograron posicionar a Flash en el principio. No hay raz�n para pensar que no pasar� a nivel m�vil. Ninguna empresa tiene un entorno tan avanzado para el desarrollo de juegos m�viles como Adobe con Flash. Y pasar� en todas las plataformas de tel�fonos actuales (En tu Nokia 1100 puede que no)

�Y Flex? �Y Adobe AIR?

Flex es l�der en desarrollo de RIAs. No se nota mucho su presencia en la web, pero est� en muchas intranets y empresas. Aun no tengo claro si Flex Mobile har� un impacto tan fuerte como Flash/AIR Mobile, pero su presencia como la mejor y m�s veloz herramienta para aplicaciones web se mantendr�, a pesar de que HTML 5 y jQuery UI son amenazas muy reales y fuertes.

Adobe AIR tiene que evolucionar. El uso de archivos .air y "badge installers" es simplemente est�pido. No est� mal que los ofrezcan, pero tambi�n incluyan la opci�n de crear instaladores por SO. Si el rumor de AIR Mobile es cierto y cometen una cagada como la de los .air, Flash no ser� el sue�o que esper�bamos. Esperemos que Adobe tome la decisi�n correcta.

Flash "est�ndar", Flash Open Source

Flash es est�ndar en el mismo sentido que los .doc y .docx lo son. Es una realidad. No es algo malo de por s�, pero muchos no se sienten c�modos. Flash tiene abiertas las especificaciones del formato SWF, pero proh�ben crear "players" alternativos con esas specs �Por qu�? Seg�n ellos, para proteger la segmentaci�n del mercado y mantener un s�lo player. Yo sol�a creer en esto.

Ya no lo creo m�s. La p�sima forma en la que Adobe ha manejado las plataformas m�viles (i-Mode -> Flash Lite con AS0.5 -> muerte de Flash Lite -> vac�o -> �10.1?) , sumado a la lecci�n de Android que se puede tener una distro oficial open source sin perder el control me lo deja claro. Adobe deber�a, sin duda, liberar el c�digo del Player y permitir que la comunidad "ayude". Si Adobe no puede implementar bien Flash en Linux y Mac, la comunidad s� podr�. �El miedo es que Microsoft los mate como mat� a Java con una maquina virtual especial? Adobe ya est� grande y debe poder superar esto. Con su penetraci�n, pueden mantener el control de un player abierto.

Si no, quiz�s y el 2022, cuando HTML 5 ser� un est�ndar cerrado y aprobado, ser� realmente el declive de Flash.