有什么理由在2011年放弃javascript flash嵌入方法吗？

据我所知，使用JS嵌入flash的好处：

• 能够查询

  navigator

  对象并查看安装了哪些flash版本，可能会在此基础上扩展并提供不同的内容
• 连接flash的一致方法，因为脚本保留标记，通常只需要指定

  src

  ，

  flashvars

  ，维度
• 通过依赖助手实用程序嵌入swf而不必担心复杂的细节，可以节省时间
• 如果每个站点嵌入多个对象，则能够提供一致的回退

缺点是：

• 没有闪存但启用JS的设备将完全失败
• 人们变得懒惰，不提供后备内容
• 如果代码需要跨浏览器兼容，那么它就是一团糟。常见的嵌入（甚至是youtube的）有各种各样的bug，“最好的”跨浏览器似乎是在每个对象中嵌套一个对象。虽然我意识到，我可以使用服务器端方法，定义嵌入代码一次，然后在一个区域中更改它，但这使得它在CMS文本区域中不可嵌入/可用

---

利大于弊。我对移动内容的研究还不够深入，无法获得准确的意见。有人能想出原因吗？

我看不出有什么好的理由放弃JS flash嵌入。SWFObject现在非常普遍（甚至是伪标准！），而且

它使得处理播放器版本要求和允许用户简单直接地更新Flash插件等棘手的事情变得容易

撇开SWFObject不谈，我认为能够使用客户端逻辑为任何插件嵌入内容将永远是一条出路；它提供了更多了解用户环境的机会，并提供适当的内容

我想可以这样说，它在客户端增加了另一个交付内容的要求，但我认为绝大多数用户将启用JS。。。尤其是那些愿意使用Flash媒体的用户

希望有帮助：）

缺点：

没有闪存但启用了JS的设备 将完全失败

正如@Lars在他的评论中指出的，我认为通过JS检测Flash是一种故障保护方法，可以为不同的平台（操作系统、浏览器、Flash播放器版本）注入不同的内容（swf）。同时禁用Flash和JS的设备可能会出现地狱般的混乱，但这只占很小的比例。我想不出一个简单的方法来绕过这一点

人们变得懒惰，不提供服务 后备内容。

这显然是非常主观的。我使用SwfObject的经验很少，但在我的例子中，当我们检测到无FLASH的情况时，我们正在退回到一个纯粹的基于HTML DOM的解决方案，使用大量的JS来模拟模块。我的观点是，使用SwfObject，提供替代内容非常容易，我不明白为什么任何优秀的开发人员都不会这样做

如果需要，代码就是一团糟 跨浏览器兼容。有 常见的嵌入错误( 甚至是youtube）和“最好的” 跨浏览器似乎正在嵌套一个 对象中的对象。我 不过要知道，我可以用 服务器端方法并定义 将代码嵌入一次并在中进行更改 一个领域，但这并不意味着 可嵌入/可用于CMS文本区域。

我想我会在一定程度上同意这一点。不同的嵌入方法是一团糟。StackOverflow上有一个线程正在讨论此问题：

有些情况下，除了使用Flash之外别无选择，例如：带有上传百分比反馈的文件上传器（因为常规的输入标记类型文件太过时了）。虽然有新的方法可以做，但它在你知道的情况下不起作用（例如：）

---

在这种情况下，没有办法摆脱Flash IMHO。

作为一个反问：有什么理由在2011年使用javascript嵌入方法吗

我发现该方法在跨浏览器时效果最好，并且遵循一个基本策略

标记如下：

<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>

---

只要你不关心检查用户的flash版本（本文中提供了一个解决方法），这就非常有效。

如果与

和

一起出现

或类似的内容，那就太好了。我认为一个更好的问题可能是：有没有理由在2011年放弃Flash。好问题，我想从这方面的专家那里得到答案。闪存嵌入似乎是一门黑暗的艺术。我不明白你所说的“没有闪存但启用了JS的设备将完全失败”是什么意思。这不是通过JS嵌入的场景之一吗？JS会检测Flash是否可用，如果可用，则只显示Flash元素？@zzzzBov:请注意，您提供的代码在IE9 RC中不起作用。