XFORM pasa a ser recomendación

post - - leave a reply - share

Aunque con cierto retraso (20/10/09) me hago eco de esta noticia, y es que los XFORM ya han sido establecidos como recomendación por parte del W3C.

Los formularios que usamos actualmente con HTML presentan un nivel de interacción algo pobre para las necesidades de hoy en día. Los sitios web han pasado de ser páginas meramente presenciales a sofisticadas aplicaciones. Es por esto que para hacer un GUI más rico e interactivo creamos diferentes controles a medida (widgets) y para ello usamos CSS, JavaScript, AJAX (y ARIA para la accesibilidad). Con el avance de los XFORMS podremos ahórranos muchos de estos widgets puesto que vendrán de serie, perfectamente estandarizados, documentados y listos para su implementación.

En una charla que nos dio Chaals sobre nuevos estándares web nos hablo de lo ridículo, laborioso y frustrante que era desarrollar controles (calendarios, inputs con mascaras, etc) para que luego no funcionasen sin JavaScript, CSS, o lo que fuese, y que además tuviésemos que validarlos localmente y por último en lado del servidor (razón no le falta!). Así que nos puso como ejemplo algunas de las soluciones XFORM y que si son soportadas en el navegador Opera.

Actualmente el soporte de XFORM es pobre o nulo, incluso se necesitan plugins y extensiones. Por otro lado la notación de los XFORM me parece muy farragosa, a mi entender deberían orientarse hacia la simplicidad de formularios actuales. Pero bueno, el paso a recomendación ya es un avance sustancial que en cierto modo supongo que hará ponerse las pilas al resto de navegadores.

W3C se volcará en HTML5

post - - leave a reply - share

¿Os acordáis que hace un tiempo hablábamos sobre ‘el duelo’ xHTML2 vs. HTML5?

Parece que el W3C se había quedado solo con la especificación xHTML2, mientras que otras empresas como Opera, Mozilla y Apple siguen trabajando por y para HTML5. Luego llego la incorporación de Google apostando fuertemente por HTML5 con proyectos como Google Wave.

Finalmente el W3C ha anunciado que cuando se acabe el plan de trabajo del Grupo de XHTML 2, planeado para el final de 2009, el Grupo no será renovado. En cambio destinará sus recursos al Grupo de Trabajo de HTML.

Con ello el W3C espera acelerar el progreso del HTML 5 y clarificar su posición sobre el futuro del HTML.

Directriz 10.5 (prioridad 3) en WCAG 2.0

post - - leave a reply - share

En un post anterior he comentado que la directriz 10.4 (prioridad 3) ha sido desaprobada en WCAG 2.0, ahora voy hablar de la siguientes en la cola 😉

La Directriz 10.5 (prioridad 3) dice:

Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) interpreten claramente los vínculos contiguos, incluya caracteres imprimibles (rodeados de espacios), que no sirvan como vínculo, entre vínculos contiguos.

Ejemplo: [ Estándares | Accesibilidad | Usabilidad ], carácter imprimible: |

Esta directriz era de obligado cumplimiento en la prioridad 3 de WCAG 1.0. Sin embargo la recomendación WCAG 2.0 nos dices que esta técnica ya no es necesaria para los agentes de usuario, aunque puede ser útil para las personas con discapacidades cognitivas.

Recursos del W3C para la web móvil

post - - 2 replies - share

W3C mobileOK Checker

mobileOK Checker es una herramienta excelente con la que podemos chequear la versión móvil de nuestro sitio web. Al igual que las otras herramientas hermanas de la W3C (Markup validation, CSS Validation) nos indica los errores y las alertas del código web. Por cierto, alertas bastante restrictivas debido al XHTML Basic.

También te indicará cuando la página tiene un peso excesivo, no recomendado para los dispositivos móviles.

Conversor de (X)HTML a XHTML Basic

Convert (X)HTML to XHTML Basic nos permite convertir cualquier tipo de documento HTML o XHTML en la versión básica de XHTML. La cual guarda númerosas diferencias con la versión estricta.

En XHTML Basic se pierde cierta semántica, no pudiendo usar por ejemplo elementos como tbody, thead, etc.

XHTML Basic 1.1 doctype

Por último tenemos Mobile Tests, mas que una herramienta se trata de un sitio web con una lista de ejemplos muy interesantes para la adaptación móvil.

WCAG 2.0 ya es una recomendación del W3C

post - - 2 replies - share

Desde hoy 11/12/08, las directrices de accesibilidad para el contenido web en su versión 2.0 ya son una recomendación W3C.

Web Content Accessibility Guidelines (WCAG) 2.0

