Resumen

  • La carta propuesta indica que WebDriver y WebDriver BiDi avanzarían a Candidate Recommendation con Snapshots, se actualizarían continuamente en ese estado y no buscarían Recommendation.
  • La decisión aún no existe y ambas publicaciones actuales son Working Drafts. La Recommendation WebDriver de 2018 sigue siendo otro estado de la misma familia, no un estatus heredado por el texto nuevo.
  • Un Candidate Recommendation Snapshot pasa por revisión y revisión de patentes; un Candidate Recommendation Draft incorpora cambios posteriores que todavía no tienen el mismo examen formal.
  • Una prueba reproducible necesita la versión inmutable de la especificación, el tipo de madurez, el commit y selección de WPT, las versiones de navegador, controlador y cliente, plataforma, fecha y exclusiones conocidas.

Cuando lo provisional se convierte en el destino previsto

WebDriver es la capa que permite a un proceso externo ordenar a un navegador que navegue, localice elementos y ejecute acciones. WebDriver BiDi añade eventos en sentido inverso. Por eso una decisión documental se convierte rápidamente en código distribuido entre motores, controladores, bibliotecas y sistemas de integración continua.

El W3C abrió el 18 de agosto la revisión de una nueva carta para Browser Testing and Tools. Los comentarios públicos cierran el 18 de septiembre y la carta vigente fue prorrogada hasta el 23 de octubre. El sucesor sigue siendo una propuesta. No obstante, su forma de describir el futuro es inequívoca.

WebDriver y WebDriver BiDi son sus dos entregables normativos. El grupo pretende publicar su estado más reciente como Candidate Recommendation, con Snapshots, y mantenerlo actualizado. No pretende llevar los documentos a Recommendation. La Candidate Recommendation deja así de ser un corredor que todos esperan atravesar. Se convierte en el régimen de mantenimiento elegido.

El W3C reconoce esa posibilidad. Su guía sobre la etapa final explica que una CR viva puede ajustarse mejor a la experiencia que llega desde varias bases de código. Las instantáneas pueden aportar puntos examinados, mientras los Drafts muestran el texto integrado entre ellas.

Pero una referencia estable deja de venir incorporada en una edición final. Empresas, auditores y desarrolladores seguirán necesitando citar la tecnología. Decir solo «WebDriver» o «la CR actual» no permite saber qué obligación y qué comportamiento se verificaron.

Las fechas del propio expediente exponen el problema

La carta propuesta identifica como últimas publicaciones WebDriver del 1 de abril de 2026 y WebDriver BiDi del 19 de marzo. Al cierre de este análisis, las páginas vivas del W3C mostraban versiones posteriores: 2 de julio para WebDriver y 25 de agosto para WebDriver BiDi.

La diferencia no convierte la carta en defectuosa. Preparar y revisar un mandato toma tiempo; publicar un Working Draft activo puede tomar un día. Los enlaces conducen a historiales válidos. Lo importante es la categoría de objeto que la carta gobierna: una serie que cambia, no un archivo congelado.

También conviven distintas madureces con el mismo nombre. La primera versión de WebDriver conserva una Recommendation de junio de 2018. El nuevo informe WebDriver figura como Working Draft. Compartir nombre no permite que el borrador use el aval del documento anterior, ni hace que la Recommendation antigua describa toda función añadida después.

La URL de última versión simplifica la lectura. Para una auditoría histórica es una referencia móvil. Puede mostrar texto nuevo mientras el navegador y el controlador investigados siguen aplicando reglas anteriores.

Snapshot no significa lo mismo que Draft

El Proceso del W3C divide la Candidate Recommendation en dos formas. Un Snapshot requiere una solicitud de transición o actualización verificada y funciona como Patent Review Draft. La guía pública le atribuye consenso del grupo, revisión pública, examen formal de otros grupos y compromisos de licencia libre de regalías de los participantes.

El Candidate Recommendation Draft integra cambios posteriores para que puedan leerse y probarse. Sus requisitos se reducen deliberadamente para mantener actualizado el documento. Esos cambios aún no han recibido revisión formal y el Draft no ofrece por sí mismo la oportunidad de exclusión de patentes del Snapshot.

