“Conflicting Absolute Positions” por Rob Swan
Rob Swan publica en A List Apart “Conflicting Absolute Positions“, un breve artículo que comenta las posibildades de ajustar las cuatro posiciones de un objeto situado absolutamente.
La técnica descrita simplifica en gran medida los problemas que surgen cuando se quiere cuadrar objetos absolutamente ya que es una solución basada en únicamente en CSS sin hacer uso de JavaScript.
El desconocimiento aparente de esta técnica es debido, una vez más, a la falta de soporte de IE5 e I6. Por suerte Rob propone una solución adaptada a estos navegadores.
Trac, gestión de proyectos
Trac es una herramienta de gestión de proyectos, principalmente de software, que unifica un sistema wiki con un sistema de seguimiento (issue tracking) con claras ventajas a la hora de trabajar con un repositorio de subversion.
Esta entrada constituye una breve guía de iniciación a Trac.
Wii Media Center
Para aquellos que habéis caído en la tentación de la Wii esta breve recopilación os vendrá de perlas para convertir vuestra Wii en un media center:
WCAG: Recomendaciones de accesibilidad
Recientemente ha habido bastante movimiento respecto a las recomendaciones sobre accesibilidad propuestas por la W3C en su Web Content Accessibility Guidelines 2.0.
Después de la polémica surgida por el borrador del año pasado (To Hell with WCAG 2), liderado por Joe Clark se creó WCAG Samurai cuyo objetivo consistía en mejorar la versión vigente.
Pues bien, a mediados del mes pasado la W3C publicó el nuevo borrador de la WCAG 2.0, esta vez con mejores críticas (WCAG 2.0: Woeful to Wonderful in One Easy Draft?), y hace un par de días se publicó la primera edición de WCAG Samurai Errata for WCAG 1.0.
En resumen: mucho por leer 
Utilizar XHTML o HTML
En primer lugar, en estos momentos, disponemos de dos definiciones principales a la hora de preparar el contenido de una página web: XHTML 1.0/1.1 y HTML 4.01, es decir uno de ellos es un documento XML y el otro no.
Desde el punto de vista de los navegadores hay dos formas de afrontar una página web. Por un lado tenemos lo que se conoce como el ‘tag soup’ y por el otro tenemos un parser XML. El modo tag soup es lento pero seguro ya que está preparado para aguantar cualquier cosa que se asemeje, por muy remotamente que sea, a código HTML. Mientras el parser XML es muy rápido pero exige que el documento sea completamente válido o si no ni siquiera se puede mostrar.
El navegador decide si utilizar un método u otro basándose en el Content Type de la página:
- text/html: se utiliza el modo tag soup.
- application/xhtml+xml: se utiliza el parser XML.
Hasta aquí la opción más evidente sería utilizar la versión más moderna, XHTML 1.1, y servirla como “application/xhtml+xml” para conseguir la mayor velocidad y calidad. Sin embargo en el mundo real hay mucho navegadores antiguos… y el IE.
En el estudio, XHTML media type test, de la W3C se comprobó el soporte real XHTML por parte de los navegadores. Echando un vistazo las cosas no parecen muy prometedoras si el sitio web incluye usuarios con navegadores que no sean de última generación.
Además, las versiones anteriores a Firefox 3 no soportan una carga incremental de XML por lo que es necesario descargar completamente la página para poder empezar su representación dando la impresión de lentitud.
Podemos bajar a la versión XHTML 1.0. La 1.1 exige que se transmita como “application/xhtml+xml” pero la 1.0 puede ser transmitida como “text/html” con lo que conseguimos ampliar nuestro público. Pero el problema es que ya hemos perdido el parser XML y volvemos al tag soup de toda la vida.
Si antes mencionábamos que uno era un documento XML y el otro no, ahora hay que plantearse si realmente merece la pena hacer uso de XHTML pues al servirlo como “text/html” hemos perdido el parser XML. Además nos encontramos con los problemas que se comentan en Sending XHTML as text/html Considered Harmful.
Lo que realmente se desea en la creación de un sitio web es conseguir la máxima accesibilidad y homogeneidad entre navegadores. Para ello nos ajustamos a un DOCTYPE determinado consiguiendo que los navegadores representen el contenido en modo “Standards compliance”.
En Activating the Right Layout Mode Using the Doctype Declaration podemos ver la influencia del DOCTYPE sobre los modos de representación entre los navegadores más populares.
En resumen, comparto la opinión de utilizar HTML 4.01 preferentemente sobre XHTML si el sitio web está orientado a un público muy general al ser la opción más segura.
Ahora bien, si necesitamos de las funcionalidades que ofrece XHTML (que sea XML válido o utilizar MathML por ejemplo) debería ser obligatorio enviarlo como “application/xhtml+xml” por lo que os recomiendo leer The perils of using XHTML properly de Roger Johansson.
