aulambra.com

No cabe duda que jQuery sigue siendo uno de los frameworks Javascript más importantes y utilizados por los desarrolladores y fruto de su uso aparece la nueva versión jQuery 1.7. En jQuery 1.7 podemos encontrar una nueva forma de asignar y desasignar eventos, mejoras de soporte HTML5 para navegadores antiguos, optimización de sus objetos y métodos en búsqueda de un mejor rendimiento y algún método nuevo que otro.

Pero echemos un ojo, en detalle, a las novedades que vienen en jQuery 1.7. Entre ellas encontramos:

• on() y off(), se ha decidido estandarizar y mejorar la gestión de eventos. Para ello se han creado estos dos métodos con los que podremos asociar/desasociar eventos a los elementos de la página. Aunque los métodos que existían hasta ahora como bind(), unbind(),.. seguirán presentes en jQuery 1.7 se recomienda que se pase a utilizar on() y off().
• Mejora de rendimiento en los métodos delegados, se ha refactorizado el manejo de eventos para que la delegación de eventos sea mucho más rápida. Consiguiendo una reducción del 50% con respecto a jQuery 1.6.4.
• Soporte HTML5 para Internet Explorer 6/7/8, estas versiones de Internet Explorer no soportan las tags de HTML5 y además son eliminadas del DOM. jQuery 1.7 nos ayudará a soportar los tags HTML5 en esos casos. Para ello deberemos de cargar html5shiv o Modernizr.
  
• Cambios en las animaciones, se han corregidos problemas que se producían cuando se cambiaba entre animaciones y si la última había terminado mediante un .stop().
• Asynchronous Module Definition (AMD), jQuery 1.7 da soporte a la especificación del API AMD la cual nos sirve para cargar los módulos de forma asíncrona.
• jQuery.Deferred, se han extendido este objeto con nuevos manejadores y métodos de notificación.
• jQuery.isNumeric(), utilidad sencilla, pero que no existía. Nos devuelve true si el dato es numérico.

Además y como es normal, un buen grupo de bugs han sido corregidos.

Tienes toda la información sobre jQuery 1.7 en http://blog.jquery.com/2011/11/03/jquery-1-7-released/

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/

Si hay un grupo de trabajo que me gusta dentro de la W3C ese es el Web Applications Working Group. Este grupo es autor, de entre otras especificaciones, del Websockets API, File API, Indexed Database API,… Vamos, de todos los APIs que están naciendo alrededor del HTML5.

En este caso, uno de los últimos borradores de trabajo es el del estandarizado en el uso del portapapeles. De esta forma programar, desde nuestros navegadores web, los accesos a copiar, cortar y pegar desde el portapapeles se hará de forma estándar.

La idea es que el portapapeles o Clipboard lance una serie de eventos (ClipboardEvent). A ver copiar, pegar y cortar.

¿Qué te parece la estandarización del Clipboard API?

Seguimos revisando los trabajos del Device APIs and Policy Working Group (ya hemos visto el Messaging API y el Calendar API). En este caso vamos a ver qué tiene el borrador que proponen para la especificación de los eventos de estado de la batería.

Es un API para que las aplicaciones puedan acceder al estado de la batería: si hay batería, el nivel de carga de la misma, cuánto tiempo le queda a la batería y saber si la batería está cargando.

De momento la especificación está en los primeros pasos y propone un interface muy sencillo. Echemos un ojo:

interface BatteryStatusEvent : Event {
    readonly attribute boolean        isBattery;
    readonly attribute boolean        isCharging;
    readonly attribute float?         level;
    readonly attribute unsigned long? timeRemaining;
    void initBatteryStatusEvent (DOMString type, boolean bubbles, boolean cancelable, boolean isBattery, boolean isCharging, float? level, unsigned long? timeRemaining);
};

Revisa el borrador de la primera especificación para los eventos de estado de la batería.

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

Cuándo no tenemos a una persona frente a nosotros y tenemos una comunicación (email, chat,…) es complicado el transmitir nuestras emociones. Diferentes técnicas pueden ser aplicadas: negritas, subrayados, texto en mayúscula, incluso los emoticonos

Es por ello que el grupo Multimodal Interaction (MMI) Working Group creo el lenguaje Emotion Markup Language (EML), con vistas a poder modelar las emociones.

Emotion Markup Language (EML) intenta complimentar a otros lenguajes de marcado ofreciendo:

• Anotaciones manuales de datos
• Reconocimiento automático de emociones en el comportamiento del usuario
• Generación de emociones relacionadas con el comportamiento del sistema

Ahora, el grupo Multimodal Interaction (MMI) Working Group, pretende establecer un vocabulario en el que se recojan las posibles emociones. En este sentido ha publicado el primer borrador de vocabularios que pueden ser utilizados en el Emotion Markup Language (EML).

Así se revisará que vocabulario tener en Emotion Markup Language (EML) partiendo de clasificaciones existentes como las emociones básicas como ira,  miedo, felicidad, tristeza, sorpresa,… emociones diarias como miedo, diversión, enojado, aburrido,… u otras clasificaciones.

Silverlight se resiste a desaparecer y a quedarse acotado al mundo de los móviles. Ellos siguen pensando en el desarrollo global de aplicaciones ricas. Así, Silverlight 5 Beta, intenta mejorar el ecosistema de desarrollo de este tipo de aplicaciones.

Dentro de Silverlight 5 Beta podemos encontrar las siguientes mejoras:

• Depuración de XAML con capacidad de insertar breakpoints
• Plantillas de datos para facilitar la reutilización de interfaces de usuarios
• Soporte al doble click
• 3D compatible con XNA y API 2D con modo inmediato.
• Soporte WAV y efectos de sonido de baja latencia.
• Soporte multi-pantalla
• Mejoras significantes de rendimiento
• … así como corrección de múltiples bugs.

Ahora ya puedes empezar a descargar y utilizar Silverlight 5 Beta.

Ya está disponible una nueva actualización de Java SE 6, la Java SE 6 Update 27.

En esta nueva actualización de Java SE 6 para los “early adopters” encontramos mejoras relativas a:

• Reimplementación del método showDocument() para que pueda funcionar en el Internet Explorer para Windows Vista y Windows 7.
• Soporte para firmas raw RSA en SunMSCAP. Esta firma será NONEwithRSA. A día de hoy solo se soportaban SHA-1, MD5 y MD2.
• Mejoras en Xalan para corregir errores al utilizar la función count()
• Mejora en la gestión de errores en JNDI.
• …

De igual manera incluye una lista de bugs solucionados en Java SE 6 Update 27.

Si eres de los que te gusta cacharrear, ya tienes la primera release candidate de jQuery 1.6 lista para descargar.

En los cambios de jQuery 1.6 RC1 podemos ver que se ven modificados todos los módulos. Entre las cosas que se han arreglado en jQuery 1.6 encontramos:

• Compatibilidad con XHR2
• Valores de 0 en el ancho y alto de las imágenes para Internet Explorer.
• Inconsistencia entre el selector has y el método attr().
• attrHooks() para manejar atributos específicos de ciertos navegadores. Igual que se hizo con las CSS.
• Corregidos errores encontrados en el proceso de compactación.
• Mejoras en jQuery.Map
• jQuery.noConflict se podrá llamar desde cualquier sitio
• Reorganizado effects.js para mejorar los rendimientos de las animaciones y reducir el tamaño del fichero.
• jQuery.event.trigger utilizará loops en vez de recursividad
• Modificado el contructor jQuery.Event para soportar setters. Y evitar que solo puedan venir las propiedades en el evento. Algo como $.Event({ type: “keydown”, keyCode: 64 })
• jQuery.HoldReady() método que nos permitirá retrasar la carga del método ready(). Método que nos permitirá, por ejemplo, cargar plugins antes de la ejecución del resto del código
• …

Si quieres más detalle puedes revisar el listado entero de cambios.

En el caso de que seas una persona más paciente la current release de jQuery es jQuery 1.5.2.