Superficies de la plataforma web: mapa de revisión

La consistencia de la plataforma web es un orden de revisión, no una prueba única. Este hub conecta el grupo de plataforma y añade un registro acotado que nombra la primera superficie que difiere del dato declarado, empezando por Diseñar matrices de prueba por plataforma y versión.

BotBrowser soporta repetir un perfil autorizado en una página propia y puede informar observaciones acotadas del navegador para cada superficie; no puede certificar conformidad con estándares, no clasifica dos productos ni predice la decisión de un servicio de terceros, y no sustituye la revisión del responsable de plataforma.

Resumen

• Agrupa el comportamiento en cuatro superficies: renderizado y maquetación, ejecución de scripts, negociación de red y acceso a capacidades.
• Registra el dato declarado junto al valor observado para la misma versión y la misma página propia.
• Nombra la primera superficie que difiere, detente y entrégala a su responsable.
• La reducción, el repliegue y la falta de disponibilidad son estados legítimos, no fallos.

Contenido

• Las cuatro superficies
• Recorrer el grupo de plataforma
• Ejecutar una revisión acotada
• Clasificar la primera diferencia
• Conclusión práctica

Las cuatro superficies

Renderizado y maquetación cubre lo que la página pinta: fuentes, color, consultas de medios y la respuesta del documento al viewport. Una página no es una sola superficie. Es una pila de superficies como document, iframe y Worker que el navegador implementa por separado, cada una con su especificación, su ritmo de versión y sus modos de fallo. Cuando un equipo pregunta si un navegador soporta su aplicación, en realidad hace cuatro preguntas a la vez, y las respuestas pueden no coincidir. Separarlas es la diferencia entre una revisión que termina en un responsable nombrado y un hilo que termina en una conjetura. La ejecución de scripts cubre lo que corre: carga de módulos, workers, identidad entre realms y contextos de larga vida. La negociación de red cubre lo que viaja: cabeceras de petición, política de respuesta, requisitos de contexto seguro y límites de origen cruzado. El acceso a capacidades cubre lo que la página puede usar: política de permisos, sensores, almacenamiento y funciones experimentales detrás de origin trials.

En un equipo habitual cada superficie tiene su responsable, y un cambio en una se atribuye con facilidad a otra. Una aplicación puede renderizar bien, ejecutar sus scripts, negociar las peticiones y aun así no poder usar la cámara, el micrófono o el portapapeles, porque una política de permisos, un requisito de contexto seguro o una elección previa del usuario cambiaron lo que la página puede pedir. Lo contrario también ocurre: la capacidad está disponible y la maquetación que la aloja está rota. Revisar las cuatro superficies por separado evita que un estado esconda al otro. Una fuente que se renderiza distinto tras una actualización puede ser un cambio de plataforma, del perfil o de la hoja de estilos. Un worker que no arranca puede ser una política de capacidades, un error de script o un archivo que falta en el paquete. Escribir el nombre de la superficie en el registro es lo que mantiene corto el diagnóstico.

El papel de BotBrowser aquí es limitado: mantiene el perfil declarado coherente entre contextos para que una diferencia del registro se pueda atribuir a la superficie revisada y no a una variable sin control. Para comparar motores y productos, usa antes Motor del navegador frente a producto y asigna la causa después.

Recorrer el grupo de plataforma

• Diseñar matrices de prueba por plataforma y versión decide qué combinaciones se ejecutan de verdad.
• Datos de compatibilidad de API y repliegues cubre detección y repliegue progresivo.
• Integridad de API entre realms separa los objetos globales de página, iframe y worker.
• Soporte de funciones no es calidad de funciones separa presencia y comportamiento.
• Comportamiento de WebAssembly entre plataformas cubre una superficie de ejecución compilada.
• Medir el rendimiento con User Timing registra tiempos en vez de percibirlos.
• Contextos seguros: por qué se exige HTTPS explica una condición que desactiva funciones en silencio.
• Política de mismo origen y aislamiento de sitio fija el límite de las pruebas entre superficies.
• Consultas de medios: respetar la elección del usuario trata las preferencias como entrada de plataforma.
• Resistencia de contextos de larga duración cubre la superficie después del primer minuto.

