Respuesta corta: en Chrome 153, <camera> y <microphone> tienen más sentido cuando una página necesita una sola capacidad —solo vídeo o solo audio— y quiere que la solicitud parta de un control visible, activado directamente por el usuario y mediado por el navegador. getUserMedia() sigue siendo la opción más segura cuando pesan más la interoperabilidad entre navegadores, la orquestación propia del flujo, los requisitos estrictos de dispositivo o la compatibilidad con código existente.
Chrome incluye ambos elementos en las notas oficiales de Chrome 153, cuya versión Stable tiene fecha del 8 de septiembre de 2026. Siguen el modelo de Capability Elements: el control mostrado dentro de la página está gestionado y fuertemente restringido por el navegador, y la captura solo comienza después de una señal explícita de intención del usuario. El cambio principal es quién controla el momento y la superficie de la solicitud de permiso; no elimina los permisos, HTTPS, las políticas del navegador ni la necesidad de fallback.
Qué cambió exactamente en Chrome 153
<camera> media el acceso a una única MediaStreamTrack de vídeo; <microphone>, a una única track de audio. La especificación Media Capture and Streams Extensions define para ambos una propiedad de solo lectura track, una propiedad error, el método setConstraints() y los eventos track, cancel y error.
En la práctica, el elemento encapsula el paso de solicitar el medio. Cuando una interacción genuina del usuario lo activa, el navegador inicia por debajo un flujo equivalente a getUserMedia() para la capacidad correspondiente. Si tiene éxito, la track queda disponible en element.track y se dispara el evento track. Si el usuario abandona o rechaza durante la interacción, el flujo puede terminar en cancel; otros fallos se exponen mediante error.
Esto no convierte getUserMedia() en una API obsoleta. Los nuevos elementos son una capa declarativa y especializada sobre el mismo problema de captura, optimizada para un caso de uso más estrecho.
Matriz rápida: úsalo cuando / evítalo cuando
| Situación | Mejor punto de partida | Motivo |
|---|---|---|
| Capturar solo vídeo, con una acción clara del usuario | <camera> | Semántica de una sola capacidad, UI de intención controlada por el navegador y entrega directa de una track de vídeo. |
| Capturar solo audio, como una nota de voz o una prueba de micrófono | <microphone> | Evita pedir acceso a la cámara sin necesidad y mantiene la solicitud en contexto. |
| Necesitar cámara y micrófono juntos | <usermedia> o getUserMedia() | Los elementos de Chrome 153 están diseñados para una sola capacidad; <usermedia> es el control declarativo combinado. |
| La aplicación debe funcionar de forma consistente fuera de Chromium | getUserMedia() con progressive enhancement | Los nuevos elementos todavía no deben tratarse como soporte interoperable universal. |
| El flujo depende de requisitos estrictos de cámara, resolución o dispositivo | getUserMedia() o validación adicional de la track | El borrador actual filtra constraints obligatorias antes de que el elemento haga la solicitud. |
| La aplicación ya tiene una capa madura de selección, cambio y reanudación de dispositivos | Mantener getUserMedia() y probar la migración por etapas | La mayor ganancia del elemento está en intención/permisos; no es automáticamente mejor para toda la orquestación de medios. |
Ejemplo mínimo con <camera> y fallback
Una implementación de producción debe detectar soporte y conservar una ruta convencional. La detección siguiente es coherente con la interfaz HTMLCameraElement expuesta por la especificación:
<camera id="camera-control"> <button id="camera-fallback" type="button">Activar cámara</button> </camera> <video id="preview" autoplay playsinline muted></video> <script> const preview = document.querySelector('#preview'); const fallback = document.querySelector('#camera-fallback'); if ('HTMLCameraElement' in window) { const camera = document.querySelector('#camera-control'); camera.setConstraints({ width: { ideal: 1280 }, height: { ideal: 720 } }); camera.addEventListener('track', () => { preview.srcObject = new MediaStream([camera.track]); }); camera.addEventListener('cancel', () => { console.log('El usuario no completó el acceso a la cámara.'); }); camera.addEventListener('error', () => { console.error(camera.error); }); } else { fallback.addEventListener('click', async () => { preview.srcObject = await navigator.mediaDevices.getUserMedia({ video: true }); }); } </script>Para micrófono, la lógica es equivalente: comprueba 'HTMLMicrophoneElement' in window, escucha track y usa microphone.track. Si la aplicación necesita combinar audio y vídeo en un único MediaStream, también puede construir ese stream a partir de las tracks obtenidas, pero en ese punto conviene comparar la complejidad con <usermedia> o con una sola llamada getUserMedia({audio:true, video:true}).
Qué cambia en el permiso —y qué no cambia
Con getUserMedia(), el sitio llama a una API imperativa y el navegador decide, según el estado y sus heurísticas, si muestra una solicitud y cómo lo hace. Con Capability Elements, el control de captura queda incrustado en la página, pero su presentación pertenece al navegador y la activación debe venir de una acción real del usuario. La documentación de <usermedia>, que usa el mismo modelo de seguridad y recuperación que Chrome 153 cita para los nuevos elementos, describe este diseño como una forma de dar al navegador una señal más fuerte de intención y ofrecer una recuperación más directa cuando el usuario ya había rechazado el acceso.
- No hay concesión automática: el elemento no evita la decisión del usuario ni las políticas del sistema operativo.
- HTTPS sigue siendo necesario: la especificación indica que <camera> y <microphone>, al igual que getUserMedia(), solo funcionan en un contexto seguro; fuera de él puede mostrarse el contenido de fallback.
- Un clic sintético no sustituye al usuario: la activación se filtra para aceptar una acción genuina; los eventos no confiables fallan en lugar de iniciar captura silenciosamente.
- Puede que el prompt no aparezca: si el navegador puede satisfacer la solicitud con el permiso ya existente, la captura puede continuar sin una nueva pregunta.
- Cancelación y error quedan separados: eso ayuda a no tratar cada desistimiento del usuario como un fallo técnico.
Por tanto, el cambio es menos “un permiso nuevo” y más una forma nueva de expresar intención y conducir el ciclo de permiso/captura.
Las constraints no son idénticas a un getUserMedia() directo
setConstraints() existe tanto en <camera> como en <microphone>, pero hay una salvedad importante: en el borrador actual, el algoritmo elimina las constraints clasificadas como obligatorias antes de construir la solicitud de captura subyacente. Esto evita que el control de permiso se convierta en una superficie que falle por requisitos duros antes de que el usuario complete una elección.
Consecuencia práctica: si tu producto depende de una cámara concreta, de una resolución que deba ser obligatoria o de una política estricta de selección de dispositivo, no trates setConstraints() del Capability Element como sustituto mecánico de toda la lógica existente. Valida track.getSettings(), prueba applyConstraints() sobre la track cuando tenga sentido y conserva el flujo tradicional donde un requisito duro sea esencial.
Aún hay detalles de ciclo de vida que requieren pruebas
La propia propuesta señala que el comportamiento de una nueva activación cuando el elemento ya tiene una track todavía debe definirse; el algoritmo actual ignora la activación si la track ya está establecida. Esto importa en interfaces que esperan usar el mismo control para detener, reiniciar, cambiar de dispositivo o recuperar una captura finalizada.
Por eso, las aplicaciones con lógica de medios sofisticada deben probar explícitamente escenarios como track.stop(), cambio de cámara, suspensión, reanudación y transiciones entre estados. Si esos comportamientos son centrales, getUserMedia() sigue ofreciendo una superficie conocida y controlable mientras la propuesta evoluciona.
Cómo planificar el fallback sin duplicar toda la aplicación
La estrategia más simple es separar la adquisición del medio del resto de la aplicación. Crea una función que reciba una MediaStreamTrack o un MediaStream y conecte ese medio al preview, Web Audio, WebRTC o pipeline de procesamiento. Después, elige solo la capa de adquisición:
- si existe HTMLCameraElement, usa <camera> para vídeo;
- si existe HTMLMicrophoneElement, usa <microphone> para audio;
- si no existe, activa navigator.mediaDevices.getUserMedia() desde el botón de fallback;
- si necesitas cámara y micrófono juntos, evalúa <usermedia> cuando tenga soporte y conserva el mismo fallback convencional.
El Intent to Ship de Chromium describió la disponibilidad esperada como limitada a navegadores Chromium y no registraba señal de Gecko ni WebKit en ese momento. Eso basta para una recomendación conservadora: no bases producción en detectar la versión de Chrome; usa feature detection y conserva un fallback funcional.
Checklist antes de producción
- Confirma que el caso es realmente de una sola capacidad.
- Sirve la experiencia por HTTPS y prueba restricciones de permisos en entornos administrados o corporativos.
- Usa 'HTMLCameraElement' in window y/o 'HTMLMicrophoneElement' in window, no user-agent sniffing.
- Conserva un botón de fallback que llame a getUserMedia() en navegadores sin soporte.
- Prueba por separado las rutas track, cancel y error.
- No intentes camuflar ni automatizar el control: la UI y la activación están protegidas deliberadamente por el navegador.
- Si las constraints estrictas son un requisito de negocio, valida la track adquirida en vez de asumir equivalencia total con getUserMedia().
- Prueba cierre y readquisición del medio, porque el comportamiento posterior a la track todavía tiene puntos abiertos en la propuesta.
Regla de decisión: adopta <camera> o <microphone> cuando la mejora de UX provenga de una solicitud contextual, explícita y de una sola capacidad. Sigue con getUserMedia() cuando necesites alcance entre navegadores, control fino del flujo o un comportamiento ya estabilizado. En Chrome 153, el camino más sólido para producción es progressive enhancement, no una migración de “todo o nada”.
