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):

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:

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

• CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*
• Vendor Prefixes – about to go south
• WebKit Isn’t Breaking the Web. You Are
• Los ya mencionados Prefixr y -prefix-free, más el imprescindible CSS3, please!