Ninguno es una norma del W3C. Además, publicar un Snapshot no exige por sí solo experiencia adecuada de implementación. La guía admite funciones todavía variables, con disponibilidad o interoperabilidad limitada, e incluso pruebas incompletas.

No es un juicio contra la CR. Es la información que la etiqueta preserva. El Snapshot demuestra cierto nivel de revisión y fija un punto de patentes. El Draft muestra la integración posterior. La Recommendation añadiría el respaldo institucional y otro umbral de experiencia. Cada uno sirve a una pregunta diferente.

El soporte es una unión, no una insignia

La carta ya exige señales valiosas. Los cambios en Candidate Recommendation y las funciones desplegadas deberían tener Web Platform Tests. Toda función nueva debería interesar a dos posibles implementadores. Seguridad, privacidad y accesibilidad deben documentarse, y las revisiones horizontales acompañar las transiciones principales.

Una señal aislada no basta. Interés no es código. Un test puede cubrir solo parte de una obligación. Un panel verde cambia cuando cambian el repositorio o los navegadores. Una función experimental puede estar detrás de una bandera. El controlador y la biblioteca cliente también pueden alterar la superficie que recibe el usuario.

Una afirmación importante debería conservar este conjunto:

instantánea inmutable + tipo de madurez + commit y selección de pruebas + versiones de navegador/controlador/cliente + plataforma + fecha + exclusiones

Si se usa un CR Draft, hay que nombrar el Snapshot anterior y los cambios sustantivos ejercitados. Si se usa un Snapshot, conviene enlazar la decisión de transición o actualización y el estado de revisión de patentes. Si una regla sigue latest, debe registrar cómo y cuándo resolvió esa dirección.

El conjunto no crea una autoridad paralela. El W3C decide la publicación; el grupo decide el texto; cada proyecto decide su binario; quien opera decide qué combinación aceptar. El registro permite comprobar la intersección.

No hace falta convertir la tesis en una exigencia de Recommendation

La prueba disponible no dice que el grupo deba buscar Recommendation. Una CR viva puede ser la mejor correspondencia con protocolos que se refinan mediante implementación. Forzar una edición final no garantiza que el código real se parezca más al texto.

El riesgo aparece cuando la flexibilidad pierde su fecha y su versión. Un resultado favorable en un Draft puede promocionarse como soporte de toda la serie. Una nueva redacción puede proyectarse hacia atrás sobre un contrato antiguo. La etiqueta común lava diferencias de revisión y comportamiento.

Congelar el resultado no congela el proyecto. Cada combinación nueva produce un registro nuevo y comparable. Así la evolución conserva velocidad sin borrar su procedencia.

Incertidumbre

La carta puede aprobarse, cambiar o no prosperar. La cláusula de CR continua puede modificarse. Ninguno de los dos informes ha llegado aún a esa etapa y no existe una fecha prometida para la primera transición.

Este artículo tampoco califica la interoperabilidad presente. El panel de WPT es una superficie de evidencia mutable, no una sentencia. La intensidad del registro depende del uso: una depuración diaria y una obligación contractual de largo plazo no tienen la misma necesidad.

La conclusión se limita a un principio operativo. Si Candidate Recommendation será el punto permanente, identificar la versión exacta deja de ser un detalle técnico. Es parte de la rendición de cuentas.

Fuentes

  1. Anuncio del W3C sobre la carta propuesta
  2. Carta propuesta de Browser Testing and Tools
  3. Carta vigente de Browser Testing and Tools
  4. Proceso del W3C
  5. Consideraciones sobre la etapa final
  6. Tipos de documentos del W3C
  7. Informe técnico actual de WebDriver
  8. Historial de publicación de WebDriver
  9. Informe técnico actual de WebDriver BiDi
  10. Historial de publicación de WebDriver BiDi
  11. Resultados WPT de WebDriver BiDi
  12. Árbol de pruebas WPT de WebDriver BiDi