Por qué me importa este tema ahora
Cuando aparece la idea de un feature-floor, enseguida apetece una «fuente oficial de verdad».
MDN browser-compat-data encaja casi perfectamente en ese rol — y casi igual de perfectamente rompe el laboratorio si se usa para lo que no toca.
Qué es BCD en palabras simples
Es un repositorio abierto de compatibilidad: qué APIs hay en qué navegadores y desde qué versión. Un calendario legible por máquina. No un post de blog. No una captura. La memoria JSON de la web.
Para un ingeniero es un regalo: puedes contrastar tu matriz «milestone ↔ API» con el conocimiento público, en vez de guardarla solo en la cabeza.
Para qué contrastar milestone y API
Porque la matriz miente más callada que un detector.
Puedo medir con honestidad la superficie del navegador e interpretar mal esa medición — si mi calendario está obsoleto, si mezclé desktop/mobile, si conté un preview como piso obligatorio.
BCD es una comprobación offline: «¿me mentí a mí mismo?»
Ritual típico:
- Tomé una hipótesis de las release notes.
- Fijé el piso esperado.
- Contrasté con BCD: cuándo la feature se volvió estable de verdad.
- Solo después miro el navegador vivo.
Así el calendario sigue siendo calendario. Y la medición, medición.
Por qué runtime sobre BCD es mala idea
Porque BCD describe el mundo «como suele contarse en la documentación», no «qué tiene ahora mismo este usuario».
Usuario en un canal con flags. Build corporativo con superficies recortadas. Diferencias regionales. Retrasos entre «apareció en notes» y «está en el 95% de clientes». Errores y lag del propio dataset.
Si arrastras BCD al runtime como oráculo de «eres bot», obtienes un detector de documentación, no de coherencia.
Peor — mezclar BCD con el veredicto. Entonces cualquier desvío de la tabla se vuelve etiqueta moral. Y el desvío a menudo significa: «mi modelo del mundo está incompleto».
En el diario del laboratorio esto importa éticamente. Prometí no publicar umbrales ni recetas de bypass. Pero incluso sin eso se puede dañar el método: convertir un calendario público en una porra.
Cómo mantengo el límite
BCD — para calibrar matrices en casa. Release notes — para el calendario primario. Navegador vivo y baseline del teléfono — para medir. El detector — para buscar contradicciones de capas, no para contrastar JSON como texto sagrado.
Tres notas seguidas (UA → feature-floor → BCD) cierran el arco «declaración vs medición» a nivel de alfabetización. Lo siguiente en el plan — tres habitaciones de una verdad: main, iframe, Worker.
Anclas públicas: https://github.com/mdn/browser-compat-data https://developer.chrome.com/release-notes/
Marco público (enlaces)
El repositorio mdn/browser-compat-data y las notas de release de Chrome/Firefox/WebKit son tres patas de un taburete. Una sin las otras dos tambalea: BCD puede retrasarse, las notes pueden ser marketing, WebKit vive a su ritmo.
Qué cambia esto en el detect y/o en el build (sin detalles)
BCD ayuda a preparar preguntas antes del experimento. En runtime escucho la superficie real. En el build no «ajusto a una fila de BCD», sino que compruebo si la superficie se desalineó de la época declarada. Flags, policies enterprise, implementaciones parciales y motores alternativos en iOS en la UE hacen débil el veredicto «BCD dijo».
Lo que no diré y por qué
No publico reglas automáticas del tipo «si BCD, entonces score». Ese camino lleva a una precisión falsa.
Breve conclusión en primera persona
BCD es un calendario en la pared del laboratorio. El calendario no sentencia a la persona en la mesa. Contraste fechas offline y mido lo vivo online.
