Discourse Spoiler Alert



I really love this rendition of the spoiler alert. It’s just about perfect, but there are a few things I would love to see done with this plugin someday, some of which have already been mentioned:

  1. The ability to adjust the blur levels using the plugin settings UI in the admin panel. I feel like with spoiler-tagged images, the blur levels might not be strong enough to keep an image from being spoiled :slight_smile:

  2. Have a spoiler-tagged image only change blur levels when actually hovering over/clicking the image. See the scary image post in this topic as an example. If you hover/click in the whitespace to the right of the image, it behaves as if you were interacting with the image itself.

  3. Figure out a way to prevent navigation to spoiler-tagged links until the spoiler alert has been deactivated.

  4. I saw at least one mention of weird behavior with lightboxed images in this topic. I haven’t tested it yet, but if that is indeed a problem, that would be great to fix. I imagine the fix would be similar to the link issue.

Just some constructive feedback. If I have some free time, I might take a crack at one of these. If I come up with any solutions before you or anyone else, I’ll report back. In the mean time, thank you @sam and the rest of the Discourse team for all you do here!


I’ve been messing around, trying to reproduce the spoiler behavior that’s used by Discourse. The fiddle I link to below is not the most eloquently written piece of code, but I think it demonstrates some interesting considerations that the team might be able to work into the existing plugin to make it better.

I’m not sure this is necessary anymore. What I found is that it helps to have two different blur cases: one for text and one for photos. The text does not seem to need very much to keep it hidden, and it’s easy to have too much. On the other hand, images seem to be better off at a higher blur level.

This should be an easy fix, the div expands to 100% width by default. It looks like adding display: inline-block to the CSS should handle it.

Handled with a special case for links.

I’m pretty sure the solution for the links will also work for lightboxes, but I can’t test that in my little fiddle.

I’m not yet experienced enough with GitHub or Discourse plugin development work to try to implement these changes and submit a pull request, so hopefully someone else that is more experienced can use this to update the current plugin at some point. Anyway, here’s what I came up with, I hope it helps!


(Régis Hanol) #55

It’s never too late to learn :wink:


Oh, I plan to learn. It will just take some time. I’ve also never contributed to an open source project, and to be honest, the thought is a little intimidating. I’ll continue to work toward a greater contribution with this, I just thought I’d share what I’ve come up so far. It’s one of those cases where I’d be more than happy if someone was inspired and beat me to it due to already know the ropes.

(Joshua Rosenfeld) #57

Curious, what makes contributing intimidating? We want anyone who’s interested to be able to contribute, without feeling intimidated.


The main factor is just the amount of responsibility you have as a good contributor (or at least that’s what it feels like to me), and the fact that I hadn’t found this extremely helpful topic until after I posted that. I had seen a few how-to topics on aspects of development, but this should be the comprehensive tutorial I was looking for. Not sure how I missed it!

(Tumi) #59

Is it possible to make that the only registered users can click and see the spoiler ?

(Jeff Atwood) #60

No, this is not possible.

(Kris) #61

Just made a PR for blocking clicks on spoiled links:

Someone needs to check my JS, but basically if the link is blurred I apply the pointer-events: none CSS, which prevents links from being clickable. Once it’s unblurred, it’s clickable.

(Kris) #62

Ah, unfortunately this wasn’t as simple as I hoped. pointer-events is technically supported by all the browsers we support, but it’s implemented in different ways so it’s not reliable. So for the time being links will still be clickable through spoilers. Maybe we can add an onclick="return false" to it or something instead?

(Mittineague) #63

AFAIK, it depends on whether or not you want to do anything with the click event. eg. for XHR it would have a preventDefault in the event listener.

(Colin Marshall) #64

How necessary is having the ability to “unspoil” the content after it has been revealed? The link problem would be any easy fix if you got rid of that capability.

(Lilly) #65

Is there any update on this?

(Jeff Atwood) #66

Due to technical limitations in browsers, it’s not currently possible.

(Biscuit) #67

If a spoiler blur is placed over a URL, then when the user clicks on the spoiler, the URL opens before the user gets a chance to see what they’re clicking on. This allows the original poster to potentially send the unsuspecting user somewhere inappropriate.

Expected Behaviour:
Clicking on the spoiler should remove the blur and make the URL underneath accessible, but not open the link. This is how it works in the compose preview pane. But, once the message is posted, the above issue occurs.

I raised this previously, but can’t find the topic. The issue still occurs.

Here’s a safe example, but it could be used to open malware or inappropriate material: (Click below)

(Joshua Rosenfeld) #68

@Biscuit moved your post here. See details above.

(Biscuit) #69

Thanks Joshua. Forgot this is a plug-in.

(Régis Hanol) #70

If you have any idea how to fix it, I’d be happy to add it :wink:

(Biscuit) #71

Ha! My strategy is to report the issue and await the fairies to do their magic.

I’m not a developer, so I can’t help solve it technically.

(Régis Hanol) #72

Ok, this should now be fixed :wink:

Links is now only (CTRL+click or middle click)able though.