这种可能性非常低，据我所知，没有人认真讨论过它。 我认为这可能会引发有趣的讨论和调查
您是否希望所有浏览器都有条件注释？
IE 已经有了它们，我们当然 使用它们。 如果我们也能做这样的事情呢？
<!--[if Fx 3.6]>
<link rel="stylesheet" href="firefox-v3.6.css">
<![endif]-->
<!--[if iOS]>
<link rel="stylesheet" href="iphone.css">
<![endif]-->一方面，这完全是不可扩展的，是对网络标准的打脸，将我们拉回到 10 年前。
另一方面，这是一个解决现实世界问题的直接解决方案。
调查在侧边栏中。 RSS 阅读器需要跳转到投票。
我认为这样做不好...
但如果能有这样的功能会很好：如果您支持它 => 那就做那个和那个，否则就做这个
您是指 Modernizr 吗？ http://www.modernizr.com
我认为他指的是“无需使用 JavaScript” :)
…并且 Modernizr 是功能检测，而不是浏览器特定的。
@Chris 是的，但测试功能比测试浏览器好得多，当然。
这就是这里正在进行的辩论的一部分 =)
通常功能检测更好，但有些情况下只有浏览器检测是唯一的方法。 例如，webkit 支持尺寸的百分比，但您不想在布局中使用它们，因为它们会错误地舍入小数像素，导致页面右侧出现几个像素的间隙，具体取决于列数。 功能检测无法区分 webkit 的错误版本和 mozilla 的近乎完美的实现。
然而，在 CSS 中，有一种方法可以使用供应商前缀进行浏览器检测。 我最近在禁用 webkit 中的一些大型盒子阴影时做到了这一点，因为它们会导致延迟。 由于没有内嵌盒子阴影，背景看起来太亮了，所以我添加了
针对 Webkit 的 hack：Chrome 和 Safari 的过滤器 2010 年 4 月 21 日
归档于：浏览器、CSS（包括 hack）— Estelle Weyl @ 下午 7:39
要仅针对 webkit（包括 Google 和 Safari），将您只想用于针对 Webkit 的所有 CSS 包含在以下 @media 块中
@media screen and (-webkit-min-device-pixel-ratio:0) {
.thing-with-box-shadow {
background: /* 更深的颜色 */;
}
}
有类似的针对 mozilla* 的 hack，当然还有针对 IE 的条件注释/星号 hack/下划线 hack。 没有什么好的方法适用于 opera（目前有一个有效的方法，但它依赖于 opera 在没有供应商前缀的情况下实现的东西，而这还没有在任何其他引擎中实现）。 我没有想出这些，我是从 这里 找到的，并一直将它们用于原型设计。
*仅针对 mozilla 的方法是
@-moz-document url-prefix() {
/* 仅 mozilla 样式在此处 */
}
现在，如果在 css 和 html 中都能够使用媒体查询进行浏览器和功能检测会很棒。
@adrusi
这是一个非常有用的技巧~
@media screen and (-webkit-min-device-pixel-ratio:0) .selector{ } }
和
@-moz-document url-prefix() { .selector { } }
非常感谢！
它并不完全是无 JavaScript 的，但您可能想查看 css 浏览器选择器。 它具有极其轻量级的优点，并且不需要多个 css 文件。
http://rafael.adm.br/css_browser_selector/
这不是一个好主意。 网页开发不应修复浏览器兼容性问题。 重点应该是开发新的令人兴奋的服务。
没错，但条件注释仍然非常有用。
如果所有浏览器都坚持标准，岂不是更好吗？
我同意。 他们只需要在开发浏览器时使用相同的标准，这并不难。
我个人一直对“标准高于一切”的思维方式感到困惑。 标准是，并且永远是，一个滞后指标。 它们是对过去知识的提炼，而不是对当前思维的反映。
想象一下最糟糕的情况，没有浏览器支持任何类型的标准。 我们将不得不为每个不同的浏览器从头开始创建网页。 我们的工作可能会困难 20 倍？ 更不用说正确做的人寥寥无几了。
谁会受苦？ 制作网站的人，付钱让这些人制作网站的人，以及使用这些网站的人。
@kevdog，你说得完全正确。 标准是滞后指标。 但是，如果浏览器不支持标准，那么这些标准就落后于行业现状。 我更愿意看到具有远见卓识的未来寻求浏览器实施更多渐进式增强，但首先，我们必须建立基础，即标准，然后才能进入创造力的领域。 更进一步，如果所有浏览器都开始制定自己的规则，我们该如何为此编码？ 我们是否忽略浏览器 A 和 B，因为 C 具有我们喜欢的更多功能？ 我们是否为 C 编码并希望 A 和 B 赶上来？ 或者我们是否找到一个中间立场，为所有浏览器编码，以便一切都统一且与平台无关？ 我会选择最后一个选项，这难道不是回到“标准”功能，为“标准”提供给每个浏览器的功能编码吗？
我同意浏览器应该支持标准，但这并不意味着它们不能添加额外的功能，只要这些功能不与标准冲突。 渐进式增强？
当然，如果所有浏览器都能以一致的方式支持大多数或所有标准，那将是理想的，但这什么时候才能实现呢？
同一个问题
我喜欢这样。 几周前我在 Chrome 上遇到了很多问题，我真希望有它。 Chrome 在不同的平台上呈现不同，即使是在同一个版本中也是如此。 然后它在不同版本之间呈现也不同！ 我最近花在调试 Chrome 中的 css 问题上的时间比我在 IE 上花的时间还要多，这太糟糕了。
我认为这是我听过的最糟糕的想法之一。 您指出 IE 拥有它们，我们当然使用它们，但为什么呢？ 因为 IE 在网络标准和盒子模型方面搞得一团糟，我们需要通过针对它们的特殊情况来使一切变得更难。
我相信，如果每个浏览器都有自己的条件语句，我们将鼓励 IE6 错误再次发生。
浏览器应该努力让我们的生活更轻松。 开发人员不应该额外工作，这样每个浏览器都可以随心所欲地做任何事情！
至少，这是我的意见。
问候，CSS tricksters 同志们。
PHP 可以做到这一点...
实际上，PHP 认为它可以做到，但它不能可靠地做到。
请参阅 Chris 关于为什么 浏览器检测不好 的文章。
应该是“on one hand”，而不是“one one hand”。
我认为这是一个很困难的话题，虽然能够轻松地针对特定浏览器会很棒，但同时也可能会让人变得懒惰，代码也可能更难更新。
例如，如果你为不同的浏览器准备了不同的样式表，那么在添加新内容时，你需要更新每个文件。
此外，如果你使用良好有效的代码，许多浏览器兼容性问题就可以解决。我无法数清有多少次，在任何 IE 版本中都无法正常工作的东西，只需添加一个简单的“float left”或“float right”就可以解决。
我相信，除非你的代码非常复杂，否则你不应该使用任何条件注释。
我完全同意，在所有浏览器中实现 Web 标准是为我们的 Web 项目建立一致且可靠基础的最佳方式。
但是，你不能否认，在未来的某个时刻，我们将会遇到所有浏览器都以相同的方式渲染所有内容的情况。
因此，虽然很多人会使用这些功能来做错事，但我希望使用它们来消除浏览器错误（是的，我知道你不相信，但即使是 Safari、Chrome 和 FF 也以非标准的方式做事，或者以不同的方式实现标准）。
关于这件事，我同意“不是功能破坏了 Web 标准，而是人”；）
那些会滥用这些东西的人也会使用 CSS-Hacks 和其他“黑暗面”的东西！
干杯 Sascha
只有 IE 如此糟糕，以至于需要这样的东西。其他浏览器有为此目的的供应商扩展。如果这是一个错误，它将被修复。这从各个方面来说都是一个糟糕的主意。
虽然我认为条件注释不是必需的，并且更希望看到浏览器遵循 Web 标准，但更好的方法是实现一个标准，例如使用媒体查询——类似这样
我对此持不同的看法，与其将其用于兼容性修复，为什么我们不能用它来为其他浏览器提供不同的东西呢？例如（我可以有一个网站推荐不同的浏览器）（如果是 Firefox，推荐除 Firefox 之外的所有内容）。
为什么不通过在 HTML 标签中添加一个特定于浏览器的类或 ID 来将其保存在一个 CSS 文件中，而不是使用单独的文件呢？
F.I.
在你的 CSS 中，你可以用以下方式为 IE6 设置样式
.ie6 .div.yourclass {
style: attr;
}
我理解所有反对意见，原则上我也同意。
我不在乎对标准的解释有多么笨拙，我想要的是相同的解释，这样一张漂亮的 CSS 列表就能完成工作。
但我们还没有。在拥有它之前，有条件地破解不同样式表的能力是我们控制设计以抵御浏览器设计者愚蠢行为的少数工具之一。是的，它很丑。是的，它并非完全面向未来。是的，我可以想到许多更好的方法来做到这一点（例如，样式表中的浏览器检测条件，这样你就可以只使用一个样式表并加载相关部分，并且只需要更新一个样式表），但这是一个可行的解决方案。
恕我直言，我认为不应该存在条件标签，因为我认为总有一天我们会使用相同的代码用于不同的平台，页面样式会适应不同的媒体。如果能够以一种方式编写代码，使其能够适应旧的手机、台式机或印刷书籍，那不是很好吗？条件标签是特定于浏览器品牌，而不是特定于媒体的，因此我认为应该努力消除使用它们的必要性。
可能不是一个好主意……围绕不一致性进行开发很有趣；）
此外，我发现除了 IE6 之外，我很少使用条件注释，而且那个家伙现在几乎不会引起我的注意。我发现，越来越多地，我只需要在 IE7 中进行一些快速修复，因为有时我不太关心 5% 或 6% 的访客看到的东西看起来足够好，并且也能正常工作。至于我的 HTML 标签上的 IE8 类，它已经很久没有使用过了。
Firefox 3.6、IE8 都足够好——即使是 IE7 在大多数情况下也足够好。给我 PNG 透明度、伪元素、属性选择器，世界就是我的：IE7 可以做到（或多或少——足够好）。
你说“IE 已经有了它们，我们当然也在使用它们”。我认为你在诡辩……有了 Firefox/Webkit，我们正在做一些 2 或 3 年前我们甚至想都不敢想的事情。我们实际上并不“需要”这些功能。我们只是无法抗拒使用尽可能多的功能——我第一个这样做：没有恶意。条件注释通过让我们能够在不担心那些无法理解的人的情况下变得强大，让我们的工作变得更加有趣。过分依赖它们是不专业的。
如果 Firefox 2 或 Safari 1 仍然存在，我们可能需要使用特定于浏览器/版本的条件注释——也就是说，如果我们想被世界上几乎所有人崇拜的话。幸运的是，这些浏览器都不存在了。不过，Firefox 3.6 仍然存在，但就在两个小时前，它是世界上最好的东西。现在 Firefox 4 即将发布，我们已经想要能够专门针对它了吗？说真的？
对于高端的装备，即使面对现实世界中的实际问题，难道浏览器前缀、Modernizr/Yepnope 化的逐步增强方法不是最好的方法吗？
现在，关于那个 iOS 条件注释：它肯定派得上用场，但媒体查询也很方便。Modernizr/Yepnope 也是如此。不得不使用它们并不像是一种负担，而是一种构建伟大作品的机会。
如果我们抱怨 JavaScript：现在，谁还会在这些天禁用 JavaScript，尤其是在他们的 iPhone 上（即使是可行的吗）？！我们可能只谈论你访客中百分之一的百分之一：让他们见鬼去吧，这些人知道他们在做什么。如果你真的想要针对 iOS……好吧，我知道我在说废话，但是：可能有一个应用程序可以做到这一点。
我认为这不是一个好主意。使用标准，不要变得懒惰！我看到很多人都使用条件样式来修复糟糕的标记，而不是寻找真正的问题。
我认为我们需要它们，不仅仅是因为我们可以“修复”浏览器破坏的东西。
这也是针对特定浏览器/用户的更好方法。
如果我有一个关于浏览器更新的博客，我可能想针对 Firefox 3 用户，并通知他有一个更新的版本可用。
IE 用户可能已经拥有了版本 9，并且不想切换到 Firefox。与其烦扰 IE 用户，我还不如直接针对我想要的目标受众。
显然，这会很棒，也很有用。如果有人不喜欢，他可以不用它。一切取决于开发人员以及他们想要实现的目标。
如果有很多选项可供选择，那总是好的。
现在我很好奇，是否可以使用相同的技术来检测 MacOS/iOS 上的 Webkit，例如？
我认为浏览器必须在没有用户干预的情况下进行更新，这将迫使每个人使用最新的浏览器。
我们还需要抵制一些浏览器，因为每年都会诞生一个新的浏览器。
我的英语不好，哈哈。
谢谢
在我工作的地方，我们可以通过 CSS 轻松访问 IE 条件注释（#ie #content），我看到开发人员经常滥用它，而不是找出问题所在。他们会直接添加一个条件注释，然后就算完事了。这很可能会让我们变得更加懒惰。但另一方面，的确有一些你无法绕开的情况，在这种情况下它会很有用。
我担心在 CSS 中使用供应商前缀有可能随着我们开始转向更新的浏览器而失控。我认为添加这样的东西可能会加剧这种情况。
不过，对于为移动设备编码来说，它可能非常有用。
我想我还没想好。
我主要使用条件注释来加载 IE 样式表（以及 shiv），但通常是因为 IE 在布局方面很糟糕。
然而，随着供应商前缀的普及，我认为这对保持主样式表中没有 hack 来说是一个很好的补充。你的主 CSS 文件可以包含所有正常的 CSS 语法，例如“border-radius: 8px”，而你的 fx.css 可以包含“-moz-border-radius: 8px”。
然后，当 Mozilla 支持真正的 CSS3 属性时，你可以直接删除条件注释并删除该文件，而无需在主 CSS 文件中查找所有供应商前缀。这有利于可维护性，可以防止不同的浏览器加载不适用于它们的 CSS 规则（Chrome 仍然可以看到 -moz 规则），并且可以更容易地验证你的 CSS。
乍一看，这对于一些人来说可能是个好主意，但我看到的最大问题是，你会有多个样式表，每个浏览器一个？当你考虑维护它们的时候，这似乎是个糟糕的主意。
我只需使用两个样式表，一个主样式表文件和一个在条件注释中的 IE 样式表文件，就可以获得非常好的跨浏览器支持。
我的主要样式表适用于所有现代浏览器，我使用我的 IE 条件样式表来针对所有 IE 浏览器，然后在需要时使用该文件中的特定 IE 6、IE 7、IE 8 CSS 技巧来针对每个版本的 IE。
嗯，我绝对不喜欢这个主意。
如果浏览器遵循标准会好得多。
这是一个糟糕的主意；主要是因为它是对一个 hack 的 hack。微软创建的条件“注释”包含，说实话，让网页开发者能够修复微软浏览器中绝对明显的兼容性问题，我使用它们是因为别无选择，但任何称职的设计师/开发人员都应该能够开发出在“良好”浏览器上运行良好的设计，而不会出现任何问题。
我从来没有在心里咒骂过 Safari、FireFox、Chrome，甚至 Opera；另一方面，我多次希望 IE6 和 IE7 团队能发生爆炸性腹泻。
添加这种类型的“条件”样式表会造成比解决的问题更多的问题。如果我做“如果 FF3.6.4”，当 FireFox 4 发布时会发生什么？
我认为，担心我们旧的糟糕的 IE 不遵循标准已经足够令人烦恼了；为所有其他浏览器提供它们只会使问题激增。
大多数浏览器都有足够大的开发团队，我不明白为什么他们必须破坏标准来取悦所有人。我的意思是，他们可以做出很棒的功能，没错，但这并不意味着他们必须为了那个功能而让其他人的生活变得复杂。
软件开发并不那么难；也许在安全相关代码上，但不在*遵循标准*的流程部分。
所有浏览器都应该具有一些功能，如果它们不是最新的在线版本，就不会让他们运行！这样我们就可以停止担心人们使用的是什么版本的 IE、FF 或 Chrome。
喜欢所有像“我们不应该这样做！”、“只需遵循网页标准，你就会没事的！”、“为什么浏览器开发人员不能保证它们都能正常工作！？”这样的理想主义评论。
长大点，请意识到情况并非如此。这是现实世界，它需要现实世界的解决方案。
没有人说要为不同的浏览器创建完整的样式表——这只是为了像
“哦，那个菜单在 FF3.6 中向左移动了一点，让我们解决一下。”
我们需要在投票中添加另一个选项，称为“如果客户愿意为此付费”。
标准使开发网站更实惠。
（这是我经历过的最糟糕的可用性体验——难道验证这么难，非要把我踢出页面，让我丢失所有表单值吗？)
总之，虽然针对所有浏览器的条件语句很有诱惑力，但这是错误的道路。我认为这只会助长网页开发人员和浏览器开发人员的懒惰，是对网页标准的蔑视。
投票提供的选项太少，所以没有投票。
不过我会投赞成票，但不是针对所有浏览器。只有在 IE 和移动设备的条件标签的情况下，否则我们将最终为每个浏览器制作不同的样式表，那将是一个巨大的痛苦！
我认为它可以解决浏览器相关的问题，而不会给服务器带来过载请求，就像我们对 9 之前的 IE 版本所做的那样，用其他浏览器这样做会很棒。
随着应用程序开发变得越来越复杂，我认为应该更加重视可用性和以用户为中心的設計，以及良好的代码、表单、行动号召等。
网页设计/开发领域中要处理的事情太多，修复不同浏览器中中断的功能只会增加各方的挫败感。IE 是一个特例，直到 MS 决定拥有一款真正与其他浏览器良好兼容的浏览器，我认为所有其他浏览器都需要变得标准化，或者尽可能接近标准化。当然，这里或那里会有一些小的差异，但我认为应该将压力放在统一的标准上，以提高应用程序在我看来，可用性和有效性。当然，这会让我的工作更愉快。;)
我认为这是一个糟糕的主意。如果浏览器制造商能够以正确的方式做事，并跟上当今的标准，我们就不会需要任何条件注释！
这对所有浏览器来说都是个糟糕的主意。但对 iOS 和 Android 来说会很棒。你说你在使用 iOS 或 Android 吗？好吧，给你，用我的 iOS/Android CSS。（所以不是专门针对那个浏览器，更多的是针对平台。）
一位聪明的开发者曾经告诉我，如果你很优秀，并且知道自己在做什么——你永远不应该使用条件语句来做除了 IE6 之外的任何事情，即使那样也值得怀疑。
好吧，今天没有必要这样做。首先，当然，**网页标准**是为了某种目的而存在的。其次，你可以很容易地编写一个 JavaScript 来为你完成这些，而且速度仍然很快。
实际上仍然不是一个坏主意，并且有一些 JavaScript 实现可以实现完全相同的功能，例如 yepnope.js 或 Modernizr，甚至具有更细粒度的控制（检测浏览器是否具有阴影、地理位置等）。
好吧，今天没有必要这样做。首先，当然，**网页标准**是为了某种目的而存在的。其次，你可以很容易地编写一个 JavaScript 来为你完成这些，而且速度仍然很快。
实际上仍然不是一个坏主意，并且有一些 JavaScript 实现可以实现完全相同的功能，例如 yepnope.js 或 Modernizr，甚至具有更细粒度的控制（检测浏览器是否具有阴影、地理位置等）……即使是手机现在也有 JavaScript。
我宁愿看到浏览器 CSS 媒体查询，例如``，这使得事情看起来比条件注释少了很多 hack，但也允许我们将这些条件样式规则内联到一个已经下载的样式表中，如果我们愿意的话（就像你目前可以使用 CSS @media 规则对打印专用样式规则所做的那样）。
我的意见是...
我选择标准：理想情况下，只有在与早期版本兼容时才需要像浏览器定位这样的解决方法，与供应商无关。
其他浏览器不需要条件标签。当我开发时，我让它在 Firefox 中运行。对于 IE 中的任何奇怪的事情，我使用条件注释，对于 Safari/Chrome，它可以正常工作。
完美世界：条件注释是魔鬼！
在现实世界中：我支持所有浏览器中的条件注释。我一直有点惊讶它们还没有。它们都有愚蠢的小浏览器特定 CSS 习惯用法，还是这是另一个讨论？
此外，更多的条件注释意味着开发人员需要做更多工作，并且他们积累的知识更加深奥。哇哦！
我希望所有浏览器都只有一个 CSS。使用条件注释添加浏览器特定 CSS 文件会让网页开发者头疼。
我会说，是的，要针对特定的主要浏览器版本，而不是 3.6。本周我花了大量时间修改 jQuery 选项卡，以确保它们在 IE7、8 和 9 中正常运行。
另一方面，我最初很喜欢 Chrome 自动更新，而不是像 Internet Explorer 那样强制用户下载更新。然而，我注意到其中一些更新正在破坏网络应用程序，除非我使用一个非常 beta 的浏览器版本进行测试，否则我没有足够的时间在用户发现这些错误之前捕捉到它们。
我认为应该保留在服务器端。我想投票，但这个网站的移动版本没有侧边栏内容？
如果我们有了这个，每个浏览器都会做他们想做的事情，而不是他们应该做的事情，这意味着我们的工作量会增加，因为市场上有许多浏览器品牌和版本。
用户需要知道他们必须更新浏览器，浏览器供应商（制造商）需要尽可能地遵守标准（并努力在每个新版本中做得更好），而我们则需要突破极限，测试事物并在事物不按预期工作时大声喊叫（或更有效地开发解决他们错误的方法）。
我宁愿所有浏览器都变得符合标准……
我在投票中投了“否”票，但如果你真的需要类似的功能，CSS 浏览器选择器 是一种有趣的选择。
我认为这不是一个好主意，不仅仅是因为已经提到的原因。我最担心的是“糟糕”的设计师会用像这样的方式来做“简单”的事情
– 浏览器 X：显示网站
– 其他浏览器：显示一个页面，说“如果你想看到这个网站，请下载浏览器 X”
…这会将一个看似好主意变成一个可访问性噩梦。还记得“浏览器战争”时期所有“针对……”优化的网站吗……
另一方面，我们都可以使用的是“计算样式”（即浏览器默认值）的更多一致性。这将使 CSS 重置变得过时，并使 CSS 样式变得不那么令人沮丧。我认为这应该是 Web 标准的基础……
当然，处理这些标准的方式更加一致也是很好的。我梦想着有一天，浏览器会代表它们提供的功能，而不是代表它们使用起来有多令人头疼……
我们都同意浏览器嗅探很糟糕，而且并不简单，它使网站更难维护。我们需要的功能测试 à la Modernizr。
就 CSS 而言，我认为条件注释可能有助于定位特定浏览器，我希望我们能够使用 @media 查询来做到这一点（-moz-VERSION、-webkit-VERSION、-o-VERSION、-ms-VERSION 等）。
目前，如果我真的需要检测浏览器，我只使用 https://github.com/garetjax/phpbrowscap
我不使用这些标签。在我看来，它们真的很烦人，而且让代码看起来很乱。我本人从未真正需要使用它们。大多数情况下，以正确且干净的方式编码，事物会在浏览器之间“对齐”。
如果事情不按计划进行，我更喜欢使用 CSS 技巧而不是这些条件标签来包含一个全新的电子表格。
虽然如果你想为移动网站（比如 iPhone）使用一个完全独立的样式表，我能够理解这种需求。
可悲的现实是。在只有一个浏览器渲染引擎之前，特定于浏览器的技巧是必要的。不管你喜不喜欢，如果你想设计网站，你就必须使用它们。
你不能强迫所有浏览器都符合 Web 标准（IE 就是一个很好的例子），你也不能强迫人们使用特定浏览器。
在一个幻想的世界里，一切都会完美运行。我们不必担心这个问题。不幸的是，我们必须为现实世界编码。在现实世界中，并非所有事情都能完美运行，而使用特定于浏览器的技巧是唯一的选择。
与其争论我们是否应该使用它们，不如想出更好的使用它们的方法。
你提出这个话题很危险。
有些时候，我希望有针对特定版本的 Safari 或 Firefox 的条件标签，但是我似乎总是能找到某种解决方法。这显然会让浏览器测试更顺利，但可能会让人们忽视应该在他们的代码中修复的问题。
我绝对、完全、百分之百地反对它们。我认为没有理由在 jQuery/JavaScript 已经使确定这些内容以及更多内容变得如此容易的情况下倒退一步。
从理论上来说，我会欢迎这个，但随后我认为事情会失控。如果所有浏览器都有条件语句，它们都不用担心标准合规性，因为你可以直接针对它们。它们都会自己做自己的事情。最终，这会导致浏览器以如此不同的方式做事，以至于我们必须做的工作才能让网站在不同浏览器上以相同的方式渲染将变得非常荒谬。从短期来看，这将是很棒的，但从长远来看，我认为这将适得其反。坚持标准，这是我的观点。
拥有条件注释将是一件好事，但如果所有浏览器都能以标准的方式以相同的方式工作，那就更好了。
即使在 IE 的情况下，我们也必须使用条件语句，因为 IE 缺乏兼容性，如果它能够像其他人一样工作，那该怎么办。
对于像 iOS 样式表和轻松的浏览器检测这样的事情，它将非常有用，但并非必不可少。IE 有条件注释的原因主要是它不符合标准。
嗯，我喜欢保罗·爱尔兰和公司在 HTML5 Boilerplate 中使用条件注释的方式。但我认为有必要像 Modernizr 那样测试功能，而不是测试特定的浏览器版本。
打扰一下，我可以知道这个博客中的代码插件吗？
嘿，这个网站是用 CSS 完成的吗？:)
是的，我想要它们。
不，我不希望人们知道它们。
我希望它们被实现，并且没有人使用它们（因为他们不知道它们的存在），直到它能够解决一些非常丑陋的问题。
然后，少数精选的人，比如克里斯·科伊尔，将从浏览器制造商那里获得该信息，并且他们只会在紧急情况下发布它。
听起来对我来说是个好主意：)
我更喜欢为浏览器添加 body 或 html 类，然后使用这些类进行样式化。
[如果世界是完美的]
我的投票 = 否
[如果所有浏览器都像 IE 一样糟糕]
我的投票 = 是
我的条件。在这种情况下，我是一个非常坚定的“也许”。
当然，为什么不呢？最坏的情况是没有人使用它。为免费解决方案可能性点赞！
（抱歉发了 2 次）
@adruzi 也许那些额外的非标准功能会变得越来越有用，越来越需要，把我们带回到第一步。
我真的很不喜欢条件注释——我不想要那种垃圾在我的标记中。
如果有的话，我更愿意让每个浏览器将它的名称/版本号/操作系统作为 html 元素上的 agent="" 属性的值添加。
好吧，我当然更喜欢它而不是使用 js，尤其是 iOS 的那个。
我宁愿将 CSS 技巧保留在 CSS 中
http://alastairc.ac/2006/05/conditional-comments-in-css/
但是，那也同样不可能发生！
这似乎可能变成一场噩梦。如果我们能够用条件注释来定位所有内容，我们会变得懒惰，不去理解我们兼容性问题背后的原因，也找不到合法的解决方法。
如果我使用这种功能，我只会用它来区分台式机和移动设备等。
原因是，虽然媒体查询很好，但总的来说，所有资源仍然会被下载，即使它们没有在移动设备上使用，而移动设备的总带宽非常宝贵，额外的 HTTP 请求也很昂贵。
所以，如果我能可靠地使用条件注释来使用单独的 mobile.css 和 standard.css 文件，我会觉得这是可以接受的。
尽管我确实在偶尔的 HTML5 shiv 中使用特定于 IE 的条件注释，具体取决于项目的需要。