A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Standardized <spoiler> tag


A feature for marking “spoilers” is a fairly common addition to community sites. It’s unusual but not without precedent to see them in other contexts, such as an article.

As far as I am aware, the origin, and hence name, is to hide a portion of text that talks about a recent movie or episode of a television show to hide it from anyone who hasn’t seen it yet and doesn’t want details spoiled unless they actively take action to reveal it. Spoilers are also increasingly used for material that requires a content warning. I have also seen them used to hide an answer to a problem, allowing readers to work it out for themselves before checking that they got it right on their own.

Spoilers are similar to details/summary but there are some important differences

  • spoilers are an inline element
  • the hidden content is not collapsed, it is obscured: generally by rendering the content entirely black, as if it had been redacted with a permanent marker, like a classified bit of a government report
  • a summary would defeat the point, though there could be a reason for why the content is obscured

While spoilers all tend to look roughly the same the method to reveal the underlying content differs. Some only show on hover. Some require a tap/click and some of those then cannot be re-hidden. Most don’t stay hidden when highlighted. Very few tend to work with keyboards.

It would be good to standardize these not just because they’re common but to make sure they’re accessible and uniform.

While there would be a lot of details to work out, I imagine they would be very easy to polyfill allowing the various platforms to transition to the standard tags while browsers roll them out.


I looked at a Mastodon instance for the first time today and noticed that all of the media was in togglable spoilers that defaulted to open, presumably unless the author noted otherwise. I had not seen that pattern before.


This seems like a good low hanging fruit to me. It is quite common and it also makes me wonder how custom implementations deal with screenreaders.


Are there any objections to the idea?

What would be the best course for moving forward? Would this fall under open-ui?


dose not <details> + <summary> work?



a large percentage of the first post is about that


<details> + <summary>

Chromium also open up the details on search


Another difference then. You wouldn’t want spoilers to open on search (though you probably would want some indication that “hey what you’re searching is under this spoiler, reveal if you dare”)


A useful reference is the markup used in the Matrix protocol. Most clients support the following syntax:

<span data-mx-spoiler="optional placeholder text">hidden content</span>

The result is typically the placeholder text followed by blurred or blacked-out hidden text, revealed upon user interaction. Children aren’t limited to text; this is a common approach to hiding images.

Some clients support Markdown flavors with the following syntax:

||optional placeholder text|hidden content||

Reddit and Discord have similar features.


I’d describe the difference between <details> and <spopiler> like this:

While a disclosure widget exists to make information toggleable, a spoiler exists to make information inaccessible without consent. The implications for assistive technologies would be significantly different.

I think that <summary> could be an optional child of a <spoiler> element to allow for placeholder text.


The other nice benefit of a dedicated element is that it can have different default display - <spoiler> wants to default to inline, rather than block.


More than that, a details tag inside a p tag causes the p to close. Even if details were able to be used in every other way it would be insufficient as you need to be able to drop a spoiler in the middle of a sentence. That’s just how people use spoilers.


I posted some additional thoughts over here: a spoiler / content warning tag · Issue #615 · WebWeWant/webwewant.fyi · GitHub

TLDR; It might make more sense to have a content-warning (or similar) attribute that could be applied to any element and whose value could be the kind of content warning (e.g., spoiler, violence, abuse).


I just wrote a lil blog post fleshing out my thoughts, including how this differs from <details>: