funcion - javascript detectar navegador movil

Detección de navegador contra detección de características

Question

Voy a hacer de abogado del diablo por un momento. Siempre me he preguntado por qué la detección del navegador (en comparación con la detección de características) se considera una mala práctica. Si pruebo una cierta versión de cierto navegador y confirmo que cierta funcionalidad se comporta de alguna manera predecible, entonces parece correcto decidir hacer un caso especial. El razonamiento es que será en el futuro infalible, porque esta versión parcial del navegador no va a cambiar. Por otro lado, si detecto que un elemento DOM tiene una función X, no significa necesariamente que:

1. Esta función funciona de la misma manera en todos los navegadores, y
2. Más importante aún, funcionará de la misma manera incluso en todos los navegadores futuros.

Acabo de echar un vistazo a la fuente de jQuery y tienen detección de detección insertando un fragmento de código HTML cuidadosamente construido en DOM y luego verifican ciertas características. Es una manera sensata y sólida, pero diría que sería demasiado pesado si hiciera algo como esto en mi pequeño fragmento de JavaScript personal (sin jQuery). También tienen la ventaja de recursos de control de calidad prácticamente infinitos. Por otro lado, lo que a menudo se ve a la gente hacer es que comprueban la existencia de la función X, y en base a esto, suponen que la función se comportará de cierta forma en todos los navegadores que tengan esta función.

No digo nada en el sentido de que la detección de funciones no sea buena (si se usa correctamente), pero me pregunto por qué la detección del navegador generalmente se descarta inmediatamente, incluso si suena lógico. Me pregunto si es otra cosa de moda para decir.

Answer 1

La solución ideal sería tener una combinación de características y detección de navegador. El primero se cae por los puntos que mencionas y el segundo porque a veces los navegadores publican información falsa para "hacer que las cosas funcionen".

Mozilla tiene un gran manual de detección de navegador que también puede ser útil para usted.

Desde wikipedia "En varios momentos de su historia, el uso de la Web ha estado dominado por un navegador en la medida en que muchos sitios web están diseñados para funcionar solo con ese navegador en particular, en lugar de según los estándares de organismos como el W3C y el IETF. Dichos sitios a menudo incluyen el código "sniffing del navegador", que altera la información enviada dependiendo de la cadena de caracteres User-Agent recibida. Esto puede significar que los navegadores menos populares no envían contenido complejo, aunque puedan tratarlo correctamente. o en casos extremos, rechazó todo el contenido. Por lo tanto, varios navegadores "ocultan" o "falsifican" esta cadena, para identificarse a sí mismos como algo más, a menudo la identidad real del navegador se incluye más adelante en la cadena ".

Answer 2

Me parece que la detección de navegadores ha sido mal vista desde que Resig lo publicó hace un par de años. Los comentarios de Resig, sin embargo, eran específicos del código de bibliotecas / framework, es decir, código que será consumido por otras aplicaciones / sitios [específicos del dominio].

Creo que la detección de características es sin dudas una buena opción para bibliotecas / frameworks . Sin embargo, para aplicaciones específicas de dominio no estoy tan seguro de que la detección del navegador sea tan mala. Es adecuado para trabajar con las características conocidas del navegador que son difíciles de detectar, o para los navegadores que tienen errores en la implementación de la función en sí. Veces que la detección del navegador es apropiada:

• sitios / aplicaciones que no son de navegador cruzado y necesitan mostrar una advertencia / diálogo / adaptación de DifferentPage al navegador de ese cliente. Esto es común en aplicaciones heredadas.
• Bancos o sitios privados con políticas estrictas sobre qué navegadores y versiones son compatibles (para evitar exploits de seguridad conocidos que puedan comprometer los datos del usuario)
• micro-optimizaciones: ocasionalmente un navegador es ridículamente más rápido que los otros cuando realiza alguna operación de cierta manera. Puede ser ventajoso dependiendo de su base de usuarios ramificarse en ese navegador / versión particular.
• Falta de transparencia png en IE6
• muchos problemas de visualización / renderización (léase: soporte de css de IE) que solo se atestiguan en versiones específicas del navegador y usted no sabe realmente qué función probar.

Dicho esto, existen algunos escollos importantes (probablemente cometidos por la mayoría de nosotros) para evitar al hacer la detección del navegador.

Answer 3

Aquí hay un buen artículo que explica cómo la detección de funciones es superior en muchos sentidos al rastreo de navegadores.

La verdad es que olfatear es extremadamente frágil. En teoría, es frágil, ya que depende de una cadena de userAgent arbitraria y luego prácticamente mapea esa cadena con un cierto comportamiento. También es frágil en la práctica, como ha demostrado el tiempo. Probar cada versión mayor y menor de docenas de navegadores e intentar analizar los números de compilación de algunas de esas versiones no es práctico en absoluto; Por otro lado, probar ciertas conductas por peculiaridades es mucho más sólido. Las pruebas de características, por ejemplo, a menudo detectan errores e inconsistencias que los proveedores de navegadores copian incidentalmente entre sí.

Desde mi propia experiencia, solucionando Prototype.js en IE8, sé que el 90% de los problemas podrían haberse evitado si no olfateamos en primer lugar.

Mientras reparaba Prototype.js descubrí que algunas de las características que deben probarse son en realidad muy comunes entre las bibliotecas de JS, así que hice una pequeña recopilación de pruebas de características comunes para cualquiera que desee deshacerse de la inhalación.