Para todos los que alguna vez “casi” nos hemos vuelto locos con la codificación de caracteres en eclipse (especialmente duro cuando compartes trabajo entre equipos linux-windows), dejo este enlace al blog de Rubensa donde explica claramente como cambiarla y las diferencias entre eclipse 2.1 y 3.2.1.
Hace unos días se presentaba el primer borrador de Html 5 y son muchos los que todavía se hacen preguntas de tipo: "¿pero eso de html no estaba ya anticuado?", "¿volveremos a la maquetación con tablas?", "¿volveremos a los documentos sin una estructura xml definida?", "¿diremos adiós a la web semántica?", "y los estándares y la accesibilidad, ¿al carajo?", pues no exactamente, en cierta medida todo sigue quedando en nuestras manos. Tener una nueva versión de Html 5 no significa volver a las tablas como posiblemente muchos de vosotros esté pensando, es mas, tenemos nuevos elementos que también debiéramos utilizar a la hora de crear un nuevo documento, elementos como section, article, aside, header, footer, nav, dialog, etc. La forma de trabajar seguirá siendo la misma que la actual: estructura de documento xml, a ser posible, y css para dar forma y estilo. Eso si, aunque recomendable, no estaremos obligados a seguir la estructura xml de un documento xhtml y es aquí donde está la diferencia, rompemos la tendencia que había marcado el w3c hace unos años donde parecía que cualquier documento no xml no sería renderizado por los navegadores en el futuro. En este documento podéis encontrar las diferencias entre html4 y html5.
HTML5 está siendo desarrollado por WHATWG (comunidad abierta fundada por Mozilla, Opera y Apple) a los que parece que la complejidad del próximo xhtml2 del w3c no les convencía.
Aprovechando este post permitirme un par de reflexiones personales. Estaremos todos de acuerdo de que en la web los desarrolladores tenemos varios problemas a los que parece que hasta el momento nadie ha encontrado solución.
Para los desarrolladores de aplicaciones web tenemos una plataforma que llevamos años utilizando con un propósito para el cual no fué diseñada, html;xhtml han sido y son lenguajes de etiquetas para estructurar y publicar documentos. Donde están los layouts, árboles, pestañas, las barras de progreso, los menús, una comunicación mas dinámica y usable entre cliente y servidor, etc etc etc, que necesitan los desarrolladores de aplicaciones?.
Y por otro lado, y este lo añadimos al problema anterior que intentamos solucionar cada día con grandes dosis de imaginación (véase ajax, gwt, jsf, flex, java web start), tenemos el gran problema de los estándares. Señores navegadores, ¿hasta cuando creen que el gran negocio de la web podrá continuar desperdiciando tiempos de desarrollo debido a la mala implementación de los estándares en sus maravillosas aplicaciones?. Me respondo a mi mismo, yo creo que mucho mucho tiempo porque las ventajas y oportunidades que aporta la web son muy elevadas. Como elemento de comunicación no tiene precio, es un medio único, con unos costes únicos. Como plataforma de distribución de aplicaciones el ahorro de costes es tan superior a los problemas que causa, que continuaremos remendando hasta que aparezca una tecnología estándar que solucione nuestros problemas. Mientras seguiremos con nuestros hacks remendones:
Para ir terminando, que ya me estoy enrollando demasiado, tengo que mencionar la lentitud en las tomas de decisiones del w3c y derivados, y su aportación final a la comunidad. Hace 3 días apareció el primer borrador de html5, si, pero, ¿cuando creen que realmente se convertirá en un estándar que utilicemos la mayoría?, ¿cuando aparecerá la versión final de esta propuesta?, ¿cuando lo implementarán correctamente los navegadores?, ¿y cuando la mayoría de los usuarios emplearán dichos navegadores?, ¿y cuando la mayoría de los desarrolladores comenzaremos a aprovechar este lenguaje?, pues con toda seguridad dentro de muchos muchos años. Y mientras, otros, por su cuenta, siguen buscando soluciones a muchos de estos problemas, con mucha mas agilidad, pero basándose en las posibilidades actuales que nos permite la web.
Amigos, la web necesita del trabajo de varios equipos, pero son los equipos de los estándares y desarrollo de agentes de usuario los que deben tirar del carro. El equipo de los desarrolladores web estará al completo y dispuesto a cumplir estándares cuando esto no les suponga un coste tan elevado como el actual, y cuando les aporte un beneficio que no sea simplemente "cumplir los estándares", un beneficio económico y tecnológico real. Mientras esto no ocurra solo aquellos que creemos en los ideales continuaremos intentando cumplir estándares por una futura web mejor, ¿mejor o ideal?.
Bibliografía y algunos enlaces interesantes:
http://www.w3.org/TR/2008/WD-html5-diff-20080122/#new-elements
http://www.w3.org/TR/2008/WD-html5-20080122/#relationship
http://www.w3.org/html/wg/html5/#html-vs
http://www.w3.org/TR/xhtml2/
http://dig.csail.mit.edu/breadcrumbs/node/166
http://www.digital-web.com/articles/html5_xhtml2_and_the_future_of_the_web/
http://www.whatwg.org/
Y porque un desarrollador web profesional también debe conocer los pequeños detalles, perdón, los grandes detalles olvidados. Porque a un desarrollador web profesional debemos pedirle mucho mas que reproducir fielmente un diseño photoshop, debemos pedirle conocer y cumplir con esos detalles que el resto de los mortales no ve, que están detrás, en el lado oscuro, pero que existen.
Por eso hoy quiero hablar de un tema al que mucha gente no le da la mas mínima importancia, las unidades de medida de los elementos xhtml.
Cuando en nuestras css establecemos el tamaño de los diferentes elementos, desde margins paddings widths hasta el font-size de las fuentes, podemos hacerlo en varias unidades diferentes:
En unidades relativas:
O en unidades absolutas:
De todas las unidades anteriores siempre se recomienda utilizar unidades relativas en lugar de absolutas, a no ser que estemos diseñando un documento muy específico del que sepamos a seguro en que tipo de dispositivo se va a visualizar. De las unidades relativas se recomienda utilizar em, puesto que como vemos en la siguiente imagen la unidad px es dependiente de la resolución de pantalla, mientras que en em las distancias son proporcionales a los tamaños de fuente, por lo que si aumentamos el tamaño de la fuente se aumentan todas las distancias proporcionalmente. Así en la imagen vemos que 1px cubre 16 puntos en un documento impreso a láser de alta resolución, mientras que el mismo 1px solo cubre 1 punto en un monitor de baja resolución.
Tampoco me quiero olvidar de los porcentajes (%), siempre relativos al tamaño de pantalla o al elemento padre. Así pues podríamos tener un tamaño de fuente en nuestro documento de 1.1em (declarada en la clase body por ejemplo), y en todos sus elementos hijos ser un 10% mas pequeña por lo tanto declarada con un tamaño del 90% respecto al 1.1em de la clase padre.
Ya para finalizar os dejo 3 enlaces referencia que he utilizado para documentarme sobre este tema.
Referencia: http://www.w3.org/TR/CSS21/syndata.html#percentage-units
Tabla de equivalencias entre puntos, pixels, ems y portentajes http://www.reeddesign.co.uk/test/points-pixels.html.
Sintesis de buenas prácticas en el maquetado web http://www.w3.org/WAI/GL/css2em.htm.
Espero tener algo mas de tiempo para seguir posteando sobre estándares y accesibilidad web donde todavía tenemos mucho de que hablar.
Un saludo y solo si fuisteis buenos que os traigan muchos regalos.
