When putting emoji into spoilers on Stack Exchange, like in the example below:

🚫 (text hides like normal)

The emoji appears without hovering over the spoiler, but the text doesn't appear when not hovering over the spoiler.

For those who don't see the emoji without hovering over it, here's an image:

Image of bug

Many Puzzling puzzles have emoji tied into their answers, like Emoji Connect Wall, and it ruins the puzzle when you try to solve it yourself and you see the emoji answer.

Known browser/operating system combinations that the above bug are listed below:

  • Google Chrome Canary 54.0.2828.0, macOS Sierra 10.12 beta (16A201w)
  • Google Chrome Canary 54.0.2834.0, macOS Sierra 10.12 beta (16A201w)
  • Safari 10.0 (12602.1.32.7), macOS Sierra 10.12 beta (16A201w)
  • Opera 38.0.2220.41, macOS Sierra 10.12 beta (16A201w),Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) OPR/38.0.2220.41

It appears that it's only reproducible on macOS and not on Windows.

Also, for some reason, Opera makes the emojis tiny:

Tiny Opera emoji

  • The spoilers are done with font colour for a reason I don't really remember, so it works fine, but only if your display font stylizes them text-like, for obvious reasons
    – Tim Stone
    Aug 15, 2016 at 5:03
  • 1
    No repro here on MSE. What browser are you using? It might be browser specific. Aug 15, 2016 at 7:00
  • No repro on firefox
    – Magisch
    Aug 15, 2016 at 7:30
  • 1
    Repro on Chrome 52.0.2743.116 (OSX).
    – Cai
    Aug 15, 2016 at 8:49
  • on Win10: reproducible only with FF 47 and 48, not reproducible with Chrome 52, IE 11, Edge 25.10586.0.0
    – gnat
    Aug 15, 2016 at 8:59
  • If you can install user scripts, SOUP should fix this as a side effect of its general spoiler CSS/JS rewrite. (The development branch of SOUP even has a slightly fancier version of the fix, with placeholder text and a nicer fade effect, which I really should release into the stable branch one of these days.) Aug 15, 2016 at 9:25
  • Having the same effect on both Chrome, Firefox and Safari on OSX
    – Loovjo
    Aug 15, 2016 at 10:32
  • Can you please share a screenshot where you see it bugged? Aug 15, 2016 at 13:15
  • @gnat no repro even with Firefox 47/48 under Windows 7. Probably it's due to some system font misbehaving. (So not SE fault, and can't be fixed.) Aug 15, 2016 at 13:18
  • @ShadowWizard Editing the post now. Aug 15, 2016 at 13:19
  • @Magisch What operating system? Aug 15, 2016 at 13:19
  • @Peanut W7 64b sp2
    – Magisch
    Aug 15, 2016 at 13:22
  • The bug affects OS X only: bugzilla.mozilla.org/show_bug.cgi?id=860142 (SE using color to "hide" the spoilers, and that OS does not honor color change for emoji font.) Aug 15, 2016 at 13:23
  • @ShadowWizard Why can it be reproduced with Firefox 47 and 48 on Windows 10 then? Aug 15, 2016 at 13:27
  • @Peanut good question. I got Windows 10 at home, will try to reproduce there as well. Aug 15, 2016 at 13:30

1 Answer 1


This is indeed a bug, but I am not sure if it is (entirely) SE's fault.

The icon seems to be a UTF-8 character, specifically \ud83d\udeab, (no entry sign character) which shows as 🚫 (the rendering differs per platform, so iOS shows it different than Android and your desktop browser). The spoiler is made using CSS: it initially sets all text to the same color as the background, and then eases in the black color using a transition.

The problem is though, not all characters use the text color giving through CSS. One example is the character you mentioned. It is specified to have the red border.

Given the diagnosis above, all browsers could be affected. Some browsers though (like Edge) have a black 'no entry sign' that respects the color attribute. Some other don't, like Chrome and Safari Mobile.

SE could set the visibility to hidden on the content of the spoiler div (or introduce a span under the div to do the hiding) and show that on hovering over the div.

An easier fix than described above is using color: transparent; instead of the background color of the spoiler.

  • 1
    However, images hide and aren't text. Aug 15, 2016 at 13:46
  • 1
    They aren't images, they are text. Aug 15, 2016 at 13:47
  • reread my comment. I never said emojis are images. Aug 15, 2016 at 14:22
  • 2
    @Peanut Images use opacity because they are a separate element inside the blockquote. We can't use opacity on the main blockquote because that would hide the border and background with the text.
    – animuson StaffMod
    Aug 15, 2016 at 14:34
  • @animuson have one element for the border and background (opaque), and one for all the contents (transitioning opacity)? Another positive would be that it's GPU friendly, unlike color transitions. Aug 15, 2016 at 22:20
  • @JanDvorak I had complained about not using opacity originally. But now its to the point where altering how the syntax gets rendered would break all the past uses. We've only dug ourselves into a hole that will be much harder to get out of now.
    – animuson StaffMod
    Aug 15, 2016 at 22:25
  • @animuson speaking of self-dug holes, how is the dev team feeling about the table layout used throughout the site? ;-) Aug 15, 2016 at 22:26
  • 3
    @JanDvorak About like this: i.stack.imgur.com/kckss.gif
    – Adam Lear StaffMod
    Aug 15, 2016 at 22:53
  • @Adam who's that in the gif? ;-) Mar 18, 2018 at 9:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .