Capítulo 7: Estándares

Corría el año 1994 cuando la web salió de la sombra de la academia y llegó a las pantallas de todos. En particular, fue la segunda mitad de la segunda semana de diciembre de 1994 la que culminó el año con tres días llenos de acontecimientos.

Los miembros del Consorcio World Wide Web se reunieron alrededor de una mesa en el MIT el miércoles 14 de diciembre . A la reunión asistieron unas dos docenas de personas, representantes de las principales empresas tecnológicas, fabricantes de navegadores y nuevas empresas basadas en la web. Estaban allí para discutir estándares abiertos para la web.

Cuando se hacen correctamente, los estándares establecen una guía técnica. Las empresas con intereses y prioridades contrapuestos pueden orientarse en torno a un conjunto común de documentación acordada sobre cómo debería funcionar una tecnología. El consenso sobre estándares compartidos crea interoperabilidad; la competencia se produce a través de la experiencia del usuario en lugar de la infraestructura técnica.

El Consorcio World Wide Web, o W3C, como se le conoce más comúnmente, había estado en la mente del creador de la web, Sir Tim Berners-Lee, ya en 1992. Había hablado con una lista rotativa de expertos y asesores sobre una Organismo oficial de normalización de tecnologías web. El Laboratorio de Ciencias de la Computación del MIT pronto se convirtió en su aliado más entusiasta. Después de años de trabajo, Berners-Lee dejó su trabajo en el CERN en octubre de 1994 para dirigir el consorcio en el MIT. No tenía ninguna intención de ser un dictador. Tenía opiniones firmes sobre la dirección de la web, pero aun así prefería escuchar.

En la agenda, después de que se despejó la mesa con algunas presentaciones básicas, había una larga lista de detalles administrativos que debían resolverse. El papel del consorcio, la forma en que se condujo y sus responsabilidades para con la red en general fueron poco más que esbozados al comienzo de la reunión. Poco a poco, los aproximadamente 25 miembros fueron recorriendo la lista. Al final de la reunión, el grupo confiaba en que el futuro de los estándares web estaba claro.

Al día siguiente, 15 de diciembre , Jim Clark y Marc Andreessen anunciaron la versión 1.0 de Netscape Navigator, recientemente renombrada. Había estado disponible durante varios meses en versión beta, pero ese jueves marcó un lanzamiento más amplio. En una apuesta por un mercado en crecimiento, inicialmente se regaló. Varios meses después, tras el lanzamiento de la versión 1.1, Netscape se vería obligado a retroceder. En cualquier caso, el navegador fue un éxito comercial y técnico, mejorando la velocidad, la usabilidad y las características de los navegadores anteriores.

El viernes 16 de diciembre , el W3C experimentó su primer revés. Berners-Lee nunca tuvo la intención de que el MIT fuera el sitio exclusivo del consorcio. Planeaba que el CERN, el lugar de nacimiento de la web y hogar de algunos de sus más grandes defensores, fuera el anfitrión europeo de la organización. Sin embargo, el 16 de diciembre , el CERN aprobó un presupuesto enorme para su Gran Colisionador de Hadrones, lo que los obligó a cambiar de prioridades. Un presupuesto reorientado dejó poco espacio para experimentos de hipertexto en Internet que no contribuyeran directamente al proyecto central de la física de partículas.

El CERN ya no sería el anfitrión europeo del W3C. No todo estaba perdido. Meses después, el W3C se instaló en el Instituto Nacional de Investigación en Ciencias de la Computación y Control (INRIA) de Francia. En 1996 también se establecería una tercera sede en la Universidad Keio de Japón.

Lejos de ser un caso atípico, este no sería el último revés que el W3C enfrentó, o que superaría.


En 1999, Berners-Lee publicó un relato autobiográfico de la creación de la web en un libro titulado Weaving the Web. Es una historia concisa y uniforme, un rápido recorrido por los principales hitos de la primera década de la web. A lo largo del libro, vuelve con frecuencia al tema del W3C.

Enmarca el consorcio web, ante todo, como una cuestión de compromiso. “Cada vez estaba más claro para mí que dirigir el consorcio siempre sería un acto de equilibrio, entre tomarse el tiempo para permanecer lo más abierto posible y avanzar a la velocidad que exige la avalancha de tecnología”. Lograr un equilibrio entre la compatibilidad compartida y los ciclos de lanzamiento de navegadores cada vez más cortos se convertiría en un objetivo principal del W3C.

Los estándares web, admite, prosperan a través de la tensión. Las normas se desarrollan en medio de desacuerdos y negociaciones logradas con mucho esfuerzo. Al recordar un momento justo antes de la creación del W3C, Berners-Lee señala cómo el proceso de estándares refleja la estructura de la web. "Se me ocurrió que estas tensiones harían del consorcio un campo de pruebas para los méritos relativos de las estructuras sociales en forma de red y de árbol", escribió, "estaba ansioso por comenzar el experimento". Sin embargo, un consorcio web nacido del compromiso y definido por la tensión no era el primer plan de Berners-Lee.

En marzo de 1992, Berners-Lee voló a San Diego para asistir a una reunión del Grupo de Trabajo de Ingeniería de Internet (IETF). Creado en 1986, el IETF desarrolla estándares para Internet, que van desde redes hasta enrutamiento y DNS. Los estándares del IETF son inaplicables y son totalmente voluntarios. No están sancionados por ningún gobierno mundial ni sujetos a ninguna regulación. Ninguna entidad está obligada a utilizarlos. En cambio, el IETF se basa en una simple presunción: la interoperabilidad ayuda a todos. Ha sido suficiente para sostener la organización durante décadas.

Como todo es voluntario, el IETF se rige por un conjunto laberíntico de reglas y procesos rituales que pueden resultar difíciles de entender. No existe una membresía formal, aunque cualquiera puede unirse (en sus propias palabras, “no tiene miembros ni cuotas”). Todos son voluntarios, nadie cobra. El grupo se reúne en persona tres veces al año en lugares cambiantes.

El IETF opera según un principio conocido como consenso aproximado (y, a menudo, código en ejecución). En lugar de un proceso de votación formal, las propuestas en disputa deben llegar a algún acuerdo en el que la mayoría, si no es que ninguno, de los miembros de un grupo de trabajo de tecnología estén de acuerdo. Los miembros del grupo de trabajo deciden cuándo se ha alcanzado un consenso aproximado y sus criterios cambian de año en año y de grupo en grupo. En algunos casos, el IETF ha recurrido al tarareo para medir la temperatura de una habitación. “Cuando, por ejemplo, tenemos reuniones cara a cara... en lugar de levantar la mano, a veces el presidente pide a cada parte que tararee una pregunta en particular, ya sea 'a favor' o 'en contra'”.

Es en el contexto de estas reglas idiosincrásicas que Berners-Lee llegó por primera vez al IETF en marzo de 1992. Esperaba crear un grupo de trabajo para cada una de las principales tecnologías de la web: HTTP, HTML y URI (que luego pasaría a llamarse URL a través del IETF). En marzo le dijeron que necesitaría otra reunión, esta vez en junio, para proponer formalmente los grupos de trabajo. Hacia finales de 1993, un año y medio después de su comienzo, había persuadido al IETF para que estableciera los tres.

El proceso de consenso aproximado puede ser lento. La web, por el contrario, había redefinido cómo podría ser la rapidez. Las nuevas generaciones de navegadores aparecieron en meses, no en años. Y esto fue antes de que Netscape y Microsoft se involucraran.

El desarrollo de la red se había disparado fuera de la esfera de influencia de Berners-Lee. Las imágenes en línea, una característica que tal vez sea la mayor responsable del éxito de la web, fueron producto de una sesión nocturna de intercambio de ideas con bocadillos y refrescos en el sótano de un laboratorio universitario. Berners-Lee se enteró de ello cuando todos los demás lo supieron, cuando Marc Andreessen lo publicó en la lista de correo de www-talk.

Tensión. Berners-Lee sabía que eso sucedería. Había esperado, por ejemplo, que las imágenes pudieran ser tratadas de manera diferente (“Tim me reprendió en el verano de 1993 por agregar imágenes a la cosa”, diría más tarde Andreessen), pero la web no era suya. No era de nadie. Él lo había diseñado de esa manera.

Con todas sus reglas y rituales, el IETF no parecía la opción adecuada para los estándares web. En debates privados en universidades y laboratorios de investigación, Berners-Lee había comenzado a explorar un nuevo camino. Algo así como un consorcio de partes interesadas en la web (un conjunto de empresas que crean navegadores, sitios web y software) que pueden unirse para llegar a un consenso aproximado para ellos mismos. A finales de 1993, su trabajo en el W3C ya había comenzado.


Dave Raggett, un experimentado investigador de Hewlett-Packard, tenía una visión diferente de la Web. No era académico y no estaba trabajando en un navegador (al menos todavía no). Entendió casi instintivamente la utilidad de la web como software comercial. Algo menos parecido a una guía telefónica digital y más parecido a la exitosa aplicación Hypercard de Apple.

Incapaz de convencer a sus jefes de la promesa de la Web, Raggett utilizó el diez por ciento del tiempo que HP concedía a sus empleados para realizar investigaciones independientes para comenzar a trabajar con la Web. Se ancló en la comunidad, fue un miembro activo de la lista de correo www-talk y una presencia regular en las reuniones del IETF. En el otoño de 1992, tuvo la oportunidad de visitar a Berners-Lee en el CERN.

Fue por esta época cuando conoció a Yuri Rubinsky, un entusiasta defensor del lenguaje de marcado general estándar, o SGML, el lenguaje en el que se basó originalmente HTML. Rubinsky creía que las limitaciones de HTML podrían resolverse mediante un cumplimiento más estricto del estándar SGML. Había iniciado una campaña para llevar SGML a la web. Raggett estuvo de acuerdo, pero hasta cierto punto. Todavía no estaba preparado para romper los vínculos con HTML.

Cada vez que Mosaic lanzaba una nueva versión o un nuevo navegador, se ampliaba la brecha entre la especificación HTML original y la web del mundo real. Raggett creía que se necesitaba un registro más completo de HTML. Comenzó a trabajar en una versión mejorada de HTML y en un navegador para demostrar sus capacidades. Su título provisional era HTML+.

El trabajo de Ragget pronto comenzó a extenderse a su vida hogareña. Pasaba la mayoría de las noches "frente a una computadora grande que ocupaba una buena parte de la mesa del comedor, compartiendo su superficie ligeramente pegajosa con papel, crayones, ladrillos Lego y trozos de galletas a medio comer que dejaban los niños". Después de un año de trabajo incansable, Raggett tenía una versión de HTML+ lista para funcionar en noviembre de 1993. Sus mejoras en el lenguaje estaban lejos de ser superficiales. Había logrado agregar todas las pequeñas cosas que habían llegado a los navegadores: tablas, imágenes con leyendas y figuras, y formularios avanzados.

Varios meses después, en mayo de 1994, desarrolladores y entusiastas de la Web viajaron de todo el mundo para asistir a lo que algunos asistentes denominarían medio en broma el “Woodstock de la Web”, la primera conferencia web oficial organizada por un empleado del CERN y el pionero de la web, Robert Calliau. De las 800 personas que clamaban por asistir, el espacio de Ginebra sólo podía albergar a 350. Muchos se reunían por primera vez. “Todo el mundo estaba dando vueltas en el vestíbulo”, describiría más tarde el historiador web Marc Weber, “electrizado por la misma sensación de encontrarse cara a cara con personas reales que no habían sido más que nombres en un correo electrónico o en el correo www-talk [sic] lista."

Llegó en un momento en que la red se encontraba al borde del precipicio de la ubicuidad. Nadie del equipo de Mosaic había logrado asistir (tenían su propia conferencia competitiva programada para solo unos meses después), pero ya había rumores sobre el nuevo navegador comercial del alumno de Mosaic, Marc Andresseen, que más tarde se llamaría Netscape Navigator. Mientras tanto, Mosaic había comenzado a otorgar licencias de su navegador para uso comercial. Una primera versión de Yahoo! estaba creciendo exponencialmente a medida que más y más publicaciones, como GNN, Wired, The New York Times y The Wall Street Journal, aparecían en línea.

Por otra parte, los avances en el IETF habían sido lentos. Fue demasiado meticuloso, demasiado preciso. Mientras tanto, navegadores como Mosaic habían comenzado a agregar lo que quisieran, particularmente a HTML. Las etiquetas compatibles con Mosaic no se podían encontrar en ningún otro lugar y los creadores de sitios web se vieron obligados a elegir entre tecnología de punta y compatibilidad con otros navegadores. Muchos eligieron lo primero.

HTML+ fue el principal tema de conversación en la conferencia. Pero otro momento destacado fue cuando Dan Connolly, un joven “texano pelirrojo y de corte azul marino” que trabajaba en el fabricante de supercomputadoras Convex, subió al escenario. Dio una charla titulada “Interoperabilidad: por qué todos ganan”. Más tarde, y en gran parte gracias a esa charla, Connolly sería nombrado presidente del Grupo de Trabajo HTML del IETF.

En un momento profético que capturó el espíritu de la sala, Connolly describió un futuro en el que el lenguaje HTML se fracturaría. Cuando cada navegador implementó su propio conjunto de etiquetas HTML en un esfuerzo por superar a la competencia. La solución, concluyó, era un estándar HTML que fuera capaz de evolucionar al ritmo del desarrollo de los navegadores.

HTML+ de Ragget fue un argumento sólido para convertirse en ese estándar. Era exhaustivo y describía el nuevo HTML utilizado en navegadores como Mosaic con un detalle casi perfecto. "Siempre fui minimalista, ya sabes, puedes hacerlo sin eso", dijo Connolly más tarde, "Raggett, por otro lado, quería expandirlo todo". Los dos llegaron a un acuerdo. Raggett continuaría trabajando con HTML+ mientras Connolly se concentraba en una actualización más limitada.

La versión de Connolly pronto se convertiría en HTML 2, y después de un año de idas y venidas y de un consenso aproximado en el IETF, se convirtió en un estándar oficial. No tenía los detalles de HTML+, pero Connolly pudo documentar oficialmente las características que los navegadores habían estado admitiendo durante años.

La propuesta de Ragget, rebautizada como HTML 3, quedó estancada. En un esfuerzo por dar cabida a una red en expansión, siguió creciendo en tamaño. “Lograr un consenso sobre un borrador de 150 páginas y sobre el cual todos querían expresar una opinión fue, cuando menos, optimista”, diría más tarde Raggett, de manera bastante directa. Pero para entonces, Raggett ya estaba trabajando en el W3C, donde HTML 3 pronto se haría realidad.


Berners-Lee también habló en la primera conferencia web en Ginebra y la cerró con un discurso de apertura. No mencionó específicamente al W3C. En cambio, se centró en el papel de la web. "Las personas presentes eran las que ahora creaban la Web", escribiría más tarde sobre su discurso, "y por lo tanto eran las únicas que podían estar seguras de que lo que producían los sistemas sería apropiado para una sociedad razonable y justa".

En octubre de 1994, se embarcó en su propia labor para crear un futuro más equitativo y accesible para la web. Se anunció oficialmente el Consorcio World Wide Web. A Berners-Lee se unieron un puñado de empleados, una lista que incluía tanto a Dave Raggett como a Dan Connolly. Dos meses después, en la segunda mitad de la segunda semana de diciembre de 1994, los miembros del W3C se reunieron por primera vez.

