Una breve historia de WaSP y por qué son importantes los estándares web

En agosto de 2013, Aaron Gustafson publicó en el blog de WaSP . Tenía un mensaje agridulce para una comunidad que había ayudado a liderar:

Gracias al arduo trabajo de innumerables miembros y partidarios de WaSP (como usted), la visión de Tim Berners-Lee de la web como una comunidad abierta, accesible y universal es en gran medida una realidad. Si bien aún queda trabajo por hacer, la picadura de la Avispa ya no es necesaria. Por eso es hora de que cerremos el Proyecto de Estándares Web.

Si hay el más mínimo indicio de melancólico arrepentimiento en el mensaje de Gustafson, es porque el Proyecto de Estándares Web cambió todo lo que se había convertido en la norma en la web durante sus más de 15 años de servicio. A través de la dedicación y la defensa de los desarrolladores, sacaron a la Web de un nido de incompatibilidad de navegadores y marcas sin sentido a la plataforma de aplicaciones estandarizada y rica en funciones que la mayoría de nosotros conocemos hoy.

Anteriormente cubrí lo que se necesitó para llevar CSS a la World Wide Web. Esta es la otra cara de esa historia. Fue sólo gracias a los esfuerzos de muchos voluntarios que trabajaron incansablemente entre bastidores que CSS tuvo la oportunidad de convertirse en lo que es hoy. Son la razón por la que tenemos estándares web.

Introducción de estándares web

Los estándares web ni siquiera existían en 1998. Había especificaciones HTML y CSS y borradores de recomendaciones administrados por el W3C, pero tenían un soporte de navegador irregular y desigual que los convertía en poco más que palabras en una página. En ese momento, los diseñadores web se encontraban al borde de lo que pronto se conocería como la Guerra de los Navegadores , donde Netscape y Microsoft competían para implementar características y complementos exclusivos en una lucha cada vez mayor por la participación de mercado. En lugar de ceñirse a cualquier especificación oficial, estos navegadores obligaron a los diseñadores a admitir Netscape Navigator o Internet Explorer. Y los diseñadores definitivamente no estaban contentos con esto.

Era posible ofrecer compatibilidad con ambos navegadores y sus respectivas implementaciones de funciones, pero también era difícil y poco fiable, como construir una casa sobre arena. Para ayudarse mutuamente, muchos desarrolladores comenzaron a unirse a listas de correo para intercambiar consejos y trucos sobre cómo lidiar con sitios que necesitaban verse bien sin importar dónde se renderizaran.

A partir de estas listas de correo, comenzó a formarse un grupo en torno a una idea completamente nueva. El problema, se dio cuenta este nuevo grupo, no estaba en el código, sino en los navegadores que se negaban a adherirse a las especificaciones abiertas y codificadas transmitidas por el W3C. Los navegadores promocionaban nuevos elementos HTML de presentación como la blinketiqueta, pero eran propietarios y no ofrecían opciones de diseño. Lo que la web necesitaba eran navegadores que pudieran seguir los estándares de la web.

El grupo decidió que necesitaban dar un paso adelante e impulsar a los navegadores en la dirección correcta. Se llamaron a sí mismos Proyecto de Estándares Web. Y, dado que el proceso requeriría un poco de esfuerzo, optaron por WaSP para abreviar.

Lanzamiento del proyecto de estándares web

En agosto de 1998, WaSP anunció su misión al público en un nuevo sitio web: “apoyar estos estándares básicos y alentar a los fabricantes de navegadores a hacer lo mismo, garantizando así un acceso simple y asequible a las tecnologías web para todos”. En pocas horas, 450 personas se unieron a WaSP. En unos pocos meses, ese número aumentaría a miles.

WaSP adoptó básicamente un enfoque doble. El primero fue público, aprovechando la oleada de apoyo de los desarrolladores que habían reunido para presionar a favor de un mejor soporte de estándares en los navegadores. Utilizando tácticas de base y una difusión dirigida, WaSP solía enviar a sus miembros a “misiones”, como enviar correos electrónicos a los navegadores para explicarles con gran detalle sus problemas al trabajar con una falta de soporte consistente de estándares web.

También publicaron informes mordaces que criticaban duramente a los navegadores, destacando todas las formas en que Netscape o Internet Explorer no añadieron el soporte necesario, e incluso llegaron al extremo de animar a los usuarios a utilizar navegadores alternativos. Fueron estos informes los que realmente hicieron honor a su acrónimo. Basta con ver una cita del brutal ataque de WaSP a Internet Explorer como ejemplo de su capacidad para picar:

Renuncia antes de terminar el trabajo y el lanzallamas será la única respuesta. Porque ese es nuestro trabajo. Hablamos en nombre de miles de desarrolladores web y, a través de ellos, de millones de usuarios web.

El segundo aspecto del enfoque de WaSP incluía comunicarse de forma privada con desarrolladores apasionados de los equipos de navegadores. El problema, para grandes empresas como Netscape y Microsoft, no era que los ingenieros estuvieran en contra de los estándares web. En realidad, todo lo contrario. Muchos ingenieros de navegadores creían profundamente en la misión de WaSP, pero una y otra vez se resistían a percibir intereses comerciales y burocracia burocrática. Como resultado, WaSP a menudo trabajaba con los desarrolladores de navegadores para encontrar el mejor camino a seguir y abogaba en su nombre ante los superiores cuando era necesario.

Manteniéndolo todo junto

Para ayudar a WaSP a avanzar a través de sus misiones, informes y alcance, se formó un Comité Directivo. Este comité ayudó a establecer los objetivos del proyecto y se acercó a la comunidad para obtener apoyo. Eran los heraldos de un día mejor que estaba por llegar, y más de unos pocos miembros influyentes pasarían por sus filas antes de que terminara el proyecto, entre ellos: Rachel Cox, Tim Bray, Steve Champeon, Glenn Davis, Glenda Sims, Todd Fahrner, Molly Holzschalg y Aaron Gustafson, entre muchos, muchos otros.

A la cabeza de todo estaba un líder de proyecto que marcó la pauta para el grupo y dio a los desarrolladores una voz unificada. El puesto lo ocupó inicialmente George Olsen, uno de los fundadores del proyecto, pero pronto fue asumido por otro miembro fundador: Jeffrey Zeldman.

Una red de grupos de satélites poco conectados que orbitan alrededor del Comité Directivo ayudó tanto a los desarrolladores como a los navegadores a comprender la importancia de los estándares web. Había, por ejemplo, un grupo de Accesibilidad que unió al W3C con los fabricantes de navegadores para garantizar que la web fuera abierta y accesible para todos. Luego estaba CSS Samurai, que publicó informes sobre la compatibilidad con CSS (o, más comúnmente, la falta de ella) en diferentes navegadores. Ellos fueron quienes idearon la prueba Box Acid y ofrecieron orientación a los navegadores mientras trabajaban para ampliar la compatibilidad con CSS. Todd Fahrner, quien ayudó a salvar CSS con el cambio de tipo de documento , se contaba entre los CSS Samurai.

Generar un impacto

WaSP era enorme y crecía todo el tiempo. Sus miembros eran apasionados y, poco a poco, grupos de la comunidad se unieron para implementar el cambio. Y eso es exactamente lo que pasó.

Los cambios parecieron algo pequeños al principio, pero pronto rozaron lo masivo. Cuando Netscape estaba dando vueltas a la idea de un nuevo motor de renderizado llamado Gecko que incluiría un soporte de estándares mucho mejor en todos los ámbitos, su cronograma inicial habría tardado meses en lanzarse. Pero la WaSP invadió, envió correos electrónicos y contactó a Netscape para presionarlos para que liberaran a Gecko antes. Funcionó y, en la siguiente versión, se envió Gecko (y mejores estándares web).

Tantek Çelik era otro miembro de WaSP. La comunidad lo inspiró a adoptar una postura respecto de los estándares web en su trabajo diario como desarrollador principal de Internet Explorer para Mac. Fue gracias al estímulo y apoyo de WaSP que él y su equipo lanzaron la versión 5 con soporte completo de CSS Nivel 1.

En agosto de 2001, después de años de informes públicos, divulgación privada y defensa de los desarrolladores, la picadura de WaSP provocó un cambio sísmico en Internet Explorer cuando se lanzó la versión 6 con soporte CSS Nivel 1 y las últimas funciones HTML. Las actualizaciones se debieron en gran parte al trabajo del Proyecto de Estándares Web y su trabajo con miembros dedicados del equipo del navegador. Parecía que los estándares estaban empezando a prevalecer. Es posible que la misión de la WaSP incluso haya terminado.

Pero en lugar de dejarlo todo, cambiaron un poco de táctica.

Estándares de enseñanza para una nueva generación

A principios de la década de 2000, WaSP cambiaría radicalmente su enfoque de educación y extensión a los desarrolladores.

Comenzaron con el lanzamiento de la Campaña de actualización del navegador, que educó a los usuarios que se conectaban por primera vez y no sabían absolutamente nada sobre los estándares web y los navegadores modernos. Se alentó a los propietarios de sitios a agregar algo de JavaScript y un banner a sus sitios para dirigirse a estos usuarios. Como resultado, quienes navegaban por un sitio con versiones anteriores de navegadores compatibles con los estándares, como Firefox u Opera, eran recibidos con un banner que simplemente les indicaba que actualizaran. Los usuarios que visitaban el sitio en un navegador realmente antiguo, como anterior a IE5 o Netscape 5, redirigirían a los visitantes a una página completamente nueva, explicando por qué actualizar a un navegador moderno con soporte de estándares era lo mejor para ellos.

WaSP iba ​​a acelerar la web, incluso si tuvieran que hacerlo una persona a la vez. Quizás nadie articuló mejor este sentimiento que Molly Holzschalg cuando escribió “Raise Your Standards” en febrero de 2002. En el artículo, desglosó qué son los estándares web y qué significan para los desarrolladores y diseñadores. Celebró el trabajo realizado por los navegadores y la comunidad trabajando para hacer que los estándares web existieran en primer lugar.

Pero, argumentó, la red estaba lejos de estar terminada. Había llegado el momento de que los desarrolladores dieran un paso al frente y asumieran la responsabilidad de los propios estándares codificándolos en todos sus sitios. Ella escribió:

El Consorcio está plagado de sus propios problemas internos y sus acciones, aunque casi siempre en beneficio de los autores web profesionales, en ocasiones están politizadas.

Por lo tanto, como autores web, somos personalmente responsables de tomar decisiones de implementación dentro del marco de las necesidades de marcado de un sitio. Nuestro trabajo es administrar recomendaciones lo mejor que podamos.

Sin embargo, esto no sería fácil. Una vez más, se necesitarían los esfuerzos combinados de los miembros de WaSP para unirse y enseñar a la web una nueva forma de codificar. Algunos comenzaron a publicar tutoriales en sus blogs personales o en A List Apart . Otros crearon un plan de estudios en línea basado en estándares para desarrolladores web nuevos en el campo. Algunos miembros incluso formaron nuevos grupos de trabajo para trabajar con herramientas de software populares, como Adobe Dreamweaver, y garantizar que los estándares también fueran compatibles allí.

Los rediseños de ESPN y Wired, que fueron un testimonio y ejemplo de diseños basados ​​en estándares en los años venideros, se llevaron a cabo en parte porque los miembros de esos equipos se inspiraron en el trabajo que estaba haciendo WaSP. No habrían podido dar esos primeros pasos cruciales si no fuera por los ejemplos y tutoriales que los amables miembros de WaSP pusieron a su disposición gratuitamente.

That is why web standards is basically second nature to many web developers today. It’s also why we have such a free spirit of creative exchange in our industry. It all started when WaSP decided to share the correct way of doing things right out in the open.

Looking Past Web Standards

It was this openness that carried WaSP into the late 2010’s. When Holzschlag took over as lead, she advocated for transparency and collaboration between browser makers and the web community. The WaSP, Holzschlag realized, was no longer necessary and could be done from within. For example, she made inroads at Microsoft to help make web standards a top priority on their browser team.

With each subsequent release, browsers began to catch up to the latest standards from the W3C. Browsers like Opera and Firefox actually competed on supporting the latest standards. Google Chrome used web standards as a selling point when it was initially released around the same time. The decade-and-a-half of work by WaSP was paying off. Browser makers were listening to the W3C and the web community, even going so far as to experiment with new standards before they were officially published for recommendation.

In 2013, WaSP posted its farewell announcement and closed up shop for good. It was a difficult decision for those who had fought long and hard for a better, more accessible and more open web, but it was necessary. There are still a number of battlegrounds for the open web but, thanks to the efforts of WaSP, the one for web standards has been won.

Enjoy learning about web history? Jay Hoffmann has a weekly newsletter called The History of the Web you can sign up for here.