Por tanto se han actualizado las normas por las que nos regimos para que el contenido de los sitios web sea accesible.

Esto ya se venia demorando mucho tiempo y por fin tenemos la actualización. Era realmente curioso como había ciertas directrices que carecí­an de sentido en la actualidad (incluso mirando bastante atrás en el tiempo).

Breve historia de los elementos IMG, EMBED y OBJECT

post - - leave a reply - share

Los primeros navegadores MOSAIC y Netscape ofrecieron a los diseñadores la posibilidad de incluir imágenes en las páginas web, así fue como nació la etiqueta <img>.

El W3C opino al respecto y fue en contra de esta iniciativa, ellos promovían el uso de la etiqueta <object> para cualquier elemento (objeto) multimedia.

Posteriormente al elemento IMG llego la tecnológica Future Splas (lo que hoy conocemos como Flash) y varios soportes de vídeo (Quicktime, Real, etc).

Fue entonces cuando la W3C volvió a plantear el uso del elemento OBJECT, pero Netscape hizo oídos sordos y retomo la guerra de los navegadores (ahora contra Internet Explorer) y se saco de la manga el elemento EMBED.

La W3C decía:

  • Para incrustar imágenes, usar <object>
  • Para incrustar flash, usar <object>
  • Para incrustar vídeo, usar <object>

La verdad es que suena más lógico el planteamiento del W3C, pero en la realidad el elemento IMG, EMBED y diferentes soporte propietarios ya se había propagado a millones de sitios web impulsados por diseñadores web ávidos de hacer una red mucho más estética y multimedia (y con razón).

Al final las recomendaciones de la W3C eran totalmente ignoradas, pero esta siguió su ritmo con paso firme, haciendo que las especificaciones no contemplasen el elemento EMBED y que los documentos web en su versión HTML 3.2 (o superior) y XHTML no puedan ser validados correctamente si incluyen este elemento.

Ahora años después y pensándolo en frió, el uso del elemento EMBED carece de sentido. Es un elemento propietario, esta desaconsejado por la W3C y hasta su nacimiento fue absurdo.

Por otro lado no comprendo la razón que tienen buenas plataformas de blogs como WordPress para presentar el elemento EMBED en sus códigos (¿compatibilidad inversa? a estas alturas…). Por suerte contamos con varias técnicas para incrustar vídeo y seguir validando en XHTML.

Por último recordar que también existe el elemento NOEMBED que se encarga de proporcionar un contenido alternativo y accesible a EMBED.

Los estándares web ¿negocio o necesidad?

post - - 2 replies - share

Para mi, la respuesta es clara.

Los estándares web son una necesidad, pero el negocio viene después.

Quizás en muchos casos es interpretado a la inversa, lo cual explicaría que el 96% de los desarrolladores ignoran los estándares web, supongo que por buscar primero el negocio, lo que obliga a que las cosas se hagan deprisa y mal.

Como ya he mencionado en alguna otra ocasión, pienso que los estándares web abren las puertas al futuro de forma inteligente y regulada.

Y digo que el negocio viene después por dos perspectivas:

  1. Desde el punto de vista del diseñador: El trabajo bien hecho termina premiando a nivel comercial y esto acaba por ser un aval de la inversión.
  2. Desde el punto de vista del cliente: Su nuevo sitio web tendrá una serie de beneficios que pronto pueden ser rentabilizados (de la forma que sea).

En definitiva, un sitio web bajo estándares ayuda a traer el negocio por si solo.

El diseñador web tiene la culpa

post - - leave a reply - share

Acabo de leer en un viejo libro (del 2001):

Los usuarios frecuentemente, no culpan a los exploradores de los errores, culpan a los sitios web.

Y he recordado como era habitual oír:

  • Esto no está perfectamente alineado.
  • El cuadro sale más grande que en el diseño.
  • El contenido se ha desbordado del cuadro.

Aunque el código CSS estuviera totalmente estándar (W3C) había decenas de problemas e incompatibilidades entre los diferentes navegadores: Internet explorer, Netscape, etc. Todo por culpa de la vieja batalla entre navegadores (inventando etiquetas y luchando por la mayor cuota de mercado).

El usuario y cliente lógicamente echaba la culpa al diseñador web, y aquí (o antes de ser advertido) comenzaba el duro trabajo de investigación  (la documentación escaseaba). Al final tirabas más tiempo investigando/solucionando incompatibilidades de la maqueta que el empleado en el propio diseño.

Por suerte esto fue cambiando y ya podemos omitir decenas de incompatibilidades, aunque tengamos que seguir considerando versiones pasadas de Internet Explorer 😛