使用特定于供应商的扩展（这些不包括在W3C规范中）有何利弊？ [英] What are pros and cons to use vendor-specific extesions , which are not included in W3C specifications?

问题描述

我编辑了我的问题

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

供应商特定的扩展可以用 - （破折号）或_
（下划线）开始
，通常后跟
缩写公司或
浏览器项目的扩展名是
专用于，fi -moz-用于Mozilla
浏览器，或者-webkit-用于基于WebKit
的浏览器。此供应商特定的
前缀后面是属性
名称。一个很好的例子是
-webkit-border-radius或-moz-border-radius。

IE有3件事情

1. .htc文件支持（类似于javascript）


2. 和css表达式（也是javascript的一种形式）


3. 和一些IE xhtml 和 css
   properties

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完全验证，如果i
   避免供应商特定的东西多
   尽可能获得好
   跨浏览器和平台
   兼容性（如PC，MAC，iPhone，
   其他手机）。




3. 我应该选择js解决方案超过
   供应商specfic css属性如果我有解决方案，以获得
   通过w3c验证？（但如果我将
   选择js解决方案每次，
   网站在移动
   浏览器上无法正常工作）如果w3c验证给供应商特定的扩展程序带来错误，是否可以离开？

解决方案

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

然后，添加样式和功能，使用不是所有浏览器都支持的更高级的标准，使用视觉媒体的设计，使用可能禁用的CSS和JavaScript，最后使用供应商特定的扩展，这完全不受其他浏览器支持。但是因为你首先开始设计给定一个公共的功能，每个人都支持，你不需要额外的功能从新的功能，为网站工作;它将继续在旧的浏览器中工作，具有旧功能，因为新功能是作为增强功能添加的，而不是作为您的网站工作所必需的功能。

不依赖这些供应商特定的扩展，而是使用它们作为增强。如果由于某种原因，您确实依赖它们，如果您的产品在特定浏览器上没有扩展程序时无法运行，则可能值得使用。但是在这种情况下，你的未来与那个浏览器是密不可分的。如果它落在路边，你 SOL 。如果只是在韩国使用，而你的产品是在德国，其他浏览器是主要的，再次，你是SOL。

现在，有在做出这些决定时可以选择不同种类的供应商特定的特征。有一些功能将始终特定于特定的供应商;在其他平台上不适用或已向标准机构提出并且整个方法已被拒绝的特征。这些功能是非常非常明智的使用。

标准轨道上还有其他功能。他们在一个当前的CSS 3草稿，他们实现在两三个不同的浏览器几乎兼容。这些功能是您可以开始依赖的功能，如果您的用户基础都支持他们，因为他们几乎肯定被大多数主要浏览器（大多数潜在用户使用）在未来。

因此，总而言之，您应该可以随意添加效果到您的网页，只有在单个浏览器中支持。但你不应该依赖这些，除非你有一个很好的理由相信，他们很快将被所有主要的浏览器支持。主要浏览器支持的HTML的当前状态可以做很多事情;尝试在当前标准中工作，以及浏览器之间的通用功能，尽可能多地，同时牢记，遵守标准不支付账单，它提供功能和一定的风格。 / p>

作为您问题的直接回答，关于供应商特定扩展的利弊：

为客户提供更好的价值

帮助鼓励其他浏览器的实施者和标准制定者，这个功能是个好主意

缺点

• 功能可能会消失，


• 如果您依赖这些扩展程序，可能会严重限制您的用户群。


• 此功能可能会更改显着地在释放之前，导致断页，或一些新的嗅探模式，是真的很难弄清楚。

至于是否使用基于JavaScript的方法或CSS扩展方法，这是一个判断，基础。如果你能够遵循逐步增强的原则，他们都可以使用。只要它不是您的网站的一个基本功能，或者您找到替所有主要浏览器做同样的事情的替代方法，我会说CSS比JavaScript解决方案更喜欢，因为它通常会更小，更快的加载。

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

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

1. .htc file support (it's same like javascript)
2. and css expressions (which is also a form of javascript)
3. and some IE only xhtml and css properties also

Web-kit and Mozilla also has some their own css properties.

and 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 for now or in future if we use non W3C standard things?

1. If i have a jquery solution and vendor specfic css both for a same solution then which should i use? using vendor specfic css solution will work if js is disabled but page will not validate in w3c validator and if i use js solution then page will be passed in validator.

   • for example like for making round corner

2. Will it hurt in any sense if site is not W3C fully validated due to using vendor specific things, Should i avoid vendor specfic things as much as possible to get good cross-browser and platform compatibility (like PC, MAC, iPhone, other mobiles.?

3. Should i choose js solution over vendor specfic css properties if i have solution in both to get pass w3c validation? (but if i will choose js solution every time then site will not work well on mobile browsers) Is it ok to leave if w3c validation giving error for vendor specific extensions?

解决方案

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

• Get access to features that may become widespread sooner
• Provide better value to your customers
• You can do really cool, fun stuff
• Help encourage implementers of other browsers, and people working on standards, that this feature is a good idea

Cons

• The feature may go away, and never turn up even in later versions of the same browser
• If you rely on such extensions, you may limit your user base severely
• The feature may change significantly before released, leading to broken pages, or some new sniffing mode that is really hard to figure out.

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.

这篇关于使用特定于供应商的扩展（这些不包括在W3C规范中）有何利弊？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！