El hub posee el orden y la forma del registro compartido. Cada artículo enlazado posee el detalle de su superficie y los fallos que puede producir. Dos hábitos mantienen útil el grupo. El primero es leer los artículos en el orden anterior y no en el de publicación, porque cada superficie reduce lo que la siguiente puede explicar. El segundo es enviar al lector a un artículo concreto, no a la lista, cuando la revisión ya nombró una diferencia. Un hub que se convierte en una lista de lectura deja de ser un mapa de decisiones.

El grupo también fija un vocabulario común. «Soporte», «compatibilidad» (matches-declared-media), «consistencia» y «protección» significan cosas distintas: soporte es si una capacidad existe en una versión, compatibilidad es si el repliegue de la aplicación funciona, consistencia es si dos contextos del mismo perfil coinciden, y protección es si una página puede usar un valor para señalar a una persona o un dispositivo. Usar una sola palabra para las cuatro produce revisiones que no se pueden traspasar.

Ejecutar una revisión acotada

Parte de un fixture propio, fija su versión y declara qué espera la aplicación antes de leer nada. Después lee una fila por superficie en el mismo contexto y guarda el resultado junto al dato declarado. El registro son datos, no un informe, y debe ser lo bastante corto para adjuntarlo a un ticket.

{
  "runId": "platform-review-20261019-01",
  "declared": { "release": "Chrome 155", "profile": "fresh-temporary", "fixture": "app-shell@v7" },
  "observed": {
    "rendering": "matches-declared-media",
    "scriptExecution": "workers-available",
    "network": "request-headers-recorded",
    "capabilityAccess": "camera-denied"
  },
  "firstDifference": null,
  "testedOn": "2026-10-19"
}

Mantén fuera del registro las cookies, los identificadores de cuenta, las cabeceras sin depurar y cualquier resultado de un detector de terceros. Una capacidad negada a propósito es un estado declarado; una capacidad negada sin esperarlo es la primera diferencia, y el registro debe indicar cuál de las dos es.

El comando de validación produjo esta línea de stdout:

{"slug":"browser-platform-surface-overview","linkedArticles":10,"svg":true,"docsReference":true}

Declara la versión antes de la superficie. Anota la versión del navegador, la clase de perfil, la versión del fixture y la política de aplicación que el equipo quiere soportar. Un dato declarado es una entrada de la revisión, no una promesa sobre lo que observará la página. Con la entrada junto a la observación, una diferencia posterior tiene punto de referencia y un ingeniero de soporte distingue un cambio de plataforma de un fixture que envió otro contenido.

Una página por revisión. Una revisión que cambia de página entre filas no separa la diferencia de superficie de la de página. Carga una página propia, registra su versión y lee todas las filas de ese documento o de un worker que arranque de forma deliberada. Si el flujo necesita dos páginas, haz dos revisiones y enlázalas por runId en lugar de fusionar las filas. Así la primera diferencia es atribuible.

Lee las superficies en un orden fijo. Primero renderizado, porque una maquetación rota explica mucho de lo que viene después. Después ejecución de scripts, porque un fallo de worker o de módulo imita un fallo de red. Luego negociación de red, porque las cabeceras y la política deciden qué puede hacer la página. Por último acceso a capacidades, porque los permisos y sensores suelen informar su propio estado con claridad. Un orden fijo hace comparables dos revisiones aunque las ejecuten personas distintas.

Separa presencia de comportamiento. Un constructor que existe puede lanzar un error al llamarlo; una API puede existir y devolver un valor reducido; un permiso puede estar presente y el dispositivo no. Registra presencia y comportamiento en campos distintos. Esa es la distinción que desarrolla Soporte de funciones no es calidad, y la fuente más común de un diagnóstico falso.

Registra estados reducidos y no disponibles. Un user-agent reducido, un sensor no disponible y un permiso denegado son resultados legítimos de un navegador que respeta la privacidad. Registrarlos como estados, y no como fallos, mantiene la revisión sobre el contrato de la aplicación. Si la aplicación exige un valor que no está disponible, ese requisito pertenece al dato declarado para que la comprobación falle por la razón indicada.

Nombra al responsable de cada superficie. El renderizado suele pertenecer al responsable de plataforma o del sistema de diseño, la ejecución de scripts al equipo de aplicación, la negociación de red a infraestructura o al proveedor, y el acceso a capacidades al responsable de producto que decidió la política de permisos. Escribir al responsable en el registro durante la revisión ahorra un reenvío y hace el traspaso accionable.

Cambia una entrada por reintento. Congela el fixture, el perfil y la ruta, y cambia un solo valor declarado. Actualizar la versión, cambiar el perfil y cambiar la política son tres experimentos. Si dos entradas cambian juntas y la fila difiere, el registro no puede decir cuál la causó y el siguiente revisor repite el trabajo. Es la misma disciplina que las matrices de prueba aplican a las combinaciones.

Repite tras un cambio relevante. Vuelve a ejecutar el mapa cuando cambien la versión, el fixture, la clase de perfil o la política de aplicación, y actualiza testedOn en lugar de sobrescribir el registro anterior. Dos registros con fecha muestran qué cambió y cuándo, que es lo que necesita una pregunta de soporte. Los estándares públicos y los artículos enlazados siguen siendo la referencia de las definiciones.

Clasificar la primera diferencia

Si difiere el renderizado, compara el fixture y la hoja de estilos antes que la versión. Si difiere la ejecución, comprueba si el código corrió en el nivel superior, en un iframe o en un worker. Si difiere la red, compara cabeceras y política de respuesta, incluidos los requisitos de contexto seguro. Si difiere la capacidad, distingue una denegación declarada de una inesperada.

Detente en la primera diferencia, nombra a su responsable y conserva el registro. Una revisión que termina con una diferencia nombrada es más útil que otra con diez observaciones sin dueño.

Una diferencia de renderizado que solo aparece en un idioma suele pertenecer al repliegue de fuentes o a las métricas de texto, no a la versión; revisa font-family, font-size y las familias solicitadas antes que la versión reportada. Compara el mismo conjunto de glifos antes y después del cambio y registra qué familias se pidieron. Una diferencia que solo aparece en un contexto, como un iframe o un worker, pertenece al responsable de ese contexto; la página superior puede ser correcta mientras un documento incrustado falla.

Una diferencia de ejecución que desaparece al recargar es más a menudo un problema de ciclo de vida que de plataforma. Registra si el script corrió antes de DOMContentLoaded, si un import se resolvió y si el Worker recibió terminate(). Una diferencia que solo aparece tras varios minutos es una cuestión de recursos o de ciclo de vida, y el artículo sobre contextos largos describe qué cambia en ese punto.

Una diferencia de red que solo aparece detrás de un proxy o un contenedor pertenece al responsable del transporte antes que al navegador. Compara por separado cabeceras de petición, política de respuesta y dirección de salida (https://example.com/echo). El panorama de configuración de proxy recoge ese mapa de decisión y evita atribuir una diferencia del navegador a una ruta que nunca transportó la petición.

Una diferencia de capacidad que se manifiesta como fallo silencioso suele ser el resultado de una política de permisos o de contexto seguro, no de una API ausente. Comprueba si la función está permitida en la página (window.isSecureContext, una cabecera Permissions-Policy vacía o un navigator.permissions.query() previo en denied), y si el usuario o el perfil la denegaron antes. Solo después de esas tres comprobaciones la diferencia pertenece al responsable de plataforma.

Cada comprobación responde una pregunta y produce una línea del registro. El valor del orden está en que las comprobaciones posteriores se vuelven más simples: cuando renderizado y ejecución se estabilizan, la diferencia de red es la única explicación restante y la revisión no tiene que volver sobre superficies que ya coincidieron.

Conclusión práctica

La consistencia de la plataforma web sale de un orden fijo de superficies, un dato declarado y un registro corto. Usa este hub para ordenar la revisión y el grupo para el detalle, y limita cada conclusión a la versión, el perfil y la página que la produjeron.

Fuentes

• W3C: HTML Standard, definición de origin
• MDN: Content Security Policy
• MDN: Cross-Origin Embedder Policy
• WHATWG: Workers
• W3C: Pautas de accesibilidad para el contenido web
• MDN: características de las media queries
• Documentación de BotBrowser: visión general de huella