我应该对伪元素使用单冒号还是双冒号?


108

由于IE7和IE8不支持伪元素(例如::after::first-letter)的双冒号表示法,并且由于现代浏览器支持:after向后兼容的单冒号(例如),我应仅使用单冒号表示法以及何时使用IE8的市场份额下降到可以忽略的水平,然后回去查找/替换我的代码库?还是我都应该同时包括:

.foo:after,
.foo::after { /*styles*/ }

如果我关心IE8用户(可怜的朋友),单独使用double似乎很愚蠢。

Answers:


71

请勿同时使用逗号和逗号。兼容CSS 2.1(不支持CSS3)的用户代理将忽略整个规则:

当用户代理无法解析选择器时(即,它不是有效的CSS 2.1),它必须忽略选择器以及随后的声明块(如果有)。

CSS 2.1为选择器中的逗号(,)赋予了特殊含义。但是,由于不知道逗号是否会在将来的CSS更新中获得其他含义,因此即使选择器的其余部分在CSS 2.1中看起来很合理,如果选择器中的任何地方出现错误,也应忽略整个语句。

http://www.w3.org/TR/CSS2/syndata.html#rule-sets

您可以使用

.foo:after { /*styles*/ }
.foo::after { /*styles*/ }

另一方面,这比必要的更为冗长。现在,您可以使用单冒号表示法。


7
感谢您添加逗号和忽略信息。那可能会让我(也许还有其他人)挠头。当使用的99%浏览器支持双冒号表示法时,这似乎是最好的选择(因为没有人会放弃单冒号支持并破坏了网络,因此以后查找/根本没有意义)此时替换旧代码)。
jinglesthula 2012年

2
这不是前进的道路。如果人们不再顺应旧的,残破的和过时的浏览器,浏览器的进度将被强制加快。
Gershom,2015年

2
@ Gershom Maes:不幸的是,这不是您要说的。我认为大部分开发人员都希望这样做,但是那不会发生。
BoltClock

我们可以梦想的@Gershom Maes
James Cushing

1
我认为必须注意,保持重复的样式可能会出现问题。如下所述,重复的代码喜欢发散。大多数开发人员可能不得不被它咬伤几次才能发誓:)
jinglesthula

62

CSS3选择器REC

当前文档引入了::符号,以便在伪类和伪元素之间建立区别。
为了与现有样式表兼容,用户代理还必须接受CSS级别1和2(即:first-line,:first-letter,:before和:after)中引入的伪元素的以前的单冒号表示法。本规范中引入的新伪元素不允许
这种兼容性

似乎对于CSS2.1中已经存在的伪元素使用(仅)单冒号表示法是安全的,因为UA必须向后兼容。


1
记录下来,该答案同样可以正确地标记为正确。它提供了一些有价值的观点,即使最初问题的推动力具体是伪元素之前和之后。感谢您添加它。
jinglesthula

您是如何得出这个结论的?我得出了相反的结论...如果不允许单冒号用于新的伪元素,您是否不应该开始使用双冒号来养成这种习惯?
andrewtweber's

@andrewtweber在原始问题(IE8)的上下文中使用double会破坏CSS。就是说,在撰写本文时,大多数网站可能都认为IE8使用率很低,以至于允许翻倍的使用而不会产生任何重大影响。可能依赖浏览器供应商永久支持单个表示法,但此时切换编码习惯并没有错。
jinglesthula

对于OP Yep,@ andrewtweber +1是IE8,2012年将考虑IE8; YMMV-在大型B2B项目中仍在2015年,但在其他Web项目中则没有。这两种表示法对于这些现有的伪指令都是完全有效的。CSS最小化将使用单冒号表示法获得1个字节。如果您想始终使用一种表示法而禁止使用另一种表示法,那么这是惯例,您完全可以与您的团队一起使用,但这不是推荐。
FelipeAls

@jinglesthula和Felipe,您是对的,我没有注意到日期。也许应该更新答案,因为这个问题在搜索结果中占很高的位置
andrewtweber 2016年

22

关于考虑使用一个“冒号”冒号,我绝对不同意@mddw和@FelipeAls。

这种“即使已弃用我也会使用它”的心态正是基于浏览器的技术如此缓慢地前进和前进的原因。

是的,我们希望保持与旧标准的兼容性。面对现实吧,这就是我们被抓到的手。但是,这并不意味着您无视当前的标准,而赞成过时的标准,从而懒惰了自己的发展。

最终目标应该是保持对当前标准的符合性,同时支持尽可能多的旧标准。

如果伪元素:在CSS2和::CSS3中使用,则不应使用其中一个。我们应该同时使用两者

为了完全回答最初提出的问题,以下是在支持CSS最新版本(版本3)的同时保留对版本2的传统支持的最合适方法。

.foo:after {
  /* styles */
}
.foo::after {
  /* same styles as above. */
}

3
我认为可以肯定地说,浏览器供应商将无限期地继续支持旧的表示法,因为实际上他们希望浏览器“正确地”呈现的代码量永远不会被更新。另一方面,我认为,保留样式的单独副本会引起DRY红旗。我认为在IE7市场份额下降之前使用单冒号表示法比懒惰更实用。就是说,我希望网络能像任何人一样向前迈进!
jinglesthula

9
如果您“ 绝对不同意 ”我的回答,那么您绝对不同意W3C REComendation中的“ 必须 ”一词。“ 最终目标应该是保持对当前标准的合规性,同时尽可能多地支持旧标准。 ”这是REC的这一部分正在解决的问题,它明确指出UA不得强迫作者使用两种表示法并说明这些UA必须如何完成。如果您对此不满意,请随时与CSS WG邮件列表联系(或在Twitter上@ Glazou该工作组的联合主席)
FelipeAls 2013年

4
我不会不同意您的全部回答,只是将单个冒号的使用视为“安全”。新伪元素不允许兼容,这意味着将来任何伪元素都只能在中实现::。根据您的方法,个人将开始混合使用伪元素:::对伪元素进行匹配。明确遵守旧标准(暂时可能会得到支持)是一种固有的不良做法,应在合理可能的情况下避免使用。如果您不同意该说法,我们只是持不同观点。
约书亚伯恩斯

4
坚持一个明确的兼容标准本质上是不是一个不好的做法,如果兼容性的目标。另一方面,同时使用这两种方法会导致样式重复-就像编码一阵子的人都知道,重复的代码只是喜欢发散。
cHao 2014年

8
@JoshuaBurns如果我的前任重复了一堆代码来保护自己免受假想的未来威胁,我会感到更加“被拧”。
马克·阿默里

2

但是,对于新的javascript和CSS都使用polyfill变得越来越流行,因此,只要有必要,您可能只想坚持使用较新的double-colon(::)语法,并为较旧的浏览器维护一个polyfill。


本质上,这只是一个元答案。它没有提供任何有用的信息。如果答案已过时,请对其投下赞成票和/或对此表示评论。
TylerH '16

2
为什么不还要链接这样的polyfill,这样我们就可以使用它而无需进一步搜索?
MightyPork

4
嗯,第一部分可能是meta,但是我认为第二部分是一个很好的答案。在我工作的地方,我们不使用预处理器和/或polyfill,因此可接受的答案对我有用。但是对于使用这种工具的任何商店或开发人员,此答案可能更有用。
jinglesthula

1

根据浏览器统计,在过去一年中,IE 8.0在美国的价值下降到不足1%。

http://gs.statcounter.com/browser-version-partially-combined-market-share/desktop/united-states-of-america/#monthly-201512-201612

在2015年12月,IE 8.0占据了2.92%的市场。在2016年12月,IE 8.0占据了0.77%的市场份额。

以这种下降速度,停止支持旧版本的IE并开始对伪元素使用::并不是最坏的主意。


值得庆祝的是:)还值得指出的是,这仍然取决于情况。如果您是亚马逊用户,则0.5%的用户等于超过100万认为您的网站已损坏的客户。如果您要为一家10人创业公司撰写博客,那么赌注可能会有所不同。
jinglesthula

绝对像Amazon这样的组织。但是,0.77%的人口分布并不均匀。是比例过高的老人们或钱少的人,他们无法升级。从纯粹的业务角度来看,这些可能不是理想的目标市场。因此,对大多数公司而言,0.77%的重要性甚至不及少数人所暗示的重要。而且这个数字只会越来越小。
DR01D

好点。另一个需要升级的艰巨任务是政府和企业集团严重依赖只能在特定浏览器版本上运行的应用程序(尽管值得庆幸的是,随着时间的推移,这种方式的组织也会逐渐减少)。可能没有人需要为这样的客户端编写代码:)
jinglesthula

0

包括这两种表示法当然更安全,但是我看不到任何浏览器都长时间删除该单一表示法,因此只使用一个即可(这是有效的CSS2)。

我只根据习惯习惯只使用一个冒号表示。


1
正如其他答案所表明的那样,它要比这复杂得多,并且存在一些非显而易见的陷阱(例如,对CSS 3伪元素支持单冒号表示法明显违反规范,因此对于CSS作者而言,明智的做法不是对这些选择器使用单冒号表示法)。
Mark Amery 2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.