a spoiler / content warning tag

[WebWeWantBot]

---

title: a spoiler/cw tag date: 2023-04-21T16:34:03.137Z submitter: jimmy frasche number: 6442bafb283f93005e2f13c3 tags: [ ] discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/ status: [ discussing || in-progress || complete ] related:

• title: url: type: [ article || explainer || draft || spec || note || discussion ]

This is as a user. Many sites have these, all work basically the same way but no two work identically and none seem to handle a11y especially well. Users deserve to have a common interface that works for this common need. Summary/details does not work for a multitude of reasons detailed in the previous discussion https://discourse.wicg.io/t/standardized-spoiler-tag/5814

---

If posted, this will appear at https://webwewant.fyi/wants/6442bafb283f93005e2f13c3/

[aarongustafson]

I think this is an interesting one, for sure. As discussed in the WICG thread, the existing details/summary paradigm does seem to work for block-level spoilers, but it’s not as general purpose as a feature like this could/should be. Perhaps this is something that could be achieved via an attribute, rather than a tag.

The "content warning" concept probably makes the most sense as a general purpose attribute (content-warning). The value could be details about the kind of content warning, so:

<article content-warning="child abuse">
  … article contents …
</article>

Or images:

<img content-warning="violence gore" …>

Or in the case of an inline example:

I thoroughly enjoyed the film, especially
when it was revealed that
<b content-warning="spoiler">Taye Diggs
had been the bad guy all along</b>.

In terms of browser behavior, the content so marked could be obscured with an opaque cover with the content warning layered over it and an option to "Show" the content. Any so-obfuscated elements should be considered inert and not be included in in-page search. Downloading so-designated images should also be deferred, possibly until the "show" interaction happens.

This behavior could probably be mocked up in a Codepen.

[aarongustafson]

Hastily thrown together, but interesting: https://codepen.io/aarongustafson/pen/rNqjeqj

[jimmyfrasche]

as long as it works and is stylable enough to keep from people having to rig their own to get it to look how they want, then I'm not too fussed about element vs. attribute: whatever works.

[jimmyfrasche]

details/summary doesn't really work

1. in chrome, it auto opens if find-in-page matches (which outside this use-case is fantastic)
2. it cannot be styled sufficiently

2 can be improved and maybe there'll be a way to opt out of 1 at some point but it's still cannot be used inline which is the majority of the need so a new mechanism certainly seems necessary

[odraencoded]

The "content warning" concept probably makes the most sense as a general purpose attribute (content-warning). The value could be details about the kind of content warning.

I'm not sure this is a good solution for the spoiler problem. From the attribute values it looks like you're marking the type of warning, which works great for most stuff because they don't have an intrinsic label.

For spoilers, though, they come from a work of fiction, so they can be labelled by title, season, episode, chapter, scene, etc. The spoiler label could be "second half." It wouldn't make much sense for the content warning to be "second half."

If you don't like having to click/hover on things to reveal them, you might consider all CW's to be an inconvenience so you'd rather turn them off, but spoilers would still be a necessity for you, so you can't do that. You can't selectively reveal CW's either if there's no agreed standard, and if the values are limited you can't type "second half" into the attribute which means it doesn't standardize the contemporary use of spoiler tags.

Essentially CW's are for content you might not want to ever see, while spoiler tags are for content which you may not want to see yet.

[jimmyfrasche]

I don't know if there's going to be a one size fits all taxonomy that we can come up with.

Different sites are going to have different needs and this is going to be largely coming from community generated content so how specific things are is a matter of balance between the community and the platform. Some places might be happy without any differentiation and some may need dozens of options.

You could also use this mechanism for things that are neither spoiler or content warning, like a self study site hiding the solutions to a math problem so you can work it out on your own then check your work.

It is important that a site with various offerings make them distinguishable when covered so it needs to be able to add an explanation on top of the cover somehow. And a site with different kinds of spoiler/cws could easily add have options in the settings to autoshow some or all of the different kinds by setting the open attribute when generating the html appropriately.

[jimmyfrasche]

The more I think about the more I think that means it should be a tag: so you can have an (optional) analogue of the summary element that let's you add arbitrary noninteractive content to the cover art. If there's just a ::cover or something like that it would have to accept content: 'some text' but unlike the other cases where you use that it would be optional and if you're limited to just text and background images you'd need to get too creative to match some of the cover art styles I've seen but they're all trivial if you can include some basic formatting.