aulambra.com

Seguimiento del HTML5 Europe Tour en Madrid.

Michael Smith

@sideshowbarker LinkedIn
Se unión a W3C en 2007 para trabajar en los estándares de navegación del W3C, en particular el fenómeno conocido como HTML5, así como otros estándares relacionados con las API para las aplicaciones web. Antes de unirse a W3C, Smith trabajó para Opera Software y para Openwave Systems en temas relacionados con el diseño y el desarrollo de software en Japón.

Charles McCathieNevile

@chaals LinkedIn
Experto en estándares Web, Miembro del Comité Asesor del W3C y Director del Grupo de Trabajo de WebAPIs relacionado con HTML5. Actualmente es el representante de Yandex en el Consorcio y, hasta el pasado julio fue el Chief Standards Officer del prestigioso fabricante de navegadores Opera.

¿Qué es el Do Not Track?

Seguro que muchas veces te ha pasado algo parecidos a lo siguiente. Te has querido ir de vacaciones a Roma y has utilizado una serie de webs para buscar vueltos, hoteles,… en Roma. De repente, y sin saber por qué, cada vez que estás navegador por otras web de Internet empiezan aparecerte publicidad y curiosamente toda es dirigida a hoteles, vuelos,… de Roma. Esto es lo que se de nomina publicidad personalizada en base a tu comportamiento (Behavioral Advertising).

Do Not Track es una tecnología, especificación y conjunto de políticas las cuales permite a los usuarios de Internet indicar que su actividad en la red no sea monitorizada y utilizada a posteriori con fines publicitarios, de analítica web o en plataformas sociales.

Así, si tu activas en tu navegador (o agente de usuario) la opción de Do Not Track no debería de pasarte nada de lo descrito anteriormente.

Desde el punto de vista tecnológico la idea es que los navegadores envíen una cabecera en las peticiones a los servidores y estos, ante la recepción de esta petición, realicen las acciones necesarias para no guardar ningún tipo de información en las cookies del usuario.

Soporte del Do Not Track

La cuestión es que a día de hoy Do Not Track sigue estando en un estado primigenio de adopción y su uso es limitado. Pero las últimas noticias publicadas hacen ver que Do Not Track cada vez está más adoptado.

Así, se puede leer que Yahoo! ha anunciado que dará soporte al do-not-track durante este año o que la Digital Advertising Alliance (DAA), una alianza de 400 compañías, aceptan dar soporte a Do Not Track.  En la Digital Advertising Alliance (DAA) encontramos empresas como Yahoo!, BMW, Toyota, Wells Fargo, American Expres Microsoft, Dell, AT&T,…

Incluso la Digital Advertising Alliance (DAA) ha habilitado un procedimiento para reportar quejas sobre empresas que no soporten el Do Not Track.

También la Universidad de Stanford está llevando un listado sobre actores que estén dando soporte del Do Not rack.

Implementando Do Not Track en Navegadores

Pero las Empresas y sus websites no son los únicos participantes en el negociado del Do Not Track. Los navegadores web son el otro gran actor.

Así vemos que Internet Explorer 9, Safari y Firefox ya están dando soporte del Do Not Track. Y que en el caso de Google Chrome, este soportará do-not-track a final de año. Algo bastante importante sobre todo teniendo en cuenta que Google cuenta con la publicidad como su principal fuente de ingresos.

En el caso de Opera, de momento se encuentra en fase experimental. Pero seguramente lo acaben implementando.

Estandarizando el Do Not Track

Además la tecnología y políticas defindas en Do Not Track están empezando a ser estandarizadas por la W3C y su Tracking Protection Working Group.

Los beneficios de la W3C son incuestionables y su trabajo en la estandarización de Internet ha sido excepcional. Si bien siempre se le ha achacado la complejidad de su modelo de trabajo. Los grupos cerrados, la falta de visión global de la industria, el tiempo desde que propone un estándar hasta que lo cierra,…

