Resumen

  • La nueva carta del Web Performance Working Group fue aprobada el 10 de agosto de 2026 y estará vigente hasta el 1 de agosto de 2028.
  • El texto final pide expresiones de interés de al menos dos implementadores antes de incorporar una función nueva a especificaciones mantenidas como Candidate Recommendations.
  • Sin esas dos expresiones, la función aún puede entrar en un borrador de Candidate Recommendation si queda anotada como “at risk”.
  • Para avanzar más allá de Candidate Recommendation se esperan dos implementaciones independientes e interoperables por función y pruebas abiertas; el Proceso general conserva una excepción pública y motivada.
  • Hace falta una constancia por función que no mezcle interés, adopción institucional, estado en riesgo, implementación, prueba y transición.

El respaldo que dejó de llamarse respaldo

La carta organiza un grupo encargado de medir y mejorar aspectos del rendimiento de aplicaciones: carga, renderizado, capacidad de respuesta, memoria y otras experiencias que dependen del comportamiento del navegador. El anuncio del 10 de agosto aprobó el nuevo mandato y abrió la participación hasta el 1 de agosto de 2028.

El cambio más revelador está en una frase de los criterios de éxito. La propuesta de junio hablaba del apoyo de al menos dos implementadores. La versión aprobada dice que toda función nueva debería tener “expresiones de interés” de por lo menos dos implementadores antes de incorporarse a especificaciones que se mantienen en Candidate Recommendation.

La diferencia no es cosmética. Una empresa puede estar interesada en revisar un diseño, construir un experimento o mantener abierta una opción sin decidir su calendario de producto. También puede apoyar el problema y rechazar una solución concreta. Registrar esa postura como interés permite que sea útil sin convertirla en una promesa de lanzamiento.

Más adelante aparece otra prueba. La carta espera dos implementaciones independientes e interoperables de cada función para superar Candidate Recommendation, verificadas mediante suites abiertas, y exige una suite abierta para cada función. Aquí ya no basta con que dos actores consideren valioso el trabajo. Se observa si sistemas independientes producen conductas compatibles frente a un conjunto identificable de pruebas.

Interés e interoperabilidad no son dos porcentajes de una misma aprobación. Uno orienta la inversión y la atención; el otro prueba un resultado técnico.

Incubar, adoptar, incluir y demostrar

La propia carta describe cuatro estados que una tabla de “soporte” suele comprimir.

Durante la incubación, una propuesta puede evolucionar en el Web Platform Incubator Community Group. Allí puede reunir casos de uso y código sin haber sido adoptada por el Web Performance Working Group.

La adopción por el grupo es una decisión distinta. El apartado de coordinación indica que una propuesta del WICG implementada y disponible en al menos un navegador importante, con apoyo adicional, puede ser adoptada por WebPerf. La adopción cambia quién puede conducirla en la vía formal. No demuestra automáticamente una segunda implementación independiente.

La inclusión en un borrador de Candidate Recommendation es el tercer estado. Una función sin dos expresiones de interés puede entrar si lleva una anotación de riesgo. El documento que la contiene puede tener una madurez determinada mientras la permanencia de esa función sigue condicionada.

El cuarto estado corresponde a la experiencia de implementación y la transición. El Proceso del W3C usa Candidate Recommendation para reunir evidencia. Además distingue Candidate Recommendation Draft, que presenta cambios para revisión, de Candidate Recommendation Snapshot, con otra función de transición y revisión de patentes. Decir solamente “está en CR” oculta qué instrumento, qué revisión y qué función se están describiendo.

Una casilla verde puede significar comentario favorable, prototipo, código protegido por una preferencia, adopción del grupo, cobertura parcial de pruebas o interoperabilidad completa. Mientras no se nombre la evidencia, el color no informa.

La respuesta de Mozilla no necesita ser ampliada

Mozilla publicó su respuesta a la consulta. Apoyó la propuesta aunque sus cambios no fueran aceptados y respaldó la revisión del lenguaje relativo al apoyo de dos implementadores. También marcó su intención de revisar borradores, desarrollar implementaciones experimentales, enviar informes de experiencia y crear productos basados en el trabajo.

El campo destinado al calendario quedó sin una fecha pública.

La lectura responsable es directa: existe una intención general de participar, pero no una lista de compromisos por función. El documento no nombra dos implementadores para una API concreta, una versión de navegador o un día de disponibilidad. Usarlo como prueba de despliegue añadiría datos que Mozilla no publicó.

Tampoco la membresía del grupo puede rellenar el vacío. Participar da voz, trabajo y conocimiento. No convierte a cada organización en partidaria de cada rasgo normativo ni permite deducir su hoja de ruta.

Una función en riesgo sigue abierta

“At risk” puede sonar a pronóstico negativo. En el Proceso tiene una finalidad más estrecha: advertir que una función puede ser retirada en una transición posterior bajo reglas previstas. La etiqueta conserva libertad de prueba sin hacer pasar la incertidumbre por consenso consolidado.

Por eso debe quedar ligada a una función y a una revisión inmutables. Si desaparece, el historial debería indicar si llegó nuevo interés, se completó una implementación, se redujo el alcance, se borró la función o simplemente cambió la estructura editorial.

La versión también importa para los tests. Dos productos pueden aprobar conjuntos distintos, utilizar revisiones diferentes de Web Platform Tests o compartir una base de código. La independencia requiere explicar linaje y decisiones técnicas; contar logotipos no basta. El resultado debe mencionar producto, motor, versión, estado de activación, revisión de pruebas, cobertura y fallos pendientes.

La excepción forma parte del estado

La carta usa el lenguaje de expectativa para las dos implementaciones. El Proceso del W3C permite al Team aprobar una transición con experiencia mínima cuando exista una razón de peso, siempre que haga pública la decisión y su justificación.

Una excepción transparente no destruye la regla. Añade un acto que debe ser rastreable: autoridad, versión del Proceso, alcance, evidencia y motivo. Puede incluso ser más honesta que fabricar una segunda implementación nominal sin independencia real.

La idea de Heng Lu de que la publicación no sustituye adopción, validación y uso ayuda a evitar que una etiqueta institucional reemplace la realidad. También necesita un límite: el código desplegado no se autoproclama Recommendation del W3C. La evidencia operativa y la decisión institucional deben conservarse juntas, sin que una usurpe el nombre de la otra.

Una constancia de estado por función

El W3C ya ofrece cartas, especificaciones, repositorios, issues, pruebas y páginas de publicaciones. La unión mínima debería contener:

  • identificador de la función y revisión exacta de la especificación;
  • carta y versión del Proceso aplicables;
  • cada expresión pública de interés, con actor, fecha, alcance y fuente;
  • carácter experimental, planificado, implementado, retirado o sin calendario de la declaración;
  • decisión del Working Group y revisión adoptada;
  • enlace e historial de la anotación de riesgo;
  • producto, motor y versión de cada implementación, más la razón de independencia;
  • revisión de la suite abierta, cobertura y resultados fechados;
  • transición, objeciones y cualquier excepción pública;
  • próxima revisión, corrección y sustitución.

No es una demanda de hojas de ruta confidenciales. Una declaración puede seguir diciendo “interés sin calendario”. Lo importante es que no se transforme en una promesa cuando pasa de una página a otra.

La carta aprobada ya reconoce que el interés abre una puerta y las pruebas responden otra pregunta. La gobernanza debe conservar esa precisión cuando la función llegue a contratos, políticas de compra o declaraciones de compatibilidad.

Fuentes

  1. W3C — aprobación de la carta y convocatoria de participación
  2. W3C — carta aprobada del Web Performance Working Group
  3. W3C — diferencias entre la propuesta y el texto aprobado
  4. W3C — anuncio público de la revisión de la propuesta
  5. Archivo público del W3C — respuesta de Mozilla
  6. W3C — Process Document
  7. W3C — publicaciones del Web Performance Working Group
  8. W3C — página del Web Performance Working Group
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption