Question

我最近开始使用//来“评论”单行CSS代码。我明白我实际上并没有评论这条线;我只是打破它（我应该使用/* ... */），但它具有相同的效果。然后该行由;终止，以下代码正常工作。

我可以将其删除，但我常常不想这样做，以防万一我想稍后再把它放回去，或者看看我回来时一直在使用它。

示例：

li{
    float:left;
    //list-style-type:none;
    text-indent:0px;
}

我可以逃脱这个，还是可能会给我带来麻烦？

Answer 1

我看到有很多人抱怨这个，因为这是一个较老的问题，可能有很多人在阅读它，想知道它是否仍然是真的，或者是否有第一个标准地点。请允许我清理空气。以下是严格的CSS评论政策的核心原因：

＃1这不是标准

至少从CSS 2.1开始标准化，评论仅限于/*和*/。虽然有些浏览器容忍//，但它们并不应该，并且距离某人说只有一英寸，而且＃34;那是非标准的＆＃34;或者＆＃34;嘿！这是非标准的，修复它！＆＃34 ;;然后猜猜你的CSS代码，WAS正在运行，现在对于成千上万的人来说并没有（并且可能已经没有为数百个人工作）。我将添加被允许但仅在（并且我的意思是）仅当它们出现在HTML文档中而不是在.css源文件中时。如果您的浏览器太旧而无法跳过<style>标记，那么10年前可能需要一段新浏览器。即使Lynx和其他文本浏览器都知道不读它们，因此将其注释只在非常孤立的情况下才有用，即硬件和软件在当前工作状态下是内陆的。

＃2它不是（非常）跨平台友好

单行评论从//一行开始，由＆＃39;换行符＆＃39;终止。这不是跨平台的标准化角色。更糟糕的是，有些人可能有一个字符用于换行符，或者2 ...当这些平台混合在一起时，换行符可能会丢失，并且会出现终结符......并且您的部分或全部代码现在被注释掉了不应该是，你不必是一个天才，知道这可能会产生什么后果，特别是如果你只通过CSS控制你网站的功能，很多人都这样做。

＃3标准对所有人友好且统一

无论架构，操作系统等如何，/*和*/分隔符始终与每台计算机上的字符相同。

＃4换行符是空格

最后一个原因（是的，还有一个），换行符（在CSS和许多其他语言中）被认为是空格，而*/不是空格吗？如果你在这一点上考虑它，应该很清楚你不应该使用空格来终止注释，特别是因为空格是并且可以被许多HTML / CSS解析器剥离，或者在你甚至不知道它的情况下重新格式化。

＃5 CSS！= C / C ++

现在，如果你要飞出座位并对我大吼大叫＆＃34;嘿，但C ++ ......＆＃34;，请记住那些编译器和IDE有大量新行检查和检测内置于它们中所以他们可以接受它。除非被问到，否则大多数编译器都不会重新格式化您的代码，并且许多IDE通常会询问您的文档正在使用哪种新行，如果它自己无法猜测的话。如果我们每次加载最终用户的CSS页面都这样做，想象一下它会试图绕过的噩梦。此外，C / C ++代码在运行时不会被解析并被编译，因此在大多数情况下，用户永远不会首先获得有问题的文档。整个世界并没有经常在数百个平台和许多操作系统以及数百万种不同的浏览器上查看源文件。评论在他们到达最终用户之前被删除。 CSS源代码适用于用户的浏览器，并且必须非常灵活，不知道另一方面是什么，所以需要注意的是它必须为最终用户拥有或做的任何事情做好准备，而不是开发人员所做的任何事情。或者有！

＃6不方便

不，不得不输入额外的*/非常烦人，但对此的责任主要归咎于不提供自动完成功能的CSS编辑软件开发人员。如果您使用专门的编辑器，可以开箱即用，那么您会发现它就像使用//一样简单。养成输入/**/然后退格2的习惯，它会帮助你不要忘记并让它变得更容易。更好的是，你可以设置一个热键来为你准备好这些热键。 Windows和Linux都有强大的工具来实现这一点（KDE非常适合）。

我希望这有助于每个人理解＆＃34;为什么＆＃34; ＆＃34; how＆＃34;背后，记住只是因为某些东西适合你，并不意味着它是标准，并总结：

是的，使用它是不好的做法，只要对双斜线说“不”!!! 如果您需要视觉辅助来提醒您这一重要事实，请将此图像刻录到您的脑海中（感谢那些没有更好的事情但只拍出这样的照片的人）：

No double slash

PS：如果你真的想要向那些制定/破坏CSS标准（W3C，肘部）的人抱怨，有人会开始讨论“不太重要”这个“不太重要”的问题。关键字是！但这不是这个问题的一部分，所以我不会进入它。

参考

W3C ： CSS 2.1工作草案：评论字符。
W3C ： CSS语法模块第3级：解析器到字符解释的铁路图。
Stack Overflow ：各种Stack Overflow文章与此主题几乎相同。
w3schools ： CSS 3语法标准（反过来引用W3C）。
sitepoint ： CSS语法注释＆＃34;不使用双斜杠＆＃34;。
mozilla | mdn ：轻松的CSS 3处理允许输入文件中的双斜杠。

Answer 2

首先：注释掉的代码是code smell，应该避免。我假设您使用的是Git之类的VCS，它可以为您处理历史代码。

但是如果你真的想以这种方式工作：你不知道未来和/或异国情调的浏览器将如何解释像//这样的非官方黑客，所以你最好坚持使用适当的符号：

li {
    float:left;
    text-indent:0px;
    /* list-style-type:none; */
}

Answer 3

我最近阅读了this article，其中阐述了CSS中单行评论的实践。