En este sentido la W3C ha empezado a dar pasos que modifiquen este modelo. Hasta ahora para proponer/crear un estándar había que hacerlo mediante un Working Group. Su nueva idea es crear Community Groups y Business Groups.

Community Groups

La idea es abrirse a los desarrolladores de Internet y ofrecerles toda la infraestructura de la W3C para el desarrollo de estándares. La participación será gratuita y sin cargos. No habrá presión de fechas en la propuesta de nuevos estándares.

La idea de los community groups es la de:

• Fomentar la propuesta de nuevas especificaciones
• Promover la discusión sobre los estándares
• Generar y desarrollar casos de test
• Crear una comunidad alrededor de la innovación

Business Groups

Son grupos dedicados a empresas. De esta manera se quiere generar un foro premium de empresas para desarrollar tecnologías específicas orientadas a industrias.

Con los Business Groups se busca el tener más información de empresas en las especificaciones que genere la W3C.

Si la empresa es un W3C Members no tienen coste en su participación. En caso contrario se tiene un coste anual que va desde $300 a $10.000 dependiendo del tamaño de la empresa.

Parece que a lo largo del verano empezará a funcionar este modelo, de momento puedes encontrar más información sobre las nuevas comunidades en http://www.w3.org/2010/12/community/

El grupo de trabajo Device APIs and Policy Working Group de la W3C está definiendo un nuevo borrador, en este caso es el Calendar API. Dicho API intenta definir de forma genérica el acceso a los eventos de un calendario.

Para ello dentro del Calendar API se definen dos interfaces Calendar y CalendarEvent. El interface Calendar nos permite encontrar eventos o items en el calendario y CalendarEvent define qué es un evento en sí, con su descripción, fecha de inicio y fin, si es recursiva,… El interface CalendarEvent está propuesto de la siguiente forma:

interface CalendarEvent {
  readonly attribute DOMString           id;
  attribute DOMString           description;
  attribute DOMString?          location;
  attribute DOMString?          summary;
  attribute DOMString           start;
  attribute DOMString?          end;
  attribute DOMString?          status;
  attribute DOMString?          transparency;
  attribute CalendarRepeatRule? recurrence;
  attribute DOMString?          reminder;
};

Seguiremos atentos a esta especificación.

¿Cuál es la especificación del Device APIs and Policy Working Group que más te llama la atención?

Al crear una aplicación móvil es muy probable que estemos accediendo a las capacidades del dispositivo. Entre estas capacidades encontramos, sin duda alguna, el punto de poder enviar o consultar los SMS del dispositivo. Las diferentes plataformas de dispositivos móviles nos ofrecen sencillos APIs para poder ejecutar esta tarea.

En este sentido, la W3C, en su papel de estandarizar los lenguajes y APIS ha lanzado el primer borrador del Messaging API. El Messaging API pretende estandarizar la funcionalidad de mensajería en el dispositivo: SMS, MMS y email.

Aunque Messaging API está en un estado inicial (solo están definiendo un método sendMessage) merece la pena seguirla los pasos.

El Messaging API esta gestionado por el Device APIs and Policy Working Group

Authoring Tool Accessibility Guidelines (ATAG) 2.0 está en pleno proceso de actualización y así ha notificado que están siendo actualizados los borradores de la especificación.

ATAG 2.0 es la especificación de la W3C que se encarga de definir como tienen que soportar o ayudar a soportar la accesibilidas las herramientas de autor. Es decir, redes sociales, blogs, gestores de contenidos, editores HTML,… De igual manera, ATAG 2.0, especifica como estas herramientas de autor deben de ser accesibles por si mismas.

Dentro de los documentos de trabajo de ATAG 2.0 encontramos:

• Las directrices de ATAG 2.0
• Guía para saber cómo implementar las directrices de ATAG 2.0

Siempre muy buen trabajo el realizado por la W3C en temas de accesibilidad.

Ya se acerca el verano, el calorcito y las ganas de enredar algo más. ¿Te vas a perder nuestras novedades?

Como siempre seguimos animando para que colaboréis en nuestras webs. ¿Te animas? Pues ponte ponte en contacto con nosotros.

Estas semanas en las webs de aulambra.com encontrábamos:

Línea de Código

• Dígitos de un número
• Cambios en un combo con jQuery
• Filtrar elementos nulos de un array con jQuery
• Filtrar elementos de un array con jQuery
• Bloquear el envío de un formulario con jQuery
• Cargar una matriz por teclado en Java
• Listar las claves de una Hashtable
• Número de ocurrencias en un array
• Depurar una conexión SMTP con Java Mail
• Contraseña aleatoria con php

Una Página Web

• @GoogleWebTeam
• RockMeIt y el navegador social
• IE10 User-Agent
• Listado de estándares de la W3C

W3Api

• HTML:onchange
• jQuery:change()

Esta semana en Dudas de Programación han preguntado las siguientes cosas:

• Manejando arrays
• Cambios de imágenes en Javascript
• Conectar JSP con Oracle
• Cerrar una ventana en jQuery
• Cómo generar IDs únicos y autoincrementales en Java
• … además puedes ayudar a resolver las preguntas sin respuesta.

¿Algún foro que no tengamos y que te gustaría crear? Contacta con nosotros.

Recuerda que nos puedes seguir en Twitter:

• @aulambra
• @ayudaenlaweb
• @lineadecodigo
• @unapaginaweb
• @dudasprogamar

O hacerte fan en Facebook de Aulambra, Linea de Código, Una Página Web, Ayuda en la Web o Dudas de Programación.

Cuánta gente que a lo largo de los años ha estado relacionada con el HTML ha buscado el logo del lenguaje… y es que simplemente no existía ninguno estándar. Parece ser que el grupo involucrado en HTML5 ha reparado en eso y ha entendido que el lenguaje con el que estarán hechas todas las páginas del futuro (qué atrevido) tenga su logo.

Pronto veremos correr como un reguero de pólvora el nuevo logo de HTML5 en muchas páginas de Internet… Nosotros ya lo tenemos en nuestra página de ejemplos sobre HTML5.

Pero la cosa no queda aquí, ya que a parte del logo de HTML5, cada una de las partes de la especificación de HTML5 pasa a tener su propio logo.

Echarles un vistazo…

Styling	Semantics	Performance
Offline	Multimedia	Device Access

Ya se pueden encontrar sticks, posters, camisetas,… mucho merchandising del logo HTML5.

Ponte al tanto de todo sobre el logo de HTML5 en http://www.w3.org/html/logo/

El W3C va avanzando en su afán de estandarizar todo lo posible. En esta línea acaba de publicar la recomendación del lenguaje Ink Markup Language (InkML).

El lenguaje InkML servirá para estandarizar el contenido que sea introducido mediante bolígrafos digitales. De esta forma estandarizará la forma en la que se recoge el texto, los gestos, dibujos,…

La especificación para los bolígrafos digitales podrá ser un avance en la estandarización del acceso a la información proporcionada por dispositivos reconocedores de firma. Un tipo de dispositivo que se esta extendiendo mucho últimamente.

Todo el trabajo es coordinado por el W3C MultiModal Interaction Working Group.

El HTML Working Group sigue trabajado, lento pero seguro (no teníamos noticias suyas desde marzo de este año), alrededor del HTML5. Y ha publicado actualizaciones en 8 documentos:

• Nuevo borrador de la especificación HTML5
• Diferencias entre HTML4 y HTML5
• API de referencia HTML
• HTML+RDFa 1.1
• HTML Microdata
• HTML Canvas 2D Context
• Técnicas HTML5 para ofrecer alternativas de texto útiles – documento que nos enseña a como proponer alternativas útiles a las imágenes.
• Polyglot Markup – o como generar documento XHTML compatibles con HTML.

Todos de recomendada lectura.