Antes de la reunión, Berners-Lee tenía un esbozo de cómo funcionaría el W3C. Cualquier empresa u organización podría unirse siempre que pague la cuota de membresía, una estructura de precios escalonada vinculada al tamaño de esa empresa. Las organizaciones miembros enviarían representantes a las reuniones del W3C para brindar información sobre el proceso de creación de estándares. Al limitar los procedimientos del W3C a los miembros que pagan, Berners-Lee esperaba centrar y ampliar las conversaciones a implementaciones de tecnologías web en el mundo real.

Sin embargo, a pesar de tener una membresía cerrada, el W3C opera abiertamente siempre que es posible. Las notas y la documentación de las reuniones están abiertas a cualquier persona del público. Cualquier código escrito como parte de experimentos con nuevos estándares se puede descargar gratuitamente.

Reunidos en el MIT, los miembros del W3C tuvieron que decidir a continuación cómo funcionarían sus estándares. Se decidieron por un proceso que no llega a un consenso aproximado. Aunque a menudo se les llama estándares, el W3C no crea estándares oficiales para la web. Las especificaciones técnicas creadas en el W3C se conocen, en su forma final, como recomendaciones.

Son, en efecto, propuestas. Describen con gran detalle cómo funciona exactamente una tecnología. Pero dejan lo suficientemente abierto como para que sean los navegadores quienes descubran exactamente cómo funciona la implementación. "El objetivo del W3C es garantizar la interpretabilidad de la Web, y a largo plazo eso es realista", lo describió una vez la ex jefa de comunicaciones del W3C, Sally Khudairi, "pero a corto plazo no vamos a jugar con la Web". policías para el cumplimiento... no podemos obligar a los miembros a implementar cosas”.

Los borradores iniciales crean un circuito de retroalimentación entre el W3C y sus miembros. Proporcionan orientación sobre tecnologías web, pero incluso cuando las especificaciones están en proceso de redacción, los navegadores comienzan a introducirlas y se anima a los desarrolladores a experimentar con ellas. Cada vez que se encuentran problemas, se revisa el borrador hasta que se haya alcanzado suficiente consenso. En ese momento, un borrador se convierte en una recomendación.

Siempre habría tensión y Berners-Lee lo sabía bien. El truco no consistía en intentar resistirlo, sino en crear un proceso en el que se convirtiera en un activo. Ése era el efecto buscado de las recomendaciones.

A finales de 1995, el grupo de trabajo HTML del IETF fue reemplazado por una Junta de Revisión Editorial HTML del W3C recién creada. HTML 3.2 sería la primera versión HTML lanzada íntegramente por el W3C, basada en gran medida en HTML+ de Ragget.


Hubo un año en el desarrollo web, 1997, en el que los navegadores rompieron con las aún nuevas recomendaciones del W3C. Microsoft y Netscape comenzaron a lanzar un nuevo conjunto de características separadas de los estándares acordados. Incluso tenían un nombre para ellos. Los llamaron HTML dinámico o DHTML. Y casi parten la red en dos.

DHTML fue originalmente celebrado. Dinámico significaba fluido. Una evolución natural desde el estado inerte inicial del HTML. En otras palabras, la red cobró vida.

Al promocionar sus capacidades, un artículo en Wired en 1997 se refirió a DHTML como la "varita mágica que los magos de la Web han buscado durante mucho tiempo". En su entusiasmo por la nueva tecnología, hace una pequeña nota de que "Microsoft y Netscape, hay que reconocerles, han trabajado con los organismos de normalización", específicamente en la introducción de hojas de estilo en cascada, o CSS, pero que la mayoría de las funciones se estaban agregando. "Sin mucha consideración por la compatibilidad".

La verdad sobre el terreno era que utilizar DHTML requería apuntar a un navegador u otro, Netscape o Internet Explorer. Algunos desarrolladores optaron por simplemente elegir una ruta, colocando un banner en la parte inferior de su sitio que mostraba "Mejor visto en..." en un navegador u otro. Otros ignoraron la tecnología por completo, con la esperanza de evitar su enmarañada complejidad.

Los navegadores tenían sus razones, por supuesto. Los desarrolladores y usuarios pedían cosas que no estaban incluidas en la especificación HTML oficial. Como lo expresó un representante de Microsoft: "Para introducir nuevas tecnologías en los organismos de normalización, hay que seguir innovando... Soy responsable ante mis clientes y también lo es la gente de Netscape".

Una red más dinámica no era mala, pero una red fragmentada era insostenible. Para algunos desarrolladores, sería la gota que colmó el vaso.


Tras el lanzamiento de HTML 3.2 y con el rápido avance de los navegadores, el Comité de Revisión Editorial de HTML se dividió en tres partes. A cada uno se le asignó un área de responsabilidad separada en la que avanzar, independientemente de los demás.

La Dra. Lauren Wood asumió la presidencia del Grupo de Trabajo sobre el Modelo de Objetos de Documento. Wood, ex físico nuclear teórico, fue director de tecnología de productos en SoftQuad, una empresa fundada por el defensor de SGML, Yuri Rubinsky. Mientras estuvo allí, ayudó a trabajar en el editor HTML HoTMetaL. La especificación DOM creó una forma estandarizada para que los navegadores implementen HTML dinámico. "Necesita una forma de unir sus datos y sus programas", así lo describió Wood, "y el modelo de objetos de documento es ese pegamento". Su trabajo en el modelo de objetos de documento, y más tarde en XML, tendría una influencia duradera en la web.

El grupo de trabajo sobre hojas de estilo en cascada estuvo presidido por Chris Lilley. La experiencia de Lilley fue en gráficos por computadora, como profesora y especialista en la Unidad de Gráficos por Computadora de la Universidad de Manchester. Lilley había trabajado en el IETF en la especificación HTML 2, así como en una especificación para gráficos de red portátiles (PNG), pero esta sería su primera vez como presidente de un grupo de trabajo.

CSS todavía era relativamente nuevo en 1997. Había estado en proceso durante años, pero aún no había tenido un lanzamiento importante. Lilley trabajaría junto con los creadores de CSS (Håkon Lie y Bert Bos) para crear el primer estándar CSS.

El grupo de trabajo final fue para HTML, que quedó bajo los auspicios de Dan Connolly, continuando su puesto en el IETF. Connolly había estado en la red casi tanto tiempo como Berners-Lee. Él fue una de las personas que observaron en octubre de 1991, cuando Berners-Lee hizo una demostración de la web para un pequeño grupo de personas poco impresionadas en una conferencia de hipertexto en San Antonio. De hecho, fue en esa conferencia donde conoció a la mujer que más tarde se convertiría en su esposa.

Después de regresar a casa, experimentó con la web. Le envió un mensaje a Berners-Lee un mes después. Eran sólo tres palabras: "Necesitas un DTD".

Cuando Berners-Lee desarrolló el lenguaje HTML, tomó prestada su convención de su predecesor, SGML. IBM desarrolló el Lenguaje de marcado generalizado (GML) a principios de la década de 1970 para facilitar a los mecanógrafos la creación de libros e informes formateados. Sin embargo, rápidamente se salió de control, ya que la gente tomaba atajos y usaba cualquier versión de las etiquetas que quisiera.

Fue entonces cuando desarrollaron la Definición de tipo de documento, o como la llamó Connolly, una DTD. Las DTD son las que agregaron la “S” (estandarizada) a GML. Con SGML, puede crear un conjunto estandarizado de instrucciones para sus datos, su esquema y su estructura, para ayudar a las computadoras a comprender cómo interpretarlos. Estas instrucciones son una definición de tipo de documento.

A partir de la versión 2, Connolly agregó una definición de tipo a HTML. Limitó el lenguaje a un conjunto más pequeño de etiquetas acordadas. En la práctica, los navegadores trataron esto más como una definición vaga y continuaron implementando sus propias características y etiquetas DHTML. Pero fue un primer paso.

En 1997, el Grupo de Trabajo HTML, ahora dentro del W3C, comenzó a trabajar en la cuarta iteración de HTML. Amplió el lenguaje, agregando a la especificación características mucho más avanzadas, tablas y formularios complejos, mejor accesibilidad y una relación más definida con CSS. Pero también dividió HTML de un único esquema en tres definiciones de tipos de documentos diferentes para que los navegadores las adopten.

El primero, Frameset, no se utilizaba habitualmente. El segundo, el de Transición, estaba ahí para incluir los errores del pasado. Expandió un subconjunto más grande de HTML que incluía HTML de presentación no estándar que los navegadores habían utilizado durante años, como fonty center. Esto se configuró como predeterminado para los navegadores.

El tercer DTD se llamó Strict. Según la definición estricta, HTML se redujo únicamente a sus características estándar, no presentativas. Eliminó todas las etiquetas únicas introducidas por Netscape y Microsoft, dejando solo elementos estructurados. Si usa HTML hoy en día, probablemente se base en la misma base de etiquetas.

La definición estricta trazó una línea en la arena. Decía, esto es HTML. Y finalmente permitió a los desarrolladores codificar una vez para cada navegador.


En el número de agosto de 1998 de Computerworld (entre grandes artículos sobre la inminente catástrofe del año 2000 , el potencial de facturación en la World Wide Web y preocupaciones antimonopolio sobre Microsoft) había un pequeño anuncio. Su titular decía: "Estándares de navegador apuntados". Se trataba de la creación de una nueva organización de base de desarrolladores web destinada a llevar soporte de estándares web a los navegadores. Se llamó Proyecto de Estándares Web.

Glenn Davis, cocreador del proyecto, fue citado en el anuncio. "El problema es que, con cada generación de navegadores, los fabricantes de navegadores se alejan cada vez más del soporte de estándares". Los desarrolladores, obligados a escribir código diferente para diferentes navegadores durante años, simplemente ya habían tenido suficiente. Unas cuantas conversaciones informales en listas de correo se habían convertido en un movimiento plenamente desarrollado. En el momento del lanzamiento, ya se habían inscrito 450 desarrolladores y diseñadores.

Davis no era nuevo en la web y entendía sus desafíos. Su primera experiencia en la web se remonta a 1994, justo después de que Mosaic introdujera por primera vez las imágenes en línea, cuando creó el sitio de galería Cool Site of the Day. Cada día, presentaba una única página de inicio de un sitio interesante, vanguardista o experimental. Para una comunidad aún pequeña de diseñadores web, fue un éxito instantáneo.

No había más criterios que los sitios que Davis pensaba que valía la pena presentar. “Siempre estuve buscando cosas que superaran los límites”, así lo definiría más tarde. Davis ayudó a redefinir las expectativas de la primera web, utilizando el apodo cool como abreviatura para abarcar muchas posibilidades. La autora de Dot-com Design y profesora de medios **Megan Ankerson señala lo que “este ecosistema de sitios geniales indicaba la gran variedad de cosas que podría ser la web: sus dislocaciones temporales y espaciales, su distinción y extensión de los principales medios de comunicación, su promesa como vehículo para la autoedición y la increíble combinación de lo personal, lo mundano y lo extraordinario”. Durante un tiempo en la web, Davis fue el árbitro de lo cool.

Con el paso del tiempo, Davis transformó su sitio en Project Cool, un recurso para crear sitios web. En los días de DHTML, los tutoriales de Project Cool de Davis proporcionaban técnicas constructivas y prácticas para aprovechar al máximo la web. Y una buena parte de sus escritos se dedicó a explicar cómo escribir código que fuera utilizable tanto en Netscape Navigator como en Internet Explorer de Microsoft. Finalmente llegó a un punto de quiebre, junto con muchos otros. A finales de 1997, Netscape y Microsoft lanzaron sus navegadores 4.0 con soporte de estándares irregular. Ya estaba claro que las próximas versiones 5.0 planeaban inclinarse aún más hacia extensiones DHTML desiguales y contradictorias.

