20 años de Internet Explorer

Captura de pantalla de la interfaz de Internet Explorer 1.0
Así era el navegador de Microsoft en 1995. Imagen ‘robada’ de la Wikipedia

Pocas efemérides hay en internet que se vayan a celebrar tan poco como el vigésimo cumpleaños, que se celebra hoy, de Internet Explorer. Como cuenta la Wikipedia, un dieciséis de agosto, pero de 1995, se lanzaba Internet Explorer, que en aquel momento era básicamente una versión de Mosaic en la que trabajaron seis personas. Estamos hablando de hace tanto tiempo que Explorer no soportaría tablas hasta su versión 1.5, que llegaría seis meses más tarde.

Se trata de un periodo interesante de la historia. De los navegadores que existen hoy, pocos hay más longevos: Opera se había lanzado unos meses antes y la 1.0 de Netscape Navigator data de diciembre del 94.

La de 1995, además, era la versión más odiosa de Microsoft: en 1994 el Departamento de Justicia de los Estados Unidos había lanzado su famosa demanda ‘antitrust’ contra Redmond por sus prácticas anticompetitivas desde 1988. Microsoft estaba dispuesta a comerse el mundo, casi literalmente.

Aun con la ventaja competitiva innegable de venir con el sistema operativo (estamos hablando de cuando un módem de 28800 baudios sonaba a lo último de lo último, y descargarse Navigator no era exactamente una trivialidad), IE no arrasó, precisamente: durante unos [pocos] años Netscape dominó el paisaje web como ninguna otra empresa ha vuelto (ni volverá, esperemos) a hacer. No fue hasta unos tres o cuatro años más tarde que Microsoft decidió echarle músculo de verdad al asunto y espabilar con IE5, que combinó la potencia de los de Redmond al desarrollar software (IE5 y 6 eran mucho mejores que la competencia, por difícil de creer que resulte, y con IE5 llegó una funcionalidad, XMLHttpRequest que, pese a su horrendo nombre, dio pie a la revolución que supondría AJAX, la base de lo que hoy conocemos como aplicaciones web) con la universalidad de su sistema operativo y la incapacidad de Netscape de mantener el código de Navigator para situarse como número uno. IE6 representó, en 2001, por un lado, el mejor navegador de la historia de manera indiscutible y, por el otro, el fin de la guerra de los navegadores: punto, juego, set, partido y campeonato para Microsoft. Game over. Desafortunadamente, lo que vino después era lo que se podía prever: una vez aplastada la competencia, Microsoft se quedó sin ningún incentivo para mejorar su navegador… y así lo hizo. Internet Explorer 7 no llegaría hasta finales de 2006. Cinco años más tarde. En “tiempo internet”, varias eras tarde.

Los desarrolladores de la época (y los pocos diseñadores web que había), por mucho que nos guste reescribir la historia, estaban encantadísimos en 2001 con el monopolio: un único navegador para el que desarrollar es lo mejor que te puede pasar… O no. En 2002 de las cenizas de Netscape se fundaba Mozilla y anunciaba la creación de un navegador, muy adecuadamente llamado Phoenix. Phoenix no llegaría hasta un par de años más tarde (recordemos: el código de Navigator era un absoluto desastre), rebautizado como Firefox, que supondría un (re)nacimiento de los estándares web. Firefox, sin prisa pero sin pausa, comenzaría a restar cuota de mercado a Explorer, con la ayuda inestimable de la propia Microsoft y su indolencia infinita (nunca más le darán en Redmond cinco años de margen a un enemigo para renacer de sus cenizas).

Pero Firefox ganaba mercado… fuera de las empresas del Fortune 500. Dentro de esas empresas, el panorama era muy diferente. Si hay algo que les gusta a los departamentos de sistemas de información de las grandes empresas es estandarizar. Básicamente, todos los PCs de todas las grandes empresas tenían Internet Explorer 6 instalado. Y ningún otro navegador. Los desarrolladores de las intranets de todas esas empresas, dado el panorama, optaron por no “desarrollar web” sino “desarrollar para IE6”. Una decisión perfectamente comprensible, razonable incluso… y absolutamente catastrófica. Las peculiaridades de IE6 interpretando los estándares (conviene recordar: comparado con Navigator, IE6 era la octava maravilla) estaban lejos de contemplarse con el odio que se ganarían (con absolutamente merecimiento) unos años más tarde: en ausencia de otro navegador al que dar soporte, diseñadores y desarrolladores fueron acostumbrándose a ellas y construyendo toda una serie de trucos, como el maquetado con tablas, que hoy nos escandalizan pero que en aquel momento no parecían mala idea. Como sabe todo el mundo que haya trabajado en una empresa de un cierto tamaño, las intranets fueron desarrollando parche sobre parche sobre parche en una pesadilla imposible de mantener.

Para cuando Firefox adquirió madurez y los usuarios comenzaron a reclamarlo, la tarea de adaptar las webs del mundo a los estándares resultó ardua, pero valió la pena. Excepto en el reducto de la Galia conocido como las intranets de las grandes empresas, cuyos departamentos de sistemas de información decidieron que era más fácil obligar a sus trabajadores a acceder a la intranet con IE6 que intentar desfacer el monumental entuerto. IE6 para la intranet, un navegador moderno para el resto de la web (o para la web, quizá debería decir mejor: las intranets no eran “web”, sino “cosas en HTML para IE6”), aquí paz y después gloria. O no.

Porque Microsoft se había dormido mucho con el tema de los navegadores, pero en algún momento tenía que darse cuenta de que había que espabilar. Y tarde, pero lo hizo. En 2006 llegaría IE7, IE8 en 2009 y para 2011 teníamos IE9 (el coloso Microsoft estaba acostumbrado a los ciclos de desarrollo de Windows, Office y sus herramientas de desarrollo: lanzar una versión del navegador cada dos años era, a sus ojos, recuperar la velocidad de crucero). Pero el ritmo glacial de Microsoft resultaba excesivamente frenético para —sí, lo habéis adivinado— los departamentos de sistemas de información. Microsoft era casi omnipotente, pero no podía arriesgarse a cortarse el grifo de los ingresos de las actualizaciones de todos los Windows de todos los PCs de todas las empresas del Fortune 500 con intranets que dependían vitalmente de todos los bugs de IE6. Nadie habría sido más feliz exterminando esos bugs de manera lenta pero segura que el equipo de desarrollo de IE. Pero Microsoft no podía permitirse ese “lujo”. IE7, 8, 9… todos se vieron obligados a reproducir, contra su propia voluntad, los errores de IE6. Y, de rebote, mientras la cuota de mercado de Explorer bajaba de forma inexorable pero lenta, a los diseñadores y desarrolladores web del mundo no les quedaba otra que someterse a los deseos de los galos irreductibles de las intranets, porque Internet Explorer seguía conservando suficiente presencia como para que ignorarlo fuese un riesgo inasumible. Bienvenidos al “maravilloso” mundo del diseño y desarrollo web.

Hoy, casi una década después del lanzamiento de IE7, parece que finalmente el panorama ha cambiado. Lo que quizá haya contribuido más a ello es que los CEOs del Fortune 500 hace tiempo que tienen iPads con los que quieren acceder a sus intranets. Los CIOs del Fortune 500 pudieron más que Microsoft, pero todo el mundo sabe que el CEO puede más que el CIO. Aún quedan cosas en las intranets que dependen de IE6 (o de lo que queda de IE6 dentro de IE8, 9, 10 e incluso 11), pero cada vez son menos y todo ese código web infecto parece definitivamente herido de muerte. Los esfuerzos de Microsoft por conseguirlo (si hay algo peor que desarrollar para IE6 y sus herederos tiene que ser mantener el código de IE6 en sus herederos) se han redoblado en los últimos tres o cuatro años y el navegador por defecto del sistema operativo por defecto de Microsoft ya no se llama Internet Explorer, sino Edge… En el blog de desarrolladores de Edge contaban con alegría en mayo cómo le habían extirpado a Edge más de doscientas veinte mil líneas de código al separarlo de Explorer. Por la borda se habían ido el soporte para ActiveX, los “Browser Helper Objects”, VBScript, los filtros y transiciones en DirectX… Todas ellas características que fueron útiles —revolucionarias, incluso— en su momento… y que se volvieron después zombies que, en algunos casos más de una década después de su creación, siguen pululando por ahí…

Repito: doscientas veinte mil líneas de código. La magnitud de la cosa es de difícil descripción. Aún suponiendo que fueran 220,000 líneas seguidas, eso son, para los que alguna vez habéis visto papel de impresora de agujas, más de tres mil hojas de papel de 381 por 279 milímetros (el más ancho que hayáis visto los que lo recordéis). Alucinante.

2015. Y parece que vemos la luz al final del túnel. Pero no nos engañemos: seguimos en el túnel. Y es que IE y su código zombi siguen rondando. Incluso en Windows 10, lo último y “más mejor” de Microsoft, sigue ahí, en el cadalso del desarrollo web: el navegador por defecto de Windows 10 es Edge pero, sin mucho esfuerzo, uno puede resucitar el fantasma y arrancar Internet Explorer 11 para “disfrutar” de esas doscientas veinte mil líneas de código y todas esas funcionalidades zombi.

Capturas de pantalla de una misma web visitada con Edge y con IE11
A la izquierda, Edge. A la derecha, Internet Explorer 11

En fin. Y en cualquier caso. Felicidades, Internet Explorer: no se cumplen veinte años todos los días. No hay tantas marcas en el mundo de la informática que puedan decir que han cumplido dos décadas. Pocas hay que nos hayan aportado tanto. Pocas hay que nos hayan robado tanto. Probablemente sea Explorer lo único que haya en la intersección de ambos conjuntos. Te odiamos pero, muy muy en el fondo, sabemos que eres parte imprescindible de nuestra historia tecnológica y que no seríamos lo que somos sin ti. Felicidades. Y muérete ya.


PS Parece que Microsoft y yo coincidimos, por una vez…

Réquiem por Presto

La bomba ha explotado hoy, pero la liebre saltó hace casi un mes:

Sí. Opera, los noruegos del navegador que casi nadie conoce (en mi entorno: Chris Mills nos contaba en Mosaic, hace dos años largos, que en mercados como Rusia, Bielorrusia y Ucrania tenían un share nada desdeñable (una entrevista en la que yo halagaba la capacidad de desarrollo de los noruegos, por cierto)) pero que, entre otras cosas, dio a luz el elemento de interfaz sin el que no podríamos pensar en los navegadores (las pestañas) y una tecnología sin la que la web no habría podido llegar a donde ha llegado (CSS, nada más y nada menos)… se proponía lanzar un navegador sustituyendo su motor de rendering, Presto, por el que ‘anima’ a Chrome y Safari: Webkit. Hell. Freezes. Over.

Pero si aquello sonaba cataclismático, lo de hoy ha ido mucho más allá…

Opera va a abandonar Presto y Carakan, su excelente motor de JavaScript, por WebKit y V8, el motor JavaScript de Chrome y su hermano de código abierto, Chromium. Quizá no sea tan doloroso como el día que murió Netscape, pero dentro de nada vamos a pasar de tener cuatro grandes motores de rendering (Presto, Webkit, Gecko y Trident) a tres (y lo mismo pasará con los motores JavaScript). La biodiversidad del entorno se ha reducido en un 25%. Eso, en cualquier ecosistema, es, ya usaba la palabra antes, un cataclismo.

Como dice Bruce Lawson, Presto va a seguir vivo una buena temporada:

(buena parte del negocio de Opera se alimenta de los navegadores embebidos en teles y otros dispositivos)… pero si ese tuit no suena a entierro, so sé qué lo hará…

Si hay que buscar culpables, la lista va a ser inacabable:

Mientras para muchísimos desarrolladores sólo exista Webkit primero (en la forma de Chrome y Safari, principalmente), y Firefox y el inevitable Internet Explorer (que se mueve muy lento y es víctima de muchísimas inercias imparables, pero hoy en día es un navegador más que aceptable, en sus últimas versiones) después, y ni dios tenga en cuenta el resto, la vida de Opera dependiendo de respetar los estándares pasaba por decisiones tan controvertidas como las de ‘adoptar’ los prefijos -webkit- (y pensar que creímos que el ruido que oímos entonces era el del infierno congelándose…). Y eso, aceptémoslo, era insostenible.

Como sucede en todos los sepelios, ahora resulta que el muerto era un tipo fantástico:

Lo jodido (disculpad el vocabulario, pero es que todo esto me ha dolido bastante) es que el muerto de verdad era un tipo fantástico. Personalmente, durante mucho tiempo ignoré Opera tan absolutamente como cualquier otro. Pero un Mac con sólo 2 gigas de RAM y una época de versiones Firefox especialmente voraces me llevaron a adoptar al navegador noruego durante unos meses. Al final dos gigas de RAM más y una moderación del apetito de Firefox hicieron que volviese a los orígenes (la cabra tira al monte, y ahora se siente culpable), pero durante aquel periodo tuve la oportunidad de comprobar que Opera era, efectivamente, un software fantástico… maltratado hasta la saciedad por propios y extraños (con el coloso Google a la cabeza del pelotón) con prácticas como el sniffing de agentes de usuario implementado con el culo (se me vuelve a descontrolar el vocabulario, me temo que me vais a tener que aguantar). La rendición de Opera me duele como al que más, pero no queda más remedio que aceptar (hasta aplaudir, con dolor) la decisión…

Para los que no veáis la dureza del mazazo que se llevan hoy los estándares web (que se culmina hoy, quizá habría que decir mejor), el tuit que, creo, dice más en menos:

Apenas ha hecho ruido fuera de una comunidad de freaks, pero hoy ha sido un muy mal día para la web. Descansa en paz, Presto.


Una recopilación de artículos sobre el tema:

El -webkit-problema

El que confíe, espere y desee que algún día desarrollar para la web sea una tarea fácil porque sólo hay que comprobar las cosas en un pequeño número de circunstancias debería tener en cuenta que eso ya pasó una vez: cuando Internet Explorer 6 dominaba la Tierra. Que nadie se llame a engaño: cuando Explorer 6 salió al mercado (un 27 de agosto de 2001, no ha llovido…) fue lo mejor que le podía pasar a la web en aquel momento y, cuando un par de años más tarde alcanzó una cuota de mercado del 90%, diseñadores y desarrolladores web pudieron, por primera vez, vivir tranquilos con un navegador decente (para la época). Hoy sabemos que el monocultivo IE6, de hecho, ahorró bastante trabajo a corto plazo… y tuvo tantos efectos perniciosos para la web que hoy en día renegamos de él como si nunca debiese haber pasado (con bastante razón, además).

Un panorama muy Webkit

La situación actual, a primera vista, no tiene muchos puntos en común con la de principios de siglo, pero determinadas prácticas —y, sobre todo, el advenimiento imparable de la web móvil y el cambio de panorama que supone— nos están poniendo en una situación de riesgo que gira alrededor de Webkit, el motor que mueve a Chrome y Safari, principalmente, en el escritorio, pero sobre todo a los navegadores por defecto de iOS y Android. Por poner unos números (y dibujitos) al asunto, en enero de 2011, en este modesto blog estábamos así (disculpas por el uso de tartas, se aceptan sugerencias de mejora):

Cuota de navegadores en obm. Enero de 2011. IE: 42.4, Firefox: 30.1, Webkit: 25.3

Un reparto no óptimo (sobre todo porque la cantidad de IE6 era no negligible), pero diverso. Pero si miramos el mismo reparto en los últimos 31 días, el vuelco ha sido más que notable:

Cuota de navegadores en obm. Enero de 2011. IE: 42.4, Firefox: 30.1, Webkit: 25.3

Esa brutal subida de los navegadores Webkit tiene dos vectores principales: Chrome, por sus avances tecnológicos y la pasta en publicidad que se deja Google, por un lado, y los navegadores móviles, por el otro, como ya comentábamos.

No, no estamos como en 2001 o 2002: de momento la cosa es muchísimo más diversa y, además, no podemos acusar a Google ni a Apple (ni a Adobe, que también invierte lo suyo en el desarrollo de Webkit) de las prácticas monopolísticas que usó Microsoft en su momento. En ocasiones Google juega de manera discutible, al menos en mi opinión, pero es innegable que Webkit avanza más deprisa que Firefox y Opera (Microsoft es capítulo aparte) en bastantes aspectos relevantes (no todos, pero esa es otra historia). Si a eso le sumamos el músculo económico para el marketing del que disponen y la inteligencia que demuestran en usarlo, el resultado no es precisamente de extrañar.

Y luego queda, claro, el tema de la web móvil (y para otros dispositivos, como las teles “conectadas”, que cada día abundan más). Ahí el iPhone, el iPod, el iPad y todo el ecosistema Android han hecho maravillas por Webkit. Su dominio no es absoluto (de hecho, Statcounter afirma que Opera sigue siendo el navegador móvil más usado globalmente) pero sí lo es en mindshare: si alguien encarga una web y llega a preguntar por la posibilidad de consultarla desde el móvil lo más probable es que en su bolsillo haya un iPhone o, en su defecto, un móvil Android; en ambos casos, el navegador que usará para sus pruebas será Webkit.

-propiedades-avanzadas-css

Volvamos a los navegadores y su evolución. Ya hemos comentado en alguna ocasión por aquí (y no deja de ser una obviedad) que los comités son lentos. Los grupos de trabajo del W3C son incapaces de seguir el ritmo que marcan los navegadores (de hecho, tampoco es su cometido correr detrás de estos cual galgo tras liebre), especialmente en lo que respecta a los avances en la creación e implementación de nuevas propiedades CSS (ejemplos paradigmáticos: border-radius o gradient). Una vez constatado este punto, se hizo necesario establecer un mecanismo para que los diferentes motores puedan implementar nuevas características sin que todos muramos en el intento… y se llegá la [aparentemente inofensiva] idea de los prefijos de fabricante: si Webkit decide implementar border-radius experimentalmente, lo hace prefijando un -webkit-. Mozilla usa -moz-, Opera -o- y Microsoft -ms-. La idea es que, en algún momento, border-radius pasará a ser una propiedad estandarizada CSS y nos podremos olvidar de los dichosos prefijos (pensad que implementar cuatro propiedades con prefijo más la oficial es más bien incómodo…).

border-radius es un ejemplo en el que todo el mundo se pone de acuerdo más o menos rápida y eficientemente (y un caso en el que, de hecho, nos podríamos haber saltado el proceso de los prefijos). gradient es un ejemplo de lo que pasa cuando cada fabricante tiene sus propias ideas sobre cómo debería funcionar algo: si os pasáis por el Ultimate CSS Gradient Generator podréis comprobar que Microsoft usaba una sintaxis atroz para conseguirlo desde los tiempos de IE6, los Webkits usaban otra sintaxis no tan fea pero que tampoco era ninguna virguería, que Mozilla comenzó a usar una sintaxis algo más razonable con Firefox 3.6 y que, después, esta sintaxis la fueron adoptando sucesivamente Opera, Webkit a partir de una cierta versión (desde Chrome 10 y Safari 5.1), Microsoft con IE10 (el día que salga) y que ahora hasta al W3C le parece bien la sintaxis, con lo que deberíamos poder utilizarla, en los navegadores modernos, sin semejante pesadilla de prefijos…

border-radius, pues, demuestra la necesidad de este mecanismo para introducir, poco a poco, propiedades experimentales

¿Y el problema?

[Un buen trozo de lo que sigue sale, en gran parte, de Vendor Prefixes – about to go south, de Remy Sharp.]

El problema es múltiple. Resulta ser que, naturalmente, siempre hay un navegador que hace las cosas antes que los demás. Y que, además, ese navegador tiene la manía de ser Webkit y, por tanto, acostumbra a llegar al usuario con las marcas Safari y/o Chrome. Y que Firefox y Opera suelen llevar un retraso notable (a ver quién es el guapo que le aguanta el ritmo a Google + Apple + Adobe…). Y que Internet Explorer suele llegar a la fiesta cuando se ha largado hasta el personal de limpieza (estos no tienen la excusa de la falta de recursos, pero también lidian con sus problemas: si fuera por el equipo de desarrollo de IE la cosa sería diferente, pero los ciclos de Microsoft y las necesidades del soporte corporativo son un tema en el que mejor no entrar, si no es estrictamente necesario)…

En algún momento, además, las propiedades experimentales (con prefijo) deberían o bien dejar de existir porque se demuestran poco útiles o bien dejar de existir porque han pasado a ser de uso general y, por tanto, a implementarse sin prefijo. Esto es, que sí o sí, las propiedades experimentales deberían venir con fecha de caducidad, por un motivo u otro.

¿Qué pasa? Los diseñadores, natural y comprensiblemente, implementan las nuevas características que trae Webkit para mejorar sus diseños, tan pronto como les resultan útiles. No importa si uno es de la escuela hard boiled, si predica el progressive enhancement o si es fiel a la doctrina de la graceful degradation, se trata de una práctica extendida y aceptable y respetable… siempre que uno sea consciente de que se trata de propiedades experimentales. ¿Qué significa esto? Que mientras sólo Webkit tira de la propiedad, usamos -webkit-propiedad. Y al cabo de un tiempo, cuando Mozilla y Opera la implementan, añadimos las correspondientes -moz-propiedad y -o-propiedad. Si, por algún milagro, Microsoft finalmente hace lo propio antes de que llegue el W3C, añadimos la -ms-propiedad. Y cuando llega, parsimonioso como debe, el W3C, añadimos la propiedad… y con un poco de suerte, hasta vamos eliminando las propiedades con prefijo a medida que los navegadores anticuados van desapareciendo del mercado.

¿Da miedo el procedimiento del párrafo anterior? Si no miedo, como mínimo una inmensa pereza, ¿no? Si no disponemos de alguna manera automatizada de hacerlo (posibles herramientas son Prefixr o -prefix-free), y tenemos unos cuantos diseños que mantener, el trabajo es digno de Job (siempre he sospechado que Job, de hecho, era front end de profesión). El resultado es que todo el mundo (todos los buenos diseñadores, al menos) corre a implementar las -webkit-. Pero que con cada paso posterior se pierden muchos, muchísimos trabajos. Y no sólo trabajos de demostración, sino sitios en producción, que deberían dar la mejor experiencia posible a todos los usuarios, independientemente del navegador que estén usando en ese momento…

¿Es tan grave la cosa?

Depende del punto de vista, desde luego. Si eres desarrollador en Mozilla y Opera y te acabas de pasar una noche sin dormir para colar en la última release la propiedad CSS de moda, y luego resulta que la mayoría de diseños que la usan en en Webkit pasa de tu cara, tiene que doler mucho.

Pero hasta a los desarrolladores de Webkit les tiene que doler tener que mantener sus -webkit-propiedades en el código: si las quitan, sus navegadores “romperán” muchos sitios que ahora usan toda la potencia de CSS, pero al mantenerlas pierden un milisegundo por aquí, otro por allá… Poco, quizás, pero con la lucha por la velocidad entre navegadores (y la creciente complejidad de los diseños de las páginas), hasta la última centésima cuenta…

Y si eres un diseñador, el dolor de cabeza de seguir la carrera metro a metro y decidir en cada punto cuál es la menos mala de las soluciones tampoco acaba de ser el más deseable de los futuros…

La cosa ha llegado, en los últimos días, a que los no-webkit se planteen (públicamente, en las discusiones del correspondiente grupo de trabajo del W3C) dar soporte a las -webkit-propiedades en su código. Si somos benevolentes, un parche horroroso. Siendo muy estrictos, una vulneración durísima de todo el proceso de estandarización. En cualquier caso, un efecto no previsto y muy poco deseable del proceso de innovación de los navegadores… :-(

Esperemos que el curso de la cosa comience a corregirse. De otra forma, los resultados previsibles (soporte incompleto a navegadores que cumplen los estándares, código spaguetti por todos lados, ineficiencias a mansalva) van a complicar la vida de desarrolladores y usuarios. Poco a poquísimo, pero la situación se iría haciendo más y más insostenible con el tiempo.

Seguiremos informando.


Lecturas y recursos recomendados y recomendables

Muerte al WYSIWYG

Imagino que nos ha pasado a todos los que tenemos una cierta preocupación por los estándares web: ves una web nueva, con el logo de una agencia de diseño web, que, al menos de salida, aparenta estar bastante bien hecha. Ctrl+U (o manzanita+U, o la combinación que toque) y, efectivamente, de salida, estaba (pretérito imperfecto, muy imperfecto) bastante bien hecha. Hasta que llegas a la parte que ha rellenado el usuario, al que habían prometido que “con el gestor de contenidos que te vamos a montar, que es fantástico, el contenido te lo puedes ir actualizando tú mismo”. Y así comienzan a aparecer lindezas como

<P>&nbsp;</P>

Sí señor, excelente manera de añadir espacio blanco (esas mayúsculas en los elementos HTML a estas alturas duelen a la vista pero no son incorrectas, o sea que las pasaremos por alto)… O su clásica alternativa

<P><BR>...</P>

Las listas no ordenadas también resultan ser claros ejemplos de cómo aplicar los estándares (se nota la ironía, ¿verdad?):

<P><FONT color=#800080>- </FONT>El texto que toque...<P>

¡Olé! Siguiente atentado contra la semántica y los estándares: los “títulos”…

<P><STRONG>Un título cualquiera </STRONG></P>

(Ese espacio entre el final del título y el </STRONG> es la guinda (o la guindilla, quizá mejor, o algo…) Y luego tenemos combinaciones que pasarán a la historia, como

<P><FONT color=#800080 size=3><STRONG>5- Un quinto punto 
cualquiera</STRONG></FONT></P>

…también conocido como “cómo provocar un desprendimiento de retina en un solo párrafo”…

Dejando por un lado la acidez barata (es que estoy pasando una etapa muy sensible con el tema, oiga), la culpa la deberíamos repartir entre los creadores de CMSs y plug-ins WYSIWYG (bienintencionados, además, que es lo peor del caso; y no se libra ni el Tato, que mi WordPress 2.9.2 tiene unos maravillosos botones b e i que, contra todo pronóstico, acaban creando strongs y ems, respectivamente, por no hablar de Dreamweaver o el “añoradísimo” FrontPage) y diseñadores y desarrolladores que (de nuevo, bienintencionadamente) quieren facilitar al máximo la vida de sus clientes y darles toda la autonomía posible (y un puntito de culpa también para el cliente que compra sin tener ni puñetera idea y no hace el más mínimo esfuerzo por informarse, aunque (i) sólo un puntito y (ii) el esfuerzo que habría que hacer para informarse no es pequeño).

Tampoco se trata, por otro lado, de nada que no haya sufrido en sus carnes todo diseñador gráfico desde que todo el mundo puede bajarse un Photoshop o un InDesign piratas y sentirse perfectamente capacitado para cometer todo tipo de atrocidades visuales con total y absoluta naturalidad. Como ha pasado otras muchas veces antes, poner una tecnología potente (se llame esta Word, Excel, Quark o como se llame) al alcance de mucha gente es un gran avance, pero provoca pequeños (no tan pequeños, a veces, a ojos de los connoisseurs) daños colaterales. Podríamos alegar, además, que cuando hablamos de web y texto, el crimen no suele tan obvio y que, al fin y al cabo, solo somos cuatro los raros que acabaremos mirando el código fuente. Aunque eso sea olvidar que uno de esos cuatro raros es el motor de búsqueda de Google y que ese motor es, en la mayoría de casos, nuestro visitante más importante, el que, si conseguimos caerle bien, nos traerá de la mano un visitante (y potencial cliente) tras otro…

Tenemos, por tanto que el uso indiscriminado y no educado de editores WYSIWYG es un SEOsuicidio para los responsables del sitio web de turno y, de regalo, hace bien poco por dar buena imagen al diseñador de turno (los clientes informados, esos que uno querría tener, sí miran el código fuente).

O sea que consideren ustedes este mi granito de arena en pos de un poquito (sólo un poquito, de verdad) de cultura de la web que nos lleve a la extinción en algún momento del dichoso editor WYSIWYG.

La tarea no es en absoluto fácil:

  • En primer lugar, el diseñador web debería reconocer que su trabajo no se limita al diseño de un buen tema para el CMS, sino que también debería incluir, por defecto, un buen libro de estilo y manual de uso de la herramienta (y un esfuerzo de evangelismo y concienciación, en la mayoría de los casos).
  • Cuando, desafortunadamente, el cliente pase olímpicamente de dicha documentación (algo que acabará haciendo, más temprano que tarde), no estaría de más recordarle que, además de estar arruinando la imagen pública del diseñador, se está SEOsuicidando y tirando por la borda un trabajo bien hecho que le ha supuesto una inversión nada negligible.
  • Finalmente, la comunidad debe hacer un esfuerzo para educar tanto a los futuros creadores como a los futuros clientes para que puedan distinguir entre lo que es hacer las cosas bien y hacerlas mal (¡Hola, soy Coco! Esto es una página web bien hecha y esto… esto es un atentado contra la estética, el buen gusto, los estándares y la semántica). Por lo que respecta al primer punto, no puedo dejar de citar el currículo de estándares web Opera que tradujo la UOC al español y al catalán hace ya unos meses (ya lo habíamos comentado), pero la verdad es que no soy consciente de buenos recursos para el segundo, y comienza a haber una necesidad acuciante…

En fin. Confiemos en que con el tiempo (y el esfuerzo de todos) vaya mejorando la cosa y cada vez nos encontremos menos con atrocidades como las que abren esta entrada… en webs de salida bien hechas.

PS Esta tarde, si encuentro un rato, en los comentarios dejaré una nota sobre un aspecto discutible del código HTML de esta entrada ;-).

Se acerca IE9

Nota importante Por algún extraño motivo, a Google parece gustarle mucho esta vieja entrada sobre IE9. Si queréis una información mucho más actualizada, tenéis esta entrada: Ha llegado IE9 (beta).


Será por la manía de llevarle la contraria al mundo, pero, qué le vamos a hacer, me cae bien el equipo que hay detrás de Internet Explorer, aunque prefiero mantener a IE6, IE7 e IE8 a tanta distancia como me resulta posible, desde luego :-P. Pero un grupo de gente que se toma la molestia de enviar flores al funeral de IE6 tiene mi simpatía ganada casi desde el inicio.

Además, hoy Microsoft ha presentado la Platform Preview de Internet Explorer 9 y, si siguen trabajando en las líneas en que se han movido hasta ahora, podría ser que IE9 se convierta, finalmente, en un adversario digno para Firefox, Opera y Chrome (que, en ese orden, son ahora mis favoritos).

Algunas de las cosas que se han dicho hoy en la presentación y que me han interesado:

  • Siguen trabajando en que su motor de JavaScript sea comparable con los del “top three”. Siguen siendo conscientes de que no son tan rápidos como la competencia, pero ahora parece que están en el fondo de la primera división, y no en tercera regional… Siguen haciendo hincapié, también, en que no todo es rendimiento JavaScript al mostrar una página. Afirman que no han optimizado para SunSpider y que, aún así, su rendimiento en la suite de tests ya está a menos de una “generación” de distancia de los líderes.
  • Insisten una y otra vez en lo que todos los diseñadores y desarrolladores quieren oir: un solo marcado para todos los navegadores [modernos, añado]. Ahora mismo están en un 55/100 en el test Acid3 (un test interesante pero discutible, por otra parte, porque es muy “de laboratorio”) y parece ser que ya pasan “con honores” los tests de selectores CSS3. Y también se permiten el lujo de mostrar inconsistencias entre el rendering de Firefox y el de Chrome, lo que demuestra una cierta confianza en las posibilidades propias.
  • Comienzan a demostrar que la que debería ser su principal ventaja, el “monoplataforma”, da sus frutos, haciendo uso, por ejemplo, de la decodificación hardware de vídeo en “notebooks”. En general, parece que IE9 va a suponer otro empujón para el vídeo en HTML5 (subespecie H.264, todo parece indicar, puesto que son compatibles con YouTube). También han mostrado alguna de las demos del “test drive” en la que el rendimiento de HTML5 con Canvas y JavaScript de IE9 era algún que otro orden de magnitud mejor que el de Chrome (naturalmente, uno puede sospechar, y mucho, de los “tuneados” que se les hacen a estas demos, pero el código está a la vista de todos para su revisión).
  • Finalmente, parecen dispuestos a tender todos los puentes necesarios con la comunidad. En esa línea han publicado ya este primer ‘Platform Preview’ cuando está muy pero que muy lejos de tener estatus de beta (ahora mismo, por ejemplo, si se le pide que lance una ventana nueva… lo hace usando el navegador por defecto del sistema, sea cual sea, y el soporte de vídeo aún no es el que debería), y se han comprometido a actualizarla cada 8 semanas, aproximadamente.

No me jugaría un duro por el cumplimiento total de los estándares por parte de IE9. Y dudo más aún que pase de la cuarta plaza en la lista de mis navegadores favoritos. Pero, insisto: por un lado, el equipo que hay detrás de IE me cae bien y, además, sí estoy convencido que la lucha por la última posición se va a poner mucho más interesante que hasta ahora…

PS Para aquellos de vosotros para los que el inglés no sea un problema, en Channel 9 hay un vídeo muy interesante: Introducing the IE9 Developer Platform Preview. Y en MSDN hay ya una Internet Explorer Platform Preview Guide for Developers.

PPS Para los interesados, la última entrada del IEBlog es prácticamente una transcripción de la presentación de IE9.