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.

4 Likes

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.

1 Like

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?

spoiler

a large percentage of the first post is about that

<details> + <summary>

Chromium also open up the details on search

1 Like

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”)