Pensar que yo uso esa misma fuente pero en urxvt (con las mismas vueltas para configurarla). Margaritas a los chanchos.

Pero personalmente considero que no solucionan ninguna falencia de la especificación actual sino que sólo satisfacen el capricho de los desarrolladores.

Fallback

Entre los requerimientos mencionan que un navegador que no implementa variables puede utilizar una regla más convencial. En este caso es redundante con la propia funcionalidad de CSS porque si yo quiero que cierto elemento tenga sí o sí cierto color no voy a delegar eso a una funcionalidad que puede fallar. Entonces el sistema de variables termina en una redundancia como:

@variables {
	mycolor: green;
}

p {
	color: green; /* para asegurarme que el texto sea verde */
	color: var(mycolor); /* redundante usando variables */
}

Otro problema es que no se especifica cómo funcionaría en el caso de las tipografías. En este ejemplo no existe forma de incluir una regla que no produzca un conflicto entre los navegadores que implementan variables y los que no.

@variables {
	myfont: monospace;
}

p {
	font-family: sans-serif;
	font-family: var(myfont);
}

Un navegador que implementa variables usaría una fuente monoespaciada, pero en el caso contrario no se usa una fuente sans-serif sino la fuente que esté configurada como por defecto (generalmente una fuente serif) —font-family es un caso excepcional entre las demás propiedades.

Diferenciación por versiones

Esta funcionalidad rompe completamente (de una manera indirecta) con el proposito de CSS, que es que un navegador que no implemente cierta propiedad pueda aún así sacar provecho de todas las demás. Funciona como un filtro con el que si cierta funcionalidad no está implementada, no se puede acceder a todo el resto de las propiedades; por ejemplo, que se requiera contenido generado para que también se indique qué color de fondo usar. En el caso de las variables esto se logra de manera muy sencilla:

@variables {
	mybg: black;
	myfb: white;
}

html {
	background-color: var(mybg);
	color: var(myfg);

es perfectamente equivalente a

html {
	background-color: black;
	color: white;
}

sólo que el primer ejemplo no podría ser interpretado por ciertos navegadores. El uso de variables crea un limite infranqueable (manejado por los desarrolladores) entre navegadores viejos y nuevos.

Organización

Esto no es tanto una falencia de la propuesta sino una cuestión más ideológica: el sistema de variables sólo existiría por la ineptitud de los desarrolladores. Si ciertos elementos tienen que usar el color rojo, lo más inteligente sería organizar las declaraciones de tal manera que la declaración sea hecha una sóla vez. En lugar de un despelote como

 p {color: red; /* varias propiedades más */}
ul {color: red; /* varias propiedades más */}
h3 {color: red; /* varias propiedades más */}

se puede utilizar un equivalente como

p, ul, h3 {color:red;}
p, ul, h3 { /* otras propiedades */ }

Existen montones de artículos que repiten hasta el cansancio cómo organizar las declaraciones de CSS.

¿Algún pro-variables y pro-innovacion que quiera contradecirme?

Descargo: Esto no es una burla a los desarrolladores de IceCat. Es una simple jugarreta sobre lo díficil que es controlar cada pequeño detalle cuando se trata de licencias. Eso no quita que sí creo que esos dos logos deberían ser removidos del paquete (si es que todavía no fue hecho).

Aún así esto no parecer significar que Lynx realmente pueda analizar XHTML (y por extensión XML), sino que sólo le da una vuelta de tuerca a los media-types. Lynx ahora asume que cualquier documento servido como application/xhtml+xml, application/xml y text/xml puede ser analizado como si fuera HTML, entonces no hace falta descargarlo para pasarlo a otra aplicación.

De esto se desprende que Lynx no comprueba que un documento XML esté bien formado (porque lo analiza según las reglas más laxas de HTML) y también que no reacciona a los namespaces —un elemento de SVG es simplemente un elemento desconocido que se muestra como un elemento en linea.

El sistema consiste en bajar un pequeño instalador que se encarga de descargar un gran paquete de aplicaciones y dependencias. La primera versión pública ya apareció en 3 de noviembre de 2007 (November 3rd, 2007: KDE-Beta4 packages are available for download —por eso mencionaba lo de noticias viejas).

Lo interesante del asunto es que una de las aplicaciones que (obviamente) está siendo portada es Konqueror, lo que aumenta la cantidad de navegadores web en Windows y convierte a la dupla Internet Explorer/Trident en la única (actualizada) disponible (nativamente) para una única plataforma —esto también significa que la cuota de mercado de Internet Explorer no tiene por qué ser (por siempre) proporcional a la de Microsoft Windows, disminuyendo la importancia del mismo.

Epilogo: Remarqué el hecho de que fuera una implementación nativa porque hacer funcionar aplicaciones (de KDE) en Windows tampoco es una novedad. Desde hace rato es posible usando cygwin y también es posible recurriendo al sistema de andlinux. La diferencia es que ambos proyectos se basan en una cierta forma de emulación o al menos de hacer creer a la apliación de que está corriendo en un verdadero entorno UNIX. En el proyecto oficial de KDE se menciona la remoción de código especifico de la plataforma Linux en su paso a Windows. Visualmente hablando habría que comprobar la diferencia en cómo se integra con el resto del sistema, especificamente las ventanas —en el caso de cygwin las aplicaciones parecen funcionar dentro de una ventana creada por cygwin. Y por otro lado comprobar que se respetan las convenciones de directorios de Windows (incluyendo letras para las particiones y discos).

• Descargar instalador para Windows.
• ars technica hace una revisión historica en KDE goes cross-platform with Windows, Mac OS X support.
• The KDE Windows Project
• Some thoughts about kde on windows es el blog de uno de los desarrolladores.
• Capturas de pantalla de aplicaciones de KDE funcionando nativamente en Windows en Install KDE 4 on Windows

Para que esto no ocurra (porque es una reverenda porquería) hay desactivar la opción En PageBar Open URL On MiddleClick en opera:config.

Un problema menos desde mi paso (definitivo) a Ubuntu Linux.

Cuando se habla de navegadores web populares siempre se mencionan al omnipresente Internet Explorer, a su rival Firefox y a mi favorito, Opera. Lamentablemente siempre se menosprecia a Opera cuando se habla de estadísticas por su porcentaje de mercado ronda el 1%. Lo que pocos parecen pensar es que una cantidad del 1% es algo si se compara con otros navegadores más oscuros (dejando de lado a Safari que tiene una cuota de mercado similar).

El verdadero navegador alternativo ha sido (para mi gusto) iCab para Mac OS. iCab se ha mantenido como un desarrollo con código cerrado de una única persona que funciona en versiones antiguas de Mac OS. Lamentablemente iCab tiene un oscuro pasado por un motor de renderizado comparable a Netscape 4; pero para el lanzamiento de su versión 3 no sólo logró mejorar este aspecto sino que quedó como uno de los primeros navegadores en superar el test Acid2. iCab, al igual que Opera, es un navegador que ha logrado sobrevivir aún siendo shareware en un mercado aún más alternativo como son las Macintosh —una minoría en la minoría— basando su éxito en las funcionalidades.

Lo bueno algún día acaba. Desde principios de 2008 cuando fue publicada la versión 4 de iCab, el motor de renderizado propietario que se venía utilizando, junto al intérprete de JavaScript InScript, fueron reemplazados por WebKit, el núcleo de Safari (que incluye a WebCore para renderizado y JavaScriptCore para JavaScript).

Lo más triste de esto es que Macintosh venía siendo la plataforma con más diversidad de motores de renderizado (decentes) hasta el profundo cambio de iCab (si la comparamos con Windows y Linux). Hagamos cuentas de los navegadores más usados (por motor de renderizado):

En Linux se cuentan cuatro (todavía):

• KHTML (junto a KJS) en Konqueror. Esto casi no cuenta porque los desarrolladores de KDE están usando WebKit en ciertas versiones de Konqueror. Aclaración: no llevo demasiado control sobre este punto en particular; a mí me tomó de sorpresa el ver que se distribuían versiones con WebKit.
• Gecko en Firefox, Galeon y otros.
• Presto en Opera.
• WebKit como motor de renderizado de Epiphany.

En Macintosh quedan sólo tres, o tres y medio si contamos a Tasman en Internet Explorer para Mac que fue un motor de renderizado pionero y de muy buena calidad).

• WebKit en Safari, Shiira, OmniWeb y ahora iCab.
• Gecko en Firefox y Camino.
• Presto en Opera.

En Windows se cuentan cuatro que se continuan desarrollando:

• Trident (con su futuro sistema de subversiones) en Internet Explorer.
• Gecko en Firefox y K-meleon
• Presto en Opera.
• WebKit en Safari para Windows y Swift.

Dejo de lado lo que se refiere a navegadores para plataformas móviles porque soy un ignorante total, a navegadores que podrían correr en cualquier cosa como Lynx y otros que están en estado vegetativo como Dillo.

Adios a un motor de renderizado; una extravagancia menos al momento de planear testcases.

Más para leer en Requiem for a rendering engine y The Year in Browsing: The Little Engine That Could y el anuncio oficial sobre el cambio en iCab en iCab 4.0.0 and iCab 3.0.5 Public Releases.

La solución consiste en ejecutar el Configuration Editor —no aparece en el menú de aplicaciones a menos que lo editemos—; para eso desde una terminal ejecutamos gconf-editor y buscamos la sección /desktop/gnome/applications/window_manager y modificamos los campos current y default por /usr/bin/metacity.

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

Los otros tres (o cuatro) navegadores (o motores de renderizado) principales han mejorado sus capacidades con el paso de los años y eso no ha impedido que logren tener su cuota de mercado (que varía según qué navegador tiene mejores funcionalidades). Ninguno de ellos ha tenido que dejar tan en claro su identificación salvo cuando tienen que camuflarse como Internet Explorer.

