使用特定于供应商的扩展的优缺点是什么,这些扩展未包含在W3C规范中？

Question

我编辑了我的问题

什么是供应商特定的扩展？

特定于供应商的扩展可以以" - "(破折号)或"_"(下划线)开头,通常后跟公司的缩写或扩展名专用的浏览器项目,对于Mozilla浏览器,为"moz-moz-" ,或基于WebKit的浏览器的"-webkit-".此供应商特定前缀后跟属性名称.一个很好的例子是-webkit-border-radius,或-moz-border-radius.

IE有三件事

1. .htc文件支持(和javascript一样)
2. 和css表达式(也是javascript的一种形式)
3. 有的IE仅XHTML和CSS属性也

Web-kit和Mozilla也有一些自己的css属性.

和其他一些链接

http://webdesign.about.com/cs/htmltags/a/aa012300a.htm

http://reference.sitepoint.com/css/vendorspecific#

http://www.456bereastreet.com/archive/200911/vendor-specific_extensions_are_invalid_css/

http://www.css3.info/vendor-specific-extensions-to-css3/

我的问题

如果我们使用非W3C标准的东西,我们现在或将来可能会面临任何问题吗？

1. 如果我有一个jquery解决方案和供应商specfic css两个相同的解决方案,那么我应该使用哪个？使用供应商specfic css解决方案将有效,如果js被禁用但页面将不会在w3c验证器中验证,如果我使用js解决方案,那么页面将在验证器中传递.

   • 例如喜欢制作圆角

2. 如果网站由于使用特定于供应商的东西而未经W3C完全验证,那么它是否会受到伤害？我应该尽可能避免供应商特定的东西以获得良好的跨浏览器和平台兼容性(如PC,MAC,iPhone,其他手机). ？

3. 如果我在两者中都有解决方案来获得通过w3c验证,我应该选择js解决方案而不是供应商specpic css属性吗？(但如果我每次选择js解决方案,那么网站在移动浏览器上将无法正常工作)如果w3c验证为供应商特定扩展提供错误,是否可以离开？

Answer 1

呃......他们不会在其他浏览器上工作......？

Answer 2

在考虑特定于供应商的扩展时，您应该尝试遵循的原则是渐进增强。基本思想是您应该设计您的网站，以便为尽可能多的人服务；将其设计为在终端客户端上以纯 HTML 3.2 工作，没有 JavaScript、CSS 或任何类型的供应商特定扩展。

然后，您添加样式和功能，使用并非所有浏览器都支持的更高级标准，使用视觉媒体设计，使用可能被禁用的 CSS 和 JavaScript，最后，使用供应商特定的扩展，这些扩展完全不受浏览器支持。其它浏览器。但是因为您刚开始设计时给出了一组每个人都支持的通用功能，所以您不需要新功能中的额外功能即可使站点正常工作；它将继续在具有旧功能的旧浏览器中工作，因为新功能是作为增强功能添加的，而不是作为您网站工作必不可少的东西。

因此，您不应依赖这些特定于供应商的扩展，而应将它们用作增强功能。如果由于某种原因，你确实依赖它们——如果你的产品在没有特定浏览器上可用的扩展程序的情况下无法运行——那么可能值得使用一个。但在这种情况下，您的未来与该浏览器密不可分。如果它落在路边，你就是SOL。如果它最终仅在韩国使用，并且您的产品是德语，而另一种浏览器占主导地位，那么您又是 SOL。

现在，在做出这些决定时，有多种特定于供应商的功能可供选择。有些功能总是特定于特定供应商的；不适用于其他平台的功能，或已向标准机构提出但整个方法已被拒绝的功能。这些功能是您想要非常、非常明智地使用的功能。

标准轨道上还有其他功能。它们在当前的 CSS 3 草案中，它们几乎兼容地在两个或三个不同的浏览器中实现。如果您的用户群都支持这些功能，您就可以开始依赖这些功能，因为它们肯定会在未来的某个时刻由大多数主要浏览器（由大多数潜在用户使用）实现未来。

因此，总而言之，我想说您应该可以随意向您的页面添加仅在单个浏览器中支持的效果。但是你不应该依赖这些，除非你有充分的理由相信它们很快就会被所有主要浏览器支持。主流浏览器支持的 HTML 的当前状态可以做很多事情；尽可能多地尝试在当前标准和浏览器之间通用的功能下工作，同时记住遵守标准不是支付账单，而是提供功能和一定数量的风格。

作为对您的问题的直接回答，关于供应商特定扩展的优缺点：

优点

• 访问可能会很快普及的功能
• 为您的客户提供更好的价值
• 你可以做很酷很有趣的事情
• 帮助鼓励其他浏览器的实施者和从事标准工作的人，认为此功能是个好主意

缺点

• 该功能可能会消失，即使在同一浏览器的更高版本中也不会出现
• 如果您依赖此类扩展程序，您可能会严重限制您的用户群
• 该功能在发布之前可能会发生显着变化，导致页面损坏，或者一些新的嗅探模式很难弄清楚。

至于您应该使用基于 JavaScript 的方法还是 CSS 扩展方法，您应该根据具体情况做出判断。如果您已经能够遵循渐进增强的原则，那么它们都可以很好地使用。只要它不是您网站的基本功能，或者您找到为所有主要浏览器做同样事情的替代方法，我会说 CSS 将比 JavaScript 解决方案更受欢迎，因为它通常更小，加载速度更快。

关于验证，需要考虑的一点是，虽然确保您的 HTML 验证通常是一个好主意（尽管并非总是必要的；例如，参见Google，他们认为最小化下载大小比验证更重要），但由于特定于供应商的验证失败CSS 中的属性不太重要。在 CSS 中，未知属性被定义为仅被忽略，因此即使由于您使用特定于供应商的属性而无法验证它，您也知道它在不支持该属性的浏览器中的行为；他们只会忽略它。如果您遵循了渐进增强的方法，那么如果忽略这些属性，您的网站应该仍然可以正常工作，这意味着除了您的网站看起来不太好之外，没有其他负面影响。