CSS允许您在时尚之后使用//。这不是一行评论，而是下一个构建评论。也就是说，无论何时使用//，下一个CSS构造 - 声明或阻止 - 都将被“注释掉”。

因此，在您的代码片段中，list-style-type:none是下一个CSS构造，它会被注释掉。

li {
    float:left;
    //list-style-type:none;
    text-indent:0px;
}

同样，在下面的代码片段中

//@keyframes foo {
  from, to { width: 500px; }
  50% { width: 400px; }
}
@keyframes bar {
  from, to { height: 500px; }
  50% { height: 400px; }
}

//将注释掉第一个@keyframes声明。

如果您尝试仅使用//将注释写入样式表，则必须小心 - 原始文本不是CSS构造，因此它将看过去并注释掉下一个构造你的页面。所以在下面的代码片段中

// Do some stuff.
.foo { animation: bar 1s infinite; }

这将注释掉.foo块。

您可以通过开头提到的链接文章获取更多信息。

Answer 4

According to the Working Draft，没有什么比单行评论更好了。

Answer 5

是的，我认为在当前状态下使用单行注释是不好的做法。

首先，如果您在团队环境中工作，那么代码可维护性/可读性至关重要，即使您单独工作，编写可维护代码仍然是一种良好的做法，否则会出现精神错乱。

当您开始使用单行注释时，可维护性和可读性都受到阻碍，编辑器中的语法高亮显示器不会突出显示您的注释，并且很难将注释与规则区分开来。

Comparison of single and multi-line comments

此外，单行和多行注释不是可以互换的，例如，如果不使用hack就不能使用原始文本注释，而只能注释构造//.foo {...}或规则{{1 }}

不可互换的实例：

.foo {//height:10px}

现在可以互换（由于空构造函数 hack ）：

ul.images {
    padding: 0;
    //static height value
    height: 270px;
    margin: 0 auto;
}
ul.images {
    padding: 0;
    /*static height value
    height: 270px;*/
    margin: 0 auto;
}

虽然使用构造函数ul.images { padding: 0; //static height value{}; height: 270px; margin: 0 auto; } ul.images { padding: 0; /*static height value*/ height: 270px; margin: 0 auto; }作为后缀将起作用，但IMO却无法使用它，因为您将使用更多字符;多行注释使用四个字符{};，而带有黑客的单行注释使用五个字符/**/

尚未提及的单行注释的最后一点是，Chrome开发人员工具将隐藏已注释掉的规则，而不是允许您切换它们。

Chrome开发者工具（多行评论）：

Enter image description here

Chrome开发者工具（单行注释）：

Enter image description here

一个好的用例，IMO，对于单行注释，当你需要注释掉整个构造函数时，这个构造函数很长（示例不会）。

评论整个构造函数

//{};

最后，如果您在开发期间尝试调试某些内容，我不会看到使用单行注释注释掉构造函数以消除错误的危害。如果你正在调试那么它将是暂时的。也就是说，我没有看到原始文本的任何用例，所以我绝对不会主张在那里使用它们。

Answer 6

我建议不要在不需要的时候注释掉这样的CSS。删除不需要的东西并将其提交到SVN或GIT存储库。让它完成它的工作，并为您记录历史。像这样的累积评论会让您的代码更难以阅读和理解。

Answer 7

我一直使用//来“注释”.css文件中的行。因为它绑定了Vim中的快捷方式，而且我总是忘记我正在编辑的内容。在JavaScript中，注释掉代码块，测试代码以及再次“注释”代码块（快捷方式，是）非常方便。

但是当我整理我的.css文件时，我使用以下构造来更轻松地将声明移入和移出范围：

.pin {
    /*
    position: absolute;
    background: url(buttons-3x3.png);
    background-color: red;
    */
    height:50px;
    width:150px;
    position: relative;
}


.shadow {
    margin-top: 25px;
    margin-left: 25px;
    margin-left: 60px;
    width:50px;
    height:50px;
    background: url(playground.png) -400px -100px;
    position: relative;
    position: absolute;
}

在.pin我可以删除一行并将其添加到注释区域，反之亦然。在.shadow中，我只是使用不同的值重新声明相同的属性。

这很痛苦。

!important

Answer 8

正如其他人所说，使用双斜线不符合标准，但如果真的想要使用它并且想要符合标准并且你安装了gcc，那么你可以运行你的CSS cpp -P删除CSS中的所有双斜杠和/ * ... * /注释。作为奖励，您可以使用宏，包含和条件，并且浏览器不会下载注释（次要性能提升）。

唯一的主要问题是使用cpp barfs的独立id标记（即#para { ... }）。解决方案是＃（到##）加倍并通过sed传递输出，如下所示：

cpp -P site.cssin | sed -e 's/^##/#/' >site.css

我确信有更好的面向CSS的预处理器，但这对我有用。

Answer 9

对于内联CSS评论，我使用：

.myDiv {
    @width:750px;  
}

或您想要的任何字符（即*@!ZZ）因此，属性变得未知，并且css无法读取。

Answer 10

HTML评论：

<!--........................-->
<!--  <input type="text" name="lastname">-->

JavaScript中的评论：

单行评论：

代码前面的两个斜杠＆＃34; //＆＃34;：

//document.write("Try this");

多行评论：

<script type="text/javascript">
    <!--

    /* document.write("try this!");

    document.write("try this"); */
    //-->

</script>

CSS中的注释代码：

/*
.tblemp {
color:red; }

*/

More details

Answer 11

只是添加一些更多信息并确认＆＃34;仅使用/ *评论＆＃34;规则。有权访问网站文件夹的客户只需自己选择使用以下方式注释掉一行：

//*  comment here   *//

实际上Chrome和Safari会忽略此行之后的任何内容;我称之为＆＃34; CSS杀手＆＃34;。

用//注释单行CSS是不好的做法？

11 个答案: