嵌入式CSS hacks与单独的级联样式表

Question

我认为这不是流行的立场，但我更喜欢在样式表中嵌入*和_之类的hack，而不是使用单独的IE特定样式表。起初，我尝试了单独的样式表，但我发现让相同元素的样式跨越多个文件的范围维护起来很痛苦。在更改主样式表中的样式时，我在IE特定的样式表中也有一个相应的样式，这一点并不明显。通常情况下，这些样式的变化非常小，比如对填充的微小调整，以至于在每个浏览器中测试它的额外时间似乎过长，因此并不总是发生。

但是，如果黑客攻击只是直接包含在主样式表中，那么很明显IE6的样式也需要调整和测试。我可以听到有人说，你应该在所有支持的浏览器中测试每一个风格的变化，但在现实世界中，我发现这种立场是不现实的，我也没有看到团队中的所有开发人员都遵循它。

我知道包含hack会使你的CSS无法验证，但我发现我可以快速扫描验证结果并忽略有关这些hack的错误。在我看来，我更愿意花更多的工作来解释验证结果，而不是处理IE 6中不正确呈现的站点。我在其他地方也读到过，人们不会做hack或单独的样式表，而是调整/简化设计，以便它可以在所有浏览器上工作。不幸的是，当开发人员不负责设计时，实现设计的开发人员并不总是有这种选择。另外，我花了很长时间才让小的填充问题在所有浏览器中都能正常工作，只是为了避免事后的黑客攻击，这似乎是相当浪费的。

我感兴趣的是其他人的想法和他们对这种范式的立场的理由。

Answer 1

我用CSS做了一些广泛的工作，几乎跨越了每个浏览器，无论是大项目还是小项目。虽然你可能编写的任何类型的代码都有美感的吸引力，但我认为更大的关注点是maintainability...and这适用于CSS和任何其他类型的代码。

虽然将你的hack和其他css“修复”组织到单独的文件中，这些文件通过条件逻辑加载是很好的，但从一个抽象的perspective...it实际上会造成维护上的麻烦。

根据我的经验，最好的办法是让你的黑客使用他们为任何给定的浏览器所修复的基本CSS。这使得CSS将你UI中的一些特定元素放在一个地方，这使得CSS 的管理变得非常容易，并且也明确了未来可能(或可能)适合浏览器css bug的修复应该放在哪里。

除了将你的hack放在它们相关的基本css之后，你还应该确保一个给定的hack修复了什么，以及hack支持的浏览器，并带有注释。我在一些大型项目中工作过，这些项目以高级方式广泛使用了CSS，但我们仍然必须支持IE6。长期以来，我和我的团队(顺便说一句，他们都是C# developers...at这个特殊的工作开发人员不仅编码，而且根据我们的图形设计师创建的UI样机做所有的UI实现)了解到，你实际上可以使用CSS来正确地设计几乎任何网站的样式，而不需要hack(这可能很困难，并且需要一些关于CSS works...but的广泛知识，如果没有hacks...just聪明/正确使用有效的CSS，它可以解决IE和Firefox中的几乎每一个bug )。

然而，在我的团队学习足够多的CSS知识来实现这一目标之前，我们已经有了更多的黑客攻击。将我们的hack与他们修复的基本css分组在一起，并为每个hack加上一个原因和hack所支持的浏览器，这对保持我们庞大的CSS文件的可维护性有很大的帮助。这不仅有助于改进maintainability...but，因为你学习了更多关于CSS的知识，并找到了避免黑客攻击的方法……当你修复现有的CSS以使用你的新技巧时，你可以一点一点地删除它们。因为你的hack就在你改进的CSS的旁边，所以很容易摆脱不再需要的hack。

Answer 2

这些都是HACKS，不是条件句。

不要误会我的意思，我也是这样做的:\有时它是基于案例的场景。如果你在处理大型网站时使用条件句。

如果你在做一些废话，你并不关心使用hacks。

区别如下：

HACKS暂时工作，直到有人修复它们，他们可能不会有条件-保证工作

Answer 3

我使用条件注释将页面包装在带有IE的DIVs中，目标是正确的IE版本，就像描述的here一样。

这更容易维护(就像你说的那样)，保持你的css有效(不会忽略错误)，并且比hacks更稳定……