¿Qué es lo que diferencia a Internet Explorer del resto? La frecuencia de actualización. Practicamente no se escucha de alguien que desarrolle un sitio basandose en la implementacion de la corrección menor de un navegador (por ejemplo, Mozilla Firefox 2.0.0.11 Fixes Canvas Regression, Mozillazine) pero si de antemano uno sabe que un error va a perdurar por años es inevitable resignarse a convivir con él.

Entonces también es posible que la propuesta de marcar (por partida doble) una página bien hecha sea su forma de excusarse por una incapacidad de publicar con suficiente frecuencia actualizaciones sobre Trident.

Para colmo esta propuesta es terriblemente excluyente (suponiendo que todos los navegadores la implementaran) porque requiere que un desarrollador conozca absolutamente las características de cada implementación. Sí, es casi lo mismo que pasa ahora pero en este caso requiere saber no sólo sobre la versión más actual o popular sino sobre todas anteriores —sería el infierno de Internet Explorer 5.5 y 6 extendido a los demás navegadores.

El plan de Microsoft es mantener (al lanzamiento de la versión cuatro diferentes versiones de Trident por cada una de Internet Explorer a la fecha: 5.5 (el quirks mode actual), 6, 7 y 8; una exageración cuando la web se divide entre la más estrafalaria sopa de tags y sitios bien hechos (o al menos con buenas intenciones). Los sitios que van a funcionar mal en Internet Explorer 8 ya funcionaron mal con la versión 7 y los que sólo funcionan con la versión 6 son los que serán actualizados o morirán; es superfluo y una pesada carga de mantinimiento tener subversiones para el quirks mode.

Pero lo que es peor: que otros navegadores sigan el ejemplo de Internet Explorer y que los sitios sean modificados (aún más) para verse bien en él sería reconocerle una importancia que en el mundo (ideal) de los estándares no debería existir (y que va perdiendo contra otros navegadores). Porque esta movida implicaría mayor trabajo para todas las compañias desarrolladores de navegadores que tendrían que cargar en cada versión con su vergonzoso pasado.

Por último, un pequeño error de concepto en la idea. ¿OtherUA=4 significa que los otros navegadores deben actuar como su correspondiente cuarta versión aún cuando Firefox 4 no será lo que fue Opera 4? Y suponiendo que se estandarizara una lista de números que abstrayera los números de versión y especificara que cierta versión de un navegador es equivalente a tal otra, siempre estaría la posibilidad de un navegador informe mal este número (por error o intencionalmente).

¿Internet Explrorer mostrará correctamente el Acid2 aún cuando la página original no está optimizada para Internet Explorer 8?

Los navegadores han mejorado y el mundo mejoró; Internet Explorer quiere mejorar pero el mundo se puede acabar.

• En Perspective: Acid2, Acid3, and the power of default (News.com), Håkon Wium Lie ya predecía esta movida de Microsoft.
• Meta Madness —John Resig. Esta movida convertiría a todos los navegadores en bloatware.
• Versioning, Compatibility and Standards —Surfin’ Safari. WebKit no ha recibido (suficientes) reportes de sitios que se vean mal.
• Jeffrey Zeldman (In defense of version targeting) y Eric Meyer (Version Two) están de acuerdo con la iniciativa. Este es uno de los momentos en que me pregunto si los del resto somos terriblemente estupidos o si los idolos dorados comienzan a desteñir.

Actualizacion 2 de marzo de 2008: No hace un motor de renderizado nuevo para destruir la web. Alcanza con modificar la identificación de agente de usuario. During internal testing, we have encountered a small number of sites which fail to recognize IE8 because they are performing exact string matches to look for specific IE version strings. —The Internet Explorer 8 User-Agent String.

Actualización 4 de marzo de 2008: Internet Explorer 8 usará por defecto la versión más actual del motor de renderizado. Microsoft Corp. is now configuring the settings in Internet Explorer 8, the upcoming version of its browser, to render content — by default — using methods that give top priority to Web standards interoperability.— Microsoft Expands Support for Web Standards.

server 190.2.0.201, stratum 2, offset 2.501166, delay 0.33630
server 200.43.64.72, stratum 1, offset 2.377004, delay 0.20010
server 200.80.32.172, stratum 2, offset 2.334814, delay 0.32558
1 Jan 23:01:08 ntpdate[5465]: step time server 200.43.64.72 offset 2.377004 sec

Al margen, fue interesante leer como nota introductoria que el cambio de hora en Argentina demuestra que nada cambia.

Actualización 3 de enero: Mi error. No sabía nada sobre cómo maneja internamente la hora el sistema operativo; todo el tiempo está en hora universal y es modificada para el usuario según la zona horaria que uno configura. Yo llegué a pensar que distintos servidores reportaban diferentes horas según el país en que se encuentran. Al actualizar el paquete tzdata se sincronizan correctamente los relojes. Esto también tiene su origen en lo díficil que me resultó configurar la zona horaria y coordinar la hora entre Ubuntu ¿Dapper? y Windows XP.