2010-11-23 9 views
9

Los beneficios de la incorporación de Flash con JS, que yo sepa:¿Hay alguna razón para deshacerse de los métodos de incrustación de JavaScript en 2011?

  • capacidad de consultar navigator objeto y ver qué versiones flash instaladas, posiblemente se ramifican en eso y alimentar un contenido diferente en base a este
  • método consistente de adjuntando flash, como el guión mantiene el margen de beneficio y por lo general sólo tiene que especificar los src, flashvars, dimensiones
  • ahorrar tiempo al confiar en los servicios públicos de ayuda para incrustar el swf y no preocuparse por los detalles intrincados
  • capacidad de pr Proporcione un respaldo constante si incorpora varios objetos por sitio.

Las desventajas:

  • dispositivos sin flash, pero JS habilitado fallará completamente
  • gente perezosa y no proporcionan el contenido de reserva
  • código es un desastre si necesita estar compatible con varios navegadores hay varios errores con inserción común (incluso de youtube) y el "mejor" navegador cruzado parece estar anidando un objeto en un objeto por this. Sin embargo, me doy cuenta de que puedo usar un método del lado del servidor y definir el código de incrustación una vez y cambiarlo en un área, pero esto hace que no se pueda insertar/usar en las áreas de texto de CMS.

Los pros parecen superar los inconvenientes. Realmente no he trabajado lo suficiente con el contenido móvil para obtener una opinión precisa. ¿Alguien puede pensar en por qué/por qué no?

+0

Sería bueno si junto con '

+0

Buena pregunta, y una a la que me gustaría obtener una respuesta de alguien experto en esta área. La incrustación flash parece un arte oscuro. –

+8

No entiendo lo que quiere decir con "dispositivos sin flash pero JS habilitado fallará por completo". ¿No es ese uno de los escenarios para los que se usa la inserción a través de JS? ¿El JS detecta si Flash está disponible y solo muestra el elemento Flash si ese es el caso? –

Respuesta

2

No veo una buena razón para deshacerse de la incrustación flash JS. SWFObject es bastante omnipresente en estos días (incluso pseudo-estándar!) Y even Adobe recommends using it.

Hace que las cosas pegadizas como el manejo de los requisitos de la versión de jugador y que permite al usuario actualizar su plugin de Flash fácil y directo.

SWFObject a un lado, es mi opinión que ser capaz de utilizar la lógica del lado del cliente para incrustar contenido para cualquier complemento siempre será el camino a seguir; brinda más oportunidades para leer en el entorno de usuario y entregar el contenido apropiado.

Supongo que se puede argumentar que agrega otro requisito más en el lado del cliente para entregar su contenido, pero creo que la gran mayoría de los usuarios tendrán habilitado JS ... especialmente los usuarios que están dispuestos a consumir Flash medios de comunicación.

Espero que ayude :)

3

Las desventajas:

  1. dispositivos sin flash, pero JS habilitado fallará completamente

    Como @Lars señaló en su comentario, Creo que detectar Flash a través de JS es una forma segura de inyectar contenido diferente (swf) para diferentes plataformas (sistema operativo, navegador, versión de Flash Player). Los dispositivos que tienen tanto Flash como JS deshabilitados son los dispositivos en los que todo el infierno podría desatarse, pero ese sería un porcentaje muy pequeño. No puedo pensar en una manera fácil de eludir eso.

  2. personas se vuelven perezosas y no proporcionan contenido alternativo.

    Obviamente, esto es muy subjetivo. He tenido muy poca experiencia en el uso de SwfObject, pero en mi caso, estábamos recurriendo a una solución basada en HTML DOM puro que utilizaba gran cantidad de JS para simular el módulo cuando detectamos una situación NO FLASH. Mi punto es que con SwfObject, proporcionar contenido alternativo es muy fácil y no veo por qué un buen desarrollador no hará eso.

  3. código es un desastre si necesita ser compatible con varios navegadores. hay varios errores con incrustación común ( incluso youtube) y el "mejor" cross-browser parece estar anidando un objeto en un objeto por esto. I Sin embargo, puedo usar un método del lado del servidor y definir el código de incrustación una vez y cambiarlo en un área, pero esto hace que no sea incrustable/utilizable en áreas de texto CMS.

    Creo que estaría de acuerdo con este en cierta medida. Diferentes métodos de incrustación son un desastre. Hay este hilo en StackOverflow discutir este tema: Best way to embed flash in html

Hay situaciones en las que no hay otra alternativa que usar Flash, por ejemplo: un cargador de archivos con retroalimentación porcentaje de carga (como archivo de entrada regular de tipo de etiqueta es demasiado arcaico). De acuerdo existe la nueva forma de hacer upload progress bar using just javascript pero no funcionará en usted sabe IE :)

En tales situaciones, no hay manera de deshacerse de Flash en mi humilde opinión.

1

Como pregunta de contador: ¿hay alguna razón para utilizar métodos de incrustación de JavaScript en 2011?

Me parece que el método flash satay funciona mejor en todos los navegadores, y sigue una política en su mayoría DRY.

El marcado es el siguiente:

<object id="something" name="something" type="application/x-shockwave-flash" data="path/to/file.swf"> 
    <param name="movie" value="path/to/file.swf" /> 
    <param name="flashvars" value="query=string" /> 
    <!-- Backup content here --> 
</object> 

Esto funciona muy bien siempre y cuando no se preocupan acerca de la comprobación versión flash del usuario (una solución alternativa está previsto en el artículo).

+0

** @ zzzzBov **: Tenga en cuenta que el código que ha proporcionado no funciona en IE9 RC. –

Cuestiones relacionadas