使用 W3C 规范中未包含的特定于供应商的扩展有哪些优点和缺点？
我编辑了我的问题
什么是供应商特定扩展？
可以启动供应商特定的扩展 带有“-”（破折号）或“_” （下划线），通常后跟 公司或公司的缩写 浏览器项目的扩展名是 特定于，fi “-moz-” 用于 Mozilla 浏览器，或 WebKit 的“-webkit-” 基于浏览器。该供应商特定 前缀后面是属性 姓名。一个很好的例子是 -webkit-border-radius 或 -moz-border-radius。
IE 有 3 个功能：
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 标准 CSS，我们现在或将来会遇到任何问题吗？ 示例：
如果我有同一解决方案的 jquery 代码和供应商特定的 CSS 代码，我应该使用哪一个？如果禁用 JS，则使用特定于供应商的 CSS 解决方案将起作用，但页面将无法通过 W3C 验证。如果我使用 JS 解决方案，页面将在验证器中传递。一个例子是制作圆角。
如果网站由于使用特定于供应商的属性而未经过完全 W3C 验证，会产生任何影响吗？我是否应该尽可能避免特定于供应商的事情，以获得良好的跨浏览器和平台兼容性，例如 PC、MAC、iPhone、其他移动设备？
如果我为了通过 W3C 验证而同时拥有两种解决方案，我是否应该选择 JS 解决方案而不是特定于供应商的 CSS 属性？如果我每次都选择 JS 解决方案，网站将无法在移动浏览器上正常运行。如果 W3C 验证针对特定于供应商的扩展给出错误，是否可以忽略它？
I edited my question
What is a vendor specific extension?
A vendor specific extensions can start
with a “-” (dash) or a “_”
(underscore), usually followed by an
abbreviation of the company or the
browser project the extension is
specific for, f.i. “-moz-” for Mozilla
browsers, or “-webkit-” for WebKit
based browsers. This vendor specific
prefix is followed by the property
name. A good example of this is
-webkit-border-radius, or -moz-border-radius.
IE has 3 things:
- .htc file support (same as javascript)
- css expressions (also a form of javascript)
- some IE only xhtml and css
properties
Web-kit and Mozilla also have some of their own CSS properties.
Some others links:
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/
My questions:
Could we face any problem now or in future if we use non-W3C standard CSS?
Examples:
If I have a jquery code and vendor-specfic CSS code for the same solution, which should i use? Using a vendor-specfic CSS solution will work if JS is disabled but the page will not pass W3C validation. If I use the JS solution the page will be passed in validator. An example would be for making a round corner.
Will it hurt in any sense if the site is not fully W3C validated due to using vendor-specific properties? Should I avoid vendor-specfic things as much as possible to get good cross-browser and platform compatibility such as for PC, MAC, iPhone, other mobiles?
Should I choose a JS solution over a vendor-specfic CSS property if I have a solution in both for the sake of passing the W3C validation? If I choose the JS solution every time the site will not work well on mobile browsers. Is it alright to leave it alone if the W3C validation is giving an error for vendor-specific extensions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在考虑供应商特定扩展时，您应该尝试遵循的原则是渐进增强。基本思想是，您应该将网站设计为适合尽可能多的人；将其设计为在终端客户端上以纯 HTML 3.2 运行，无需 JavaScript、CSS 或任何类型的供应商特定扩展。
然后，您添加样式和功能，使用并非所有浏览器都支持的更高级标准，使用视觉媒体设计，使用可能被禁用的 CSS 和 JavaScript，最后使用供应商特定的扩展，这些扩展根本不受浏览器支持其他浏览器。但是，由于您首先开始设计时给出了一组每个人都支持的通用功能，因此您不需要新功能中的额外功能即可使网站正常工作；它将继续在旧浏览器中使用旧功能，因为新功能是作为增强功能添加的，而不是作为网站运行所必需的东西。
因此，您不应该依赖这些特定于供应商的扩展，而应将它们用作增强功能。如果出于某种原因，您确实依赖它们（如果没有特定浏览器上可用的扩展程序，您的产品就无法运行），那么可能值得使用它们。但在这种情况下，你的未来就与该浏览器密不可分。如果它半途而废，那么您就是 SOL。如果它最终只在韩国使用，而您的产品是德语版本，而另一种浏览器占主导地位，那么您又是 SOL。
现在，在做出这些决策时，可以选择不同类型的特定于供应商的功能。有些功能始终是特定于特定供应商的；不适用于其他平台的功能，或者已向标准机构提出但整个方法已被拒绝的功能。这些功能是您需要非常非常明智地使用的功能。
标准轨道上还有其他功能。它们处于当前的 CSS 3 草案中，它们在两个或三个不同的浏览器中几乎兼容地实现。如果您的用户群都支持这些功能，您就可以开始依赖这些功能，因为它们很肯定会在未来的某个时刻被大多数主要浏览器（由大多数潜在用户使用）实现。未来。
因此，总而言之，我想说，您应该随意向仅在单个浏览器中支持的页面添加效果。但您不应该依赖这些，除非您有充分的理由相信它们很快就会受到所有主要浏览器的支持。目前主流浏览器支持的 HTML 可以做很多事情；尝试尽可能在当前标准和浏览器之间通用的功能范围内工作，同时记住，遵守标准并不是支付账单，而是提供功能和一定的风格。
作为对您问题的直接回答，关于供应商特定扩展的优缺点：
优点
缺点
至于是否应该使用基于 JavaScript 的方法或 CSS 扩展方法，您应该根据具体情况做出判断。如果您能够遵循渐进增强的原则，那么它们都可以很好地使用。只要它不是您网站的基本功能，或者您找到了为所有主要浏览器执行相同操作的替代方法，我会说 CSS 会优于 JavaScript 解决方案，因为它通常更小并且更小加载速度更快。
关于验证需要考虑的一点是，虽然确保 HTML 验证通常是一个好主意（尽管并不总是必需的；请参阅 Google，他们认为最小化下载大小比验证），由于 CSS 中特定于供应商的属性而导致的验证失败不太重要。在 CSS 中，未知属性被定义为仅被忽略，因此即使它因使用供应商特定属性而未验证，您也知道它在不支持该属性的浏览器中的行为方式；他们只会忽略它。如果您遵循渐进增强的方法，那么如果忽略这些属性，您的网站应该仍然可以正常工作，这意味着除了您的网站看起来不太好之外，没有任何负面影响。
The principle you should try to follow, when considering vendor specific extensions, is progressive enhancement. The basic idea is that you should design your site to work for as many people as possible; design it to work in plain HTML 3.2, on a terminal client, with no JavaScript, CSS, or any sort of vendor specific extension.
Then, you add on style and functionality, using more advanced standards that not all browsers support, using designs for visual media, using CSS and JavaScript which may be disabled, and finally, using vendor-specific extensions, which are not at all supported by other browsers. But because you first started designing given a common set of functionality that everyone supports, you don't need the extra functionality from the new features for the site to work; it will continue working in old browsers, with old features, as the new features were added as enhancements, not as something essential for your site to work.
So, you shouldn't rely on these vendor-specific extensions, but use them as enhancements. If for some reason, you do rely on them—if your product cannot function without an extension available on a particular browser—then it may be worth using one. But in that case, your future is inextricably linked to that browser. If it falls by the wayside, you're SOL. If it winds up being used only in Korea, and your product is in German where another browser is the dominant one, again, you're SOL.
Now, there are different sorts of vendor-specific features to choose from when making these decisions. There are some features that will always be specific to a particular vendor; features that are not applicable on other platforms, or which have been proposed to a standards body and that entire approach has been rejected. These features are ones that you want to use very, very judiciously.
There are other features which are on the standards track. They are in a current CSS 3 draft, they are implemented in two or three different browsers almost compatibly. These features are ones that you may be able to begin relying on, if your user base all support them, as they are pretty certain to be implemented by a majority of major browsers (used by a majority of potential users) at some point in the future.
So, in sum, I would say that you should feel free to add effects to your pages that are supported only in an individual browser. But you shouldn't rely on these, unless you have a good reason to believe that they will soon be supported by all of the major browsers. The current state of HTML supported by the major browsers can do quite a lot; try working within the current standards, and functionality common between the browsers, as much as you can, while keeping in mind that adhering to standards isn't paying the bills, it's providing functionality, and a certain amount of style, that is.
As a direct answer to your question, about the pros and cons of vendor specific extensions:
Pros
Cons
As to whether you should use a JavaScript based approach or the CSS extension approach, that's a judgement you should make on a case by case basis. If you have been able to follow the principles of progressive enhancement, they are both fine to use. As long as it is not an essential feature of your site, or you find alternative ways of doing the same thing for all of the major browsers, I would say that CSS would be preferred over a JavaScript solution, as it will generally be smaller and faster loading.
Something to consider about validation is that while it's generally a good idea to ensure your HTML validates (though not always essential; see Google for example, where they consider minimizing download size to be more important than validating), validation failures due to vendor-specific properties in your CSS are less critical. In CSS, unknown properties are defined to just be ignored, so even if it doesn't validate because you use a vendor specific property, you know how it will behave in browsers that don't support that property; they will just ignore it. And if you've followed the approach of progressive enhancement, then your site should still work fine if those properties are ignored, meaning that there's no negative impact other than your site looking a little bit less nice.
呃...它们不能在其他浏览器上运行...？
Uhh... that they won't work on other browsers...?
遵守标准被认为是整个行业的最佳实践，因为它可以带来可预测性和互操作性。
这适用于所有行业，而不仅仅是网络内容的创建。
如果我们同意 W3C 是网络标准制定机构，我们就应该遵循他们制定的指导方针。
这意味着不依赖专有扩展，无论是谁引入它们。
Adherence to standards is considered best practice throughout industry because it leads to predictability and interoperability.
This applies across all industries, not just the creation of web content.
If we're going to agree that the W3C is the standards-making body for the Web, we should follow the guidelines they set down.
This means not relying on proprietary extensions, regardless of who introduces them.
除非您的网站严格且专门针对 Windows + IE 用户，并且您很乐意失去 Firefox 用户、Mac 用户、iPhone、黑莓或 Android 设备用户等的所有流量，否则使用任何专有 IE 扩展都是极其短视的。微软刚刚与欧盟达成协议，在不久的将来提供一个“浏览器调色板”供用户选择默认浏览器，因此可以想象，坚持使用 IE 作为默认或唯一浏览器的 Windows 用户比例可能会在未来几年内下降。未来。
使用 Firefox 的专有扩展几乎同样是短视的 - 您将很难说服所有访问者为您的网站切换到 FF（从 IE、Safari 或他们喜欢的任何其他浏览器），而且，尽管支持的设备范围很广。虽然您可以安装 FF 的范围比可以安装 IE 的范围更广，但您仍然会切断 iPhone 和 Android 等设备的市场，而这部分市场正在不断增长比“传统 PC”更快。
Unless your site strictly and exclusively targets Windows + IE users, and you're happy to lose all traffic from Firefox users, Mac ones, ones with iPhones or Blackberries or Android devices, and so on, using any proprietary IE extensions is incredibly myopic. Microsoft just agreed with the EU to offer a "palette of browsers" for users' choice as default browser in the near future, so one can imagine that the percentage of Windows users sticking with IE as their default or only browser can likely decrease in the future.
Using proprietary extensions from Firefox is almost as myopic -- you'll have a hard time convincing all visitors to switch to FF for your site (from IE, Safari, or whatever else they prefer), and, although the range of devices on which you can install FF is broader than those on which you can install IE, you're still cutting off devices such as iPhones and Android, a segment of the market that's growing much faster than "traditional PCs".