W3C规范中未包含使用特定于供应商的扩展的利弊是什么？ [英] What are pros and cons of using vendor-specific extesions not included in W3C specifications?

问题描述

我编辑了问题

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

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

IE具有3事情：

1. .htc文件支持（与javascript相同）


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


3. 仅某些IE xhtml 和 css
   属性

Web工具包和 Mozilla 也有一些

其他一些链接：

http：//webdesign.ab out.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？
示例：

1. 如果同一解决方案具有jquery代码和特定于供应商的CSS代码，我应该使用哪个？如果禁用了JS，则可以使用特定于供应商的CSS解决方案，但该页面无法通过W3C验证。如果我使用JS解决方案，则该页面将通过验证程序。一个例子就是制作一个圆角。

   
   



2. 如果由于使用供应商而未完全对W3C进行验证，那么从任何意义上说都会受到伤害。特定的属性？我是否应该尽量避免使用特定于供应商的东西，以获得良好的跨浏览器和平台兼容性，例如PC，MAC，iPhone和其他移动设备？

   
   



3. 如果为了通过W3C验证而在两者中都有解决方案，我应该在特定于供应商的CSS属性上选择JS解决方案吗？如果我每次都选择JS解决方案，则该网站将无法在移动浏览器上正常运行。如果W3C验证给供应商特定的扩展错误时，不理会它吗？

   
   

解决方案

在考虑供应商特定的扩展时，您应该尝试遵循的原则是渐进增强。基本思想是，您应该设计站点以使其服务于尽可能多的人。将其设计为可以在终端客户端上以纯HTML 3.2运行，而无需JavaScript，CSS或任何特定于供应商的扩展。

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

因此，您不应不必依赖这些特定于供应商的扩展，而是将它们用作增强功能。如果由于某种原因您确实依赖它们（如果您的产品在没有特定浏览器可用的扩展的情况下无法运行），那么可能值得使用它。但是在那种情况下，您的未来与该浏览器有着千丝万缕的联系。如果是顺带一提，则您 SOL 。如果最终只能在韩国使用，而您的产品是德语，而另一种浏览器是主要浏览器，那么您就是SOL。

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

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

总而言之，我想说，您应该随时为仅在单个浏览器中支持的页面添加效果。但是，除非您有充分的理由相信所有主要浏览器都将支持它们，否则您不应依赖这些。主流浏览器支持的HTML的当前状态可以做很多事情。尝试在当前标准和浏览器之间的通用功能之内，尽可能地工作，同时要记住，遵守标准并不会付钱，而是提供功能和一定数量的样式。 / p>

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

专业

• 访问功能可能会尽快普及


• 为客户提供更好的价值


• 您可以做一些非常有趣的事情


• 帮助鼓励其他浏览器的实现者以及从事标准工作的人，此功能是一个好主意

缺点

• 该功能可能会消失，并且永远不会消失即使在同一浏览器的更高版本中也会出现


• 如果您依赖于此类扩展程序，则可能会严重限制用户群


• 该功能可能会更改在发布之前sed，导致页面损坏，或某些很难发现的新嗅探模式。

关于您应该使用基于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 (same as javascript)
2. css expressions (also a form of javascript)
3. 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:

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

2. 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?

3. 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?

解决方案

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