By jinglesthula


2012-04-16 21:06:34 8 Comments

Since IE7 and IE8 don't support the double-colon notation for pseudo-elements (e.g. ::after or ::first-letter), and since modern browsers support the single-colon notation (e.g. :after) for backwards compatibility, should I use solely the single-colon notation and when IE8's market share drops to a negligible level go back and find/replace in my code base? Or should I include both:

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

Using double alone seems silly if I care about IE8 users (the poor dears).

6 comments

@zpr 2016-06-16 03:01:43

However, it's become increasingly popular to use polyfills for both new javascript and CSS, so you might just want to stick with using the newer double-colon (::) syntax, and maintain a polyfill for older browsers, so long as that is necessary.

@TylerH 2016-08-11 13:38:49

This is essentially just a meta answer; it doesn't provide any useful information. If an answer is outdated, downvote it and/or comment on it indicating such.

@MightyPork 2016-09-30 12:07:24

why not also link such a polyfill, so we can use it without further googling?

@jinglesthula 2016-10-07 15:17:54

eh, the first part may be meta, but I think the second part is a good answer. Where I work we don't use a preprocessor and/or polyfills, so the accepted answer works for me. But for any shop or dev that uses such tools, this answer is probably more useful.

@DR01D 2017-01-26 16:12:44

For what it's worth according to Browser Stats IE 8.0 has dropped to less than 1% in the USA over the past year.

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

In December 2015 IE 8.0 had 2.92% of the market. In December 2016 IE 8.0 had .77% of the market.

At that rate of decline it wouldn't be the worst idea to stop supporting old versions of IE and start using :: for Pseudo Elements.

@jinglesthula 2017-01-26 18:19:34

Which is something to celebrate :) It's also worth pointing out that it depends on the situation still. If you're Amazon, 0.5% of your users equals over a million customers who think your site is broken. If you're doing a blog for a 10 person startup, the stakes may be different.

@DR01D 2017-01-26 19:02:21

Definitely true about an organization like Amazon. But that .77% isn't evenly distributed across the entire population. It's disproportionately old folks or people with little money that can't upgrade. From a purely business standpoint those probably aren't ideal target markets. So to most companies the .77% group is even less significant than what that small number suggests. And that number will only get smaller.

@jinglesthula 2017-01-27 16:32:09

Good points. Another group where upgrading is an uphill battle is government and business groups rely heavily on apps that will only work with a certain browser version (though thankfully groups that are that way will diminish over time as well). May none of you ever have to code for such a client :)

@user123444555621 2012-04-16 21:25:06

Do not use both combined with a comma. A CSS 2.1 compliant (not CSS3 capable) user agent will ignore the whole rule:

When a user agent cannot parse the selector (i.e., it is not valid CSS 2.1), it must ignore the selector and the following declaration block (if any) as well.

CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.

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

You could however use

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

On the other hand this is more verbose than necessary; for now, you can stick with the one-colon notation.

@jinglesthula 2012-04-16 22:59:00

thanks for including the info on the comma and the ignore. That probably would have had me (and maybe others) scratching heads for a while. Looks like the best thing when 99% of browsers in use do support the double colon notation is to shift to using that and (because no one will drop single colon support and break the web, so there's not really even a point in later find/replace-ing old code at that point).

@Gershom 2015-11-03 18:51:13

This isn't the way forward. Browser progress will be forcibly expedited if people stop pandering to antediluvian, broken, and deprecated browsers.

@BoltClock 2016-02-23 06:20:31

@Gershom Maes: That's not for you to say, unfortunately. I think a large portion of developers hope for the same, but it's just not gonna happen.

@James Cushing 2016-04-16 10:52:58

@Gershom Maes we can dream

@jinglesthula 2016-10-24 20:14:44

I think it's important to note that maintaining duplicate styles can be problematic. As cHao notes below, duplicate code loves to diverge. Most developers probably have to be bitten by it a few times to swear it off :)

@Joshua Burns 2013-11-19 21:35:24

I absolutely disagree with @mddw and @FelipeAls, in regards to considering the use of one colon "safe".

This "I'll use it even though it's deprecated" mentality is exactly why browser-based technologies are so slow at advancing and progressing forward.

YES, we want to maintain compatibility with old standards. Let's face it, it's the hand we've been dealt. BUT, this does not mean you have an excuse to be lazy in your development, by ignoring current standards in favor of deprecated ones.

Out goal should be to maintain compliance with current standards, while supporting as much of the legacy standard as possible.

If pseudo-elements use : in CSS2 and :: in CSS3, we should not be using one or the other; we should be using both.

To fully answer the original question asked, the following is the most appropriate method of supporting the most current implementation of CSS (version 3), while retaining legacy support for version 2.

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

@jinglesthula 2013-11-19 22:52:08

I think it is pretty safe to assume that browser vendors will continue to support the old notation indefinitely due to the amount of code that will realistically never be updated that they want their browser to render 'correctly'. On the other hand, maintaining separate copies of the styles raises the DRY red flag, I think. I think it's more pragmatic than lazy to use the single-colon notation until IE7 market-share drops off. That said, I want the web to move forward as much as anyone!

@FelipeAls 2013-11-21 09:36:30

If you "absolutely disagree" with my answer, then you're absolutely disagreeing with the word must in a W3C RECommendation. "Out goal should be to maintain compliance with current standards, while supporting as much of the legacy standard as possible." is what is being addressed by this part of the REC and it explicitly states that UAs mustn't force authors to use both notations and explains how this must be done by these UAs. Feel free to contact CSS WG mailing-list if you're not OK with that (or on Twitter @glazou co-chairman of this Working Group)

@Joshua Burns 2013-11-21 18:11:20

I don't disagree with your entire answer, only regarding the use of a single colon as "safe". compatibility is not allowed for the new pseudo-elements means any future pseudo-elements will only be implemented in ::. According to your approach, individuals will then start to mix-and-match the use of : and :: for pseudo-elements. Adhering explicitly to old standard (which for the time being may be supported,) is an inherently bad practice and should be avoided whenever reasonably possible. If you disagree with that statement, we simply hold different views.

@cHao 2014-02-10 12:50:59

Adhering to an explicitly compatible standard is inherently not a bad practice, if compatibility is a goal. On the other hand, using both leads to duplicate styles -- and as anyone who's coded for a while knows, duplicated code just loves to diverge.

@BoltClock 2014-04-28 12:47:58

If you really want to use both notations, you can throw all your rules with the old notation into a separate stylesheet reserved for IE8 and older with a conditional comment, since those are the only browsers/versions that are still relevant at the time of this writing that support the old notation without supporting the new one. From a pragmatic stance, it is utterly pointless to include both notations in the same stylesheet unless you're a wizard with PE or GD or whatever with CSS and can figure out a way to make the legacy pseudo-elements relevant even when CSS3 features are not supported.

@Joshua Burns 2014-04-28 14:49:18

@BoltClock that is a great suggestion, as most interfaces of any complexity end up with IE-specific stylesheets anyways.

@Mark Amery 2014-08-31 15:55:05

-1. Yes, eventually we want developers to stop using the legacy selectors (since they break the otherwise-elegant system of using single colons for pseudo-classes and double colons for pseudo-elements). However, how soon that happens is not affected at all by whether developers right now use only the single colon syntax or use both. To support legacy documents, new browsers will need to support this syntax forever anyway - but once IE 8 finally dies, web developers can abandon the single-colon syntax forever. What advantage is gained from people using both syntaxes in the interim?

@Joshua Burns 2014-09-22 15:55:17

@Mark Amery: Forward compatibility. Why wait until IE8 dies to implement the appropriate syntax?

@Mark Amery 2015-02-03 15:23:14

@JoshuaBurns There is no forward compatibility issue, here, though. Browsers - and the CSS spec - will likely never be able to drop support for the old syntax, because there are documents out there that use it that are unmaintained and will never be updated. There is no reason to fear that some day the old syntax will cease to work.

@Joshua Burns 2015-02-11 18:37:40

@Mark Amery, betting on something you have no control over or view into the future of is a foolish practice. As a programmer, you can do the minimum, the good enough; but that sort of programming ends up screwing anyone who inherits your projects in the future.

@Mark Amery 2015-02-11 18:40:50

@JoshuaBurns If my predecessor had duplicated a load of code to protect against an imaginary future threat I would feel significantly more "screwed".

@Bram Vanroy 2016-06-06 08:22:28

I always prefer to keep the most recent notation as the last line. By doing so, you make sure that the latest standard is always used. In your code example, the "old" CSS 2.1 standard will always be used (as long as the browser supports it).

@FelipeAls 2012-04-16 21:17:48

From CSS3 Selectors REC:

This :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements.
For compatibility with existing style sheets, user agents must also accept the previous one-colon notation for pseudo-elements introduced in CSS levels 1 and 2 (namely, :first-line, :first-letter, :before and :after).
This compatibility is not allowed for the new pseudo-elements introduced in this specification.

It seems you're safe using (only) one-colon notation for pseudo-elements that already existed in CSS2.1 as UAs must be backward compatible.

@jinglesthula 2013-11-19 22:48:36

For the record, this answer could equally well be marked as correct. It provides some valuable perspective, even though the impetus for the original question was specifically the before and after pseudo-elements. Thanks for adding it.

@andrewtweber 2016-01-04 19:02:51

How did you come to that conclusion? I came to the opposite conclusion... if single colons will not be allowed for new pseudo-elements, shouldn't you start using double colons to get in the habit?

@jinglesthula 2016-01-04 21:36:18

@andrewtweber in context of the original question (IE8) using double would break the CSS. That said, as of this writing most sites probably see IE8 usage at such a low level as to allow double without any significant fallout. Browser vendors may be relied upon to support the single notation in perpetuity, but nothing wrong with switching coding habits at this point.

@FelipeAls 2016-01-05 10:27:36

@andrewtweber +1 for OP Yep, IE8 was to be taken into account in 2012 and - YMMV - is still in 2015 in huge B2B projects and alike but not in other web projects. Both notations are perfectly valid for these existing pseudos. CSS minification will gain 1 byte by using one-colon notation. If you want to always use one notation and forbid the other, well that's a convention you're completely free to do so with your team but it's not a RECommendation.

@andrewtweber 2016-01-05 15:56:59

@jinglesthula and Felipe, you're right, I didn't notice the date. Maybe the answer should be updated though, since this question comes up high in search results

@Ronald 2016-04-21 12:00:46

@FelipeAls Wouldn't it be best to only use the double-colon notation for all pseudo-elements and let the CSS minifier reduce the syntax in an automated build task? cssnano lists this as one of it's features on the homepage: "Pseudo element double-colon syntax reduction".

@FelipeAls 2016-04-21 12:15:06

@Ronald That's a convention you can adopt but it isn't "better" (or worse). If you still support IE8 (my sincere thoughts and), you'd better use single-colon and make sure Autoprefixer replaces double-colon by single ones otherwise it's a matter of taste. I'm very accustomed to single-colon because even IE7 didn't exist when I begun professionally but that's just a personal habit.

@mddw 2012-04-16 21:08:16

Including both notations is certainly safer, but I can't see any browser dropping the single notation for a long time, so only a single one'll be fine (it's valid CSS2.)

Personnaly I only use the single colon notation, mostly by habit.

@Mark Amery 2014-08-28 14:05:01

As the other answers make clear, it's a bit more complicated than this and there are some non-obvious traps (e.g. supporting single-colon notation for CSS 3 pseudo-elements is an explicit violation of spec, so it seems wise for CSS authors not to use the single-colon notation for those selectors).

Related Questions

Sponsored Content

7 Answered Questions

[SOLVED] CSS: How to remove pseudo elements (after, before,...)?

19 Answered Questions

[SOLVED] Can I use a :before or :after pseudo-element on an input field?

22 Answered Questions

12 Answered Questions

[SOLVED] Can I change the height of an image in CSS :before/:after pseudo-elements?

  • 2012-01-23 20:14:34
  • Coderer
  • 295261 View
  • 252 Score
  • 12 Answer
  • Tags:   css pseudo-element

8 Answered Questions

Sponsored Content