Al quedarse sin paciencia, Davis ayudó a crear una lista de correo con George Olsen y Jeffrey Zeldman. La lista comenzó con dos docenas de personas, pero rápidamente obtuvo apoyo. El Proyecto de Estándares Web, conocido como WaSP, se lanzó oficialmente a partir de esa lista en agosto de 1998. Comenzó con unos cientos de miembros y anuncios en revistas como Computer World. En unos pocos meses tendría decenas de miles de miembros.

La estrategia de WaSP fue impulsar a los navegadores (públicos y privados) a soportar estándares web. WaSP no pretendía ser un nombre hiperbólico”. El W3C recomienda estándares. No puede hacerlas cumplir”, dijo una vez Zeldman sobre la estrategia de la organización, “y ciertamente no está dispuesta a hacer berrinches públicos por el incumplimiento. Entonces hacemos ese trabajo”.

Zeldman, destacado diseñador y defensor de los estándares, tendría una influencia duradera en los creadores de la web. Más tarde dirigiría WaSP durante algunos de sus años más influyentes. Su sitio web y su lista de correo, A List Apart, se convertirían en un lugar de reunión para diseñadores preocupados por los estándares web y el uso de las últimas tecnologías web.

WaSP cambiaría de enfoque varias veces durante su década y media en el cargo. Impulsaron a los navegadores a hacer un mejor uso de HTML y CSS. Enseñaron a los desarrolladores cómo escribir código basado en estándares. Abogaron por una mayor accesibilidad y herramientas que respaldaran los estándares listos para usar.

Pero su misión, publicada en su sitio web el primer día del lanzamiento, nunca fallaría. "Nuestro objetivo es respaldar 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".

WaSP tuvo éxito en su misión en algunas ocasiones desde el principio. Algunos navegadores, en particular Opera, tenían estándares integrados desde el principio; Sus esfuerzos fueron elogiados por WaSP. Pero los dos navegadores que en conjunto constituyen la mayor parte del uso de la web (Internet Explorer y Netscape Navigator) necesitarían algo de trabajo.

Una venta de cuatro mil millones de dólares a AOL en 1998 no fue suficiente para que Netscape pudiera competir con Microsoft. Después del lanzamiento de Netscape 4.0, redoblaron su apuesta por una estrategia audaz y eligieron publicar todo el código del navegador como fuente abierta bajo el proyecto Mozilla. Los consumidores cotidianos podían descargarlo de forma gratuita; Se animó a los codificadores a contribuir directamente.

Los miembros de la comunidad pronto notaron algo en Mozilla. Tenía un nuevo motor de renderizado, a menudo denominado Gecko. A diferencia de los lanzamientos planificados de Netscape 5, que en el mejor de los casos tenían un soporte de estándares irregular, Gecko admitía una versión bastante completa de HTML 4 y CSS.

WaSP desvió su formidable membresía a la tarea de presionar a Netscape para que incluyera Gecko en su próximo lanzamiento importante. Una táctica familiar de WaSP se conocía como bloqueo de carreteras. Algunos de sus miembros trabajaron en publicaciones como HotWired y CNet. WaSP coordinaría artículos en varios medios a la vez criticando, por ejemplo, el abandono de los estándares por parte de Netscape frente a una solución perfectamente razonable en Gecko. Al hacerlo, a menudo pudieron captar la atención de al menos un ciclo de noticias.

WaSP también tomó medidas más directas. Se pidió a los miembros que enviaran correos electrónicos a los navegadores o firmaran peticiones que mostraran un apoyo generalizado a los estándares. En ocasiones, la presión abrumadora de los desarrolladores fue suficiente para empujar a los navegadores en la dirección correcta.

En parte debido a WaSP, Netscape acordó hacer que Gecko forme parte de la versión 5.0. Las versiones beta de Netscape 5 ciertamente tendrían HTML y CSS compatibles con los estándares, pero estaban plagados de problemas en otros lugares. Se necesitarían años para su liberación. Para entonces, el dominio de Microsoft sobre el mercado de los navegadores estaría

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir