Por qué me importa este tema ahora
Si el UA es una declaración, entonces Web API es la superficie con la que se puede comprobar esa declaración.
La idea es simple. Los navegadores publican release notes. En esas notas aparecen nuevas API. Por tanto, el «piso» de capacidades se puede valorar no por un dígito en una cadena, sino por lo que realmente hay en runtime.
Lo llamo feature-floor — el piso de versión por capacidades.
Feature-detection vs parseo de versión
El parseo de versión responde: «¿cómo se nombró el navegador?» Feature-detection responde otra: «¿qué sabe hacer ahora mismo?»
Esas preguntas divergen más a menudo de lo que la práctica SEO y antifraud desearía.
Un motor viejo con UA nuevo — piso bajo con declaración alta. Un motor nuevo con UA recortado o raro — piso alto con insignia modesta. Flags, previews, implementaciones parciales — un piso «con entreplanta».
Páginas públicas como x-bot.tech muestran exactamente esta lógica: mirar las API y la coherencia de plataforma, no rezar a una sola cadena. Desgloso la idea como alfabetización, no como copia de un production ajeno.
Tipos de marcadores en palabras simples
En el laboratorio conviene pensar en tres cestas — sin nombres internos de flags.
Marcadores estrictos. API que en cierta rama ya deberían existir. Su ausencia con un número declarado alto es una contradicción fuerte.
Opcionales. Funciones que dependen de plataforma, política, permisos. La ausencia por sí sola dice poco.
Preview / experimentales. Las tienen algunos usuarios, otros no. No se puede colgar un veredicto de ellas.
El error del principiante es convertir todo el calendario de features en un checklist «bot/no bot». El hábito correcto es buscar la contradicción entre piso y declaración, no coleccionar «ausencias sospechosas».
De dónde sacar el calendario
No de la cabeza ni de un archivo cerrado en el portátil, si el objetivo es alfabetización pública.
Chrome release notes / New in Chrome. Firefox Releases en MDN. Blogs de WebKit / Safari.
Más detectores educativos abiertos como ejemplo de método, no como verdad absoluta.
A propósito no enumero aquí API concretas «para comprobar Chrome N». La lista envejece. El método permanece: declaración → piso esperado → medición → desajuste.
Enlace con la nota anterior
El UA dijo «estoy alto». El piso de versión dijo «el piso es más bajo». Eso no es automáticamente un bot. Es un agujero en el relato.
A veces el agujero es mi matriz desactualizada. A veces un build raro. A veces privacidad y superficies desactivadas.
Por eso la siguiente nota es sobre MDN browser-compat-data: cómo contrastar el calendario offline y por qué no se debe arrastrar BCD directamente a un veredicto en runtime.
Anclas públicas: https://x-bot.tech/chrome/version1/ https://developer.chrome.com/release-notes/ https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases https://webkit.org/blog/
Marco público (enlaces)
Cruzo el calendario de features con Chrome release notes, Firefox Releases y el blog de WebKit. Un ejemplo práctico público de este pensamiento es x-bot version1.
Qué cambia esto en el detect y/o en el build (sin detalles)
En el detect escribo más a menudo «la superficie parece de la época N±» que «versión demostrada». En el build compruebo si no estoy creando la superficie de una época con la declaración de otra. Los espejos vuelven a mirarse. La falsa precisión «versión = 131.4» me resulta menos útil que un intervalo de coherencia y una lista de contradicciones.
Lo que no diré y por qué
No publico tablas de marcadores internos, umbrales ni recetas de «cómo pintar el piso de versión para un sitio».
Conclusión breve en primera persona
Feature-floor enseña humildad: el navegador es un piso de capacidades, no una pegatina en la caja. Calibro el piso con release notes abiertas y compruebo